TL;DR: Forgotten service credentials, OAuth grants, and orphaned accounts can still authenticate long after the original owner, project, or integration is gone, as Unixi’s analysis of the Klue breach shows. The real failure is governance drift: identity programmes often disable the user but leave the access path intact, which makes residual access a standing attack surface.
NHIMG editorial — based on content published by Unixi covering the Klue breach and residual access: residual credentials, OAuth tokens, and orphaned SaaS access
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.
Questions worth separating out
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.
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.
Q: What should teams get wrong about offboarding in SaaS environments?
A: They often assume disabling the primary account is enough.
Practitioner guidance
- 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.
- 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.
- Tie offboarding to access-path closure Require evidence that the directory disable event removed downstream grants, not just the primary account.
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.
👉 Read Unixi's analysis of the Klue breach and residual access risk →
Residual access and orphaned credentials: what IAM teams miss?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Residual credentials and orphaned access remain breach-grade risk