Dormant Integration

Expanded Definition

A dormant integration is not simply an unused connection. It is a still-authorised SaaS-to-SaaS path that can retain OAuth consent, API keys, refresh tokens, or service credentials after the business process has stopped. In NHI governance, that means the integration may continue to read data, post updates, or call downstream systems without an active owner watching it.

Definitions vary across vendors because some tools classify inactivity by traffic volume, while others key off last login, last token use, or missing business ownership. For security teams, the important distinction is between an integration that is no longer needed and one that is no longer visible but still technically capable of acting. That is why dormant integrations sit alongside other NHI lifecycle issues covered in the Ultimate Guide to NHIs, and why identity monitoring should align with control expectations in NIST Cybersecurity Framework 2.0.

The most common misapplication is treating a disabled app workflow as retired when the linked tokens, delegated scopes, or webhook credentials still remain active in the source and target systems.

Examples and Use Cases

Implementing dormant integration governance rigorously often introduces discovery overhead and business-process friction, requiring organisations to weigh stronger access hygiene against the time needed to validate ownership and intent.

• A marketing automation platform still pushes customer records into a CRM after the campaign was cancelled, because the OAuth grant was never revoked.
• A finance team decommissions a reporting dashboard, but the service account remains active and continues to pull ledger data into a data warehouse.
• An HR integration stops being used after a vendor change, yet its refresh token still allows periodic access to employee profile fields.
• A webhook tied to an incident management tool is forgotten during a migration, creating a silent path for unreviewed ticket creation or data exposure.
• A low-code workflow is abandoned by its original owner, but the integration identity still exists in the tenant and can be reactivated through copied credentials.

These scenarios are easier to spot when teams correlate token age, last-use telemetry, and business owner attestations, a pattern reinforced in the Ultimate Guide to NHIs. They also map well to NIST guidance on asset visibility and ongoing governance in NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Dormant integrations matter because they combine two common NHI failure modes: weak offboarding and poor visibility. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes retired connections a realistic persistence path for attackers. Once a token or delegated consent is forgotten, the integration can become a shadow control plane for data access.

The risk is not theoretical. A dormant connection can bypass review queues, inherit broad permissions, and continue triggering automated actions long after the business believes the integration is dead. That is especially dangerous in SaaS ecosystems where service relationships multiply across departments and ownership changes over time. Good practice is to inventory integration identities, revoke unused consent, rotate or delete exposed secrets, and confirm that downstream automations no longer depend on stale credentials, as outlined in the Ultimate Guide to NHIs and reinforced by the control intent of NIST Cybersecurity Framework 2.0.

Organisations typically encounter the damage only after an audit, incident review, or data leakage investigation, at which point dormant integration cleanup becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• When does an OAuth integration become too risky to keep?
• When does a third-party integration become a security liability?
• When should teams revoke a third-party SaaS integration?