Residual credentials and orphaned access remain breach-grade risk

At a glance

What this is: This is an analysis of residual access, showing how dormant credentials and tokens outlive their owners and can still be used to breach connected SaaS environments.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern every authentication path, not just the primary directory account, or offboarding will keep failing in practice.

By the numbers:

• 54% of organizations lacked automation for lifecycle management.
• 68% of workers retain network access even after leaving an organization.
• 41% of successful human logins on Cloudflare-protected sites used a previously-leaked password.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Unixi's analysis of the Klue breach and residual access risk

Context

Residual access is what happens when an account, token, or delegated authorization keeps working after the business reason for it has ended. In identity programmes, the failure is usually not authentication itself but incomplete lifecycle management across SaaS, local logins, OAuth grants, shared credentials, and persistent sessions. For IAM teams, the problem is not confined to humans or service accounts. It is a cross-domain offboarding problem that leaves active access behind.

The Klue case is a familiar pattern in modern enterprise identity: a test integration was abandoned, but the credential remained active for years. Once that forgotten credential was discovered, attackers did not need to bypass authentication or exploit a software flaw. They simply used legitimate access that had outlived governance.

This is the same structural weakness that shows up whenever directories, SSO, and revocation workflows only cover part of the access graph. If the identity provider is the only thing being turned off, the rest of the access paths can stay live long after the user, project, or vendor relationship has ended.

Key questions

Q: What breaks when organisations disable the user but leave credentials and tokens active?

A: Offboarding fails because the real access path is not the directory account alone. Local passwords, OAuth grants, refresh tokens, API tokens, and sessions can keep working after the user is removed, which means the organisation has only partially revoked access. The control failure is incomplete lifecycle closure, not weak authentication.

Q: Why do residual credentials increase breach risk even when MFA is used?

A: MFA protects interactive login, but it does not automatically invalidate every existing token, session, or delegated authorisation. If those artefacts remain active after the owner has left or the project has ended, attackers can inherit legitimate access without triggering a fresh MFA challenge. That is why token and session lifecycle matters.

Q: What should teams get wrong about offboarding in SaaS environments?

A: They often assume disabling the primary account is enough. In reality, offboarding must also remove app-specific accounts, revoke OAuth tokens, and confirm that shadow IT services do not retain access. If the app estate is only partially known, offboarding is partial by definition and leaves residual access behind.

Q: Who is accountable when a phished identity is used to access downstream systems?

A: Accountability sits with the teams that own the identity, the application boundary, and the downstream trust chain. In practice, IAM, application, and security owners must all share responsibility for what a compromised session can reach. For regulated environments, the issue also maps to audit evidence, because access controls must be demonstrable after authentication, not just at login.

Technical breakdown

Why residual access survives directory offboarding

Residual access survives when the authoritative identity store is treated as the whole access model. In reality, SaaS environments often have local passwords, OAuth grants, API tokens, recovery channels, browser sessions, and SaaS-to-SaaS delegations that exist outside the IdP’s direct control. Disabling a user in the directory only removes the federated path. Anything provisioned elsewhere remains valid until explicitly revoked or expired. That is why offboarding can look complete in the IdP and still leave active access behind.

Practical implication: map every authentication path per application, not just the directory account, and require revocation coverage for each path.

Why orphan accounts are harder to find than active users

An orphan account is not just an unused account. It is an account, token, or session whose ownership can no longer be tied to an active person, role, or business need. The problem grows in shadow SaaS because employees can create accounts directly with corporate email addresses, bypassing procurement and security workflows. Once those accounts exist, the organisation may not know where they are, which means it cannot revoke them when employment or project ownership changes.

Practical implication: build discovery that finds accounts outside procurement and SSO records, then tie each one to an owner and a removal trigger.

Why OAuth tokens and refresh tokens change the offboarding problem

OAuth tokens and refresh tokens are not passwords, but they create similar persistence risks because they can continue authorising requests without another interactive login. Refresh tokens are especially problematic because they can extend access across many sessions, often until revoked. In a breach chain, a stolen token can become a bridge into customer environments even when the original account looks inactive. That is why token lifecycle is now part of identity governance, not just application security.

Practical implication: include token revocation, grant review, and token ownership in every offboarding and access recertification workflow.

Threat narrative

Attacker objective: The attackers wanted to convert abandoned internal access into downstream customer compromise and data exposure across connected SaaS environments.

1. Entry occurred through a forgotten service credential created for a test integration that was never shipped, but remained active for years. The credential gave the attackers legitimate access rather than forcing them to exploit a vulnerability.
2. Escalation came when the attackers used the compromised access to steal OAuth tokens tied to customer integrations. Those tokens extended the reach of the original credential into downstream corporate Salesforce environments.
3. Impact followed when the stolen tokens were used to enter dozens of corporate Salesforce environments, including LastPass, exposing customer data through legitimate but orphaned access.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Residual access is a lifecycle failure, not an authentication failure: The Klue case worked because the access path stayed alive after the business purpose ended. That is the governance problem IAM teams must name, because the directory record is often removed while the credential, token, or session remains usable. The implication is that offboarding must be measured by access-path completion, not account closure.

