Why do dormant SaaS integrations create so much identity risk?

Why Dormant Integrations Become High-Value Targets

Dormant SaaS integrations are risky because identity does not expire just because a business process did. A forgotten connector can retain delegated consent, OAuth scopes, API keys, refresh tokens, or service-account privileges long after the owner has moved on. That makes it a standing NHI with no active sponsor, which is exactly the kind of asset attackers look for when they want low-noise access.

This problem is amplified by privilege creep and weak visibility. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, while only 5.7% of organisations have full visibility into their service accounts. In practice, a dormant integration may still be able to read mail, pull customer data, trigger workflows, or modify records, even though the original project is long closed. NIST guidance on identity and access governance in the NIST Cybersecurity Framework 2.0 aligns with this risk by treating access management as a continuous control, not a one-time setup.

The real-world failure mode is simple: teams assume unused means harmless, but attackers treat unused as quiet, persistent, and easy to miss. In practice, many security teams encounter dormant integration abuse only after data has already been accessed, rather than through intentional offboarding.

How Dormant Access Is Abused in Real Environments

Most dormant integrations remain dangerous because the underlying trust chain still works. A SaaS app may be “inactive” from a business point of view, yet its token can still refresh, its secret can still authenticate, and its delegated permissions can still authorize actions at runtime. That is why current guidance suggests treating integration offboarding as a lifecycle event, not an informal cleanup task.

Attackers often start with a leaked secret, an abandoned OAuth grant, or a stale API key in code or CI/CD. From there, they can enumerate data, pull attachments, create new tokens, or chain access into adjacent systems. NHIMG research shows how common this is: the Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 91.6% of secrets remain valid five days after notification. The 52 NHI Breaches Analysis also shows a recurring pattern of missed revocation and overlong credential lifetime.

Practically, defenders should inventory every integration, map the business owner, verify the exact scopes, and revoke anything that no longer has an active purpose. Short-lived secrets, enforced rotation, and centralized secrets management reduce the blast radius, but they only work if the organisation actually knows the integration exists. These controls tend to break down when credentials are embedded in code or when SaaS admins and application owners manage permissions in separate, uncoordinated workflows.

• Review delegated OAuth consent, not just local app settings.
• Identify secrets stored in code, configs, ticketing systems, and CI/CD runners.
• Revoke access on project end, vendor churn, or personnel changes.
• Use NIST Cybersecurity Framework 2.0 identity and access practices to make revocation auditable.

Where the Standard Answer Breaks Down

Tighter integration control often increases operational overhead, requiring organisations to balance lower exposure against faster delivery and fewer workflow interruptions. That tradeoff is real, especially in environments where teams spin up SaaS automations quickly and forget to formalise ownership later.

There is also no universal standard yet for how aggressively to disable inactive integrations. Some systems need long-lived access for batch jobs, vendor support, or cross-org reporting, so blanket expiry can break legitimate workflows. The better pattern is risk-based: align access duration to business purpose, require explicit renewal for high-risk scopes, and segregate read-only from write or admin-like permissions. Where service accounts or app registrations cannot be tied to a named owner, the risk rises sharply because nobody is accountable for rotation or removal.

For organisations building stronger NHI governance, the most relevant controls are the ones that make ownership, purpose, and expiry explicit. The Top 10 NHI Issues and the Snowflake breach both reinforce the same lesson: dormant does not mean neutral when credentials still authorize access. Organisations that lack automated revocation, lifecycle review, or secrets inventory usually discover the gap only after an incident, not during routine governance.

Related resources from NHI Mgmt Group

• Why do AI agents create more identity risk than ordinary SaaS integrations?
• How do third-party SaaS integrations create NHI risk and how should they be managed?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?