Orphan credentials create a long-tail breach window: A credential created for a test integration can become a live attack path years later if no owner, expiry, or revocation trigger survives project abandonment. That makes residual access more dangerous than ordinary privilege creep because the organisation may no longer remember why the access existed. Practitioners should treat unowned credentials as breach candidates, not hygiene exceptions.

OAuth grants should be governed as first-class identity assets: Token-based access is not a side effect of application integration. It is an identity relationship that can outlive the user, the vendor, and the original session. When organisations fail to track delegated authorisations, they create a hidden access layer that bypasses normal SSO and PAM controls. The implication is that token governance belongs inside identity lifecycle management.

Service credentials expose the identity blast radius problem: One forgotten credential did not just affect one app. It gave attackers a route into multiple downstream corporate environments through token reuse and trust chaining. That is why the right unit of analysis is not the account, but the blast radius of every credential and delegation. Security teams should prioritise the access paths that can fan out across customers, partners, or internal systems.

Identity programmes still over-index on the primary user object: The article shows how easily organisations disable the person while leaving the machine relationship intact. That is a structural blind spot across IAM, IGA, and PAM, especially where offboarding is still tied to HR events instead of live access graph dependency. The implication is clear: governance must follow the credential, not just the employee record.

From our research:

• 54% of organizations lacked automation for lifecycle management, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• If you want the breach pattern behind abandoned credentials and delegated access, review 52 NHI Breaches Analysis for lifecycle failures that turn stale access into compromise.

What this signals

Residual access is becoming a governance signal, not an edge case: Once organisations accept that access paths outlive the directory record, the programme focus changes from account deprovisioning to access graph closure. The practical test is whether your offboarding process can prove that credentials, grants, and sessions are no longer usable after the human or integration is gone.

Identity blast radius is the concept teams should operationalise next: A single credential can fan out into multiple customer or partner environments through delegated trust chains. That means recertification has to account for downstream reach, not just primary ownership, because the highest-risk access is often the access that can spread beyond the original app boundary.

With 54% of organizations lacking lifecycle automation, according to our 2025 State of NHIs and Secrets in Cybersecurity research, most teams are still dependent on manual cleanup after an employee or integration exits. That lag is where residual access turns into breach exposure.

For practitioners

• Inventory every non-directory access path Build a complete map of local passwords, OAuth grants, API tokens, recovery methods, and persistent sessions for each application. Offboarding cannot be validated until every access path is tied to an owner and a revocation method.
• Treat abandoned credentials as high-risk assets Flag credentials created for test integrations, temporary vendors, or failed projects and subject them to explicit expiry and owner confirmation. If a credential has no active business purpose, revoke it rather than leaving it in a dormant state.
• Tie offboarding to access-path closure Require evidence that the directory disable event removed downstream grants, not just the primary account. Validate closure across SaaS accounts, token stores, and any shared authentication routes before closing the leaver case.
• Review delegated authorisations alongside recertification Include OAuth grants, refresh tokens, and SaaS-to-SaaS authorisations in access reviews so that delegated access is not exempt from governance. A review that only covers user accounts will miss the most persistent paths.

Key takeaways

• The breach reveals a simple but costly failure: organisations often remove the user while leaving the credential alive.
• The scale of the problem is measurable, with lifecycle automation gaps and active post-offboarding tokens showing that stale access is still normal in many environments.
• The control that matters most is complete access-path revocation, including tokens, sessions, and delegated grants, not just directory deprovisioning.

Key terms

• Residual Access: Residual access is any permission, token, account, or data path that continues to work after a user should no longer have access. It is a common failure mode in SaaS-heavy environments because deprovisioning one system does not automatically shut down all downstream connections.
• Orphaned Account: An orphaned account is an identity that remains active without a clear owner or business purpose. These accounts are dangerous because they often escape review, retain unnecessary access, and provide attackers with low-friction entry points into otherwise governed environments.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Access Graph: An access graph is a relationship model that links identities, permissions, data objects, and system interactions. In NHI governance, it helps security teams see the full path from an agent or user to the action it can take, which is more useful than isolated account reviews.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of the Klue attack chain, including how the abandoned test credential reached customer Salesforce environments.
• A deeper walkthrough of residual access types, including local passwords, OAuth refresh tokens, shared accounts, and persistent sessions.
• Specific examples of why disabling the IdP account does not remove downstream SaaS access.
• The vendor's four-pillar approach to discovery, risk analysis, universal SSO, and lifecycle management.

👉 The full Unixi article covers the attack chain, residual access model, and lifecycle gap in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.