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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Residual credentials, orphaned accounts, and unmanaged OAuth access remain usable after ownership ends, with Klue as the clearest example.
Why it matters: IAM and NHI teams need to treat revocation as a lifecycle problem, because disabling a user without removing every downstream authentication path leaves a live attack surface.
Context
Residual access is what happens when an identity, credential, token, or delegated authorization keeps working after the person, project, or integration that created it should no longer exist. In IAM terms, the problem is not authentication failure but incomplete lifecycle closure across systems that still trust the old credential.
Unixi frames the issue through a real breach path in which a forgotten service credential survived after a test integration was abandoned. That matters for NHI governance because service accounts, OAuth grants, and persistent sessions often sit outside the deprovisioning path that removes a human user from the directory.
The article’s central claim is that offboarding is now a graph problem, not a single account action. If security teams only disable the IdP record, they can leave local logins, tokens, browser sessions, and app-to-app grants untouched.
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 create breach risk even without malware or phishing?
A: They preserve legitimate-looking access. If a real credential still works, the system may see a valid login rather than an attack, which bypasses many detection cues. That makes orphaned credentials especially dangerous in SaaS and NHI estates where ownership can disappear while the authentication path remains intact.
Q: How do security teams know whether offboarding is actually working?
A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.
Q: What is the difference between offboarding a user and revoking delegated access?
A: User offboarding removes the person from the directory or workforce system. Revoking delegated access removes the tokens, grants, sessions, and machine credentials that can keep working after the person is gone. In practice, both are required because a valid delegation can outlive the human identity that created it.
Technical breakdown
Why residual access survives directory offboarding
Modern access is distributed across federation, local authentication, OAuth grants, API tokens, shared accounts, and persistent sessions. Disabling the central identity provider account only removes one route into the application estate. If an app still accepts a local password, a refresh token, or a saved session cookie, the credential remains valid until it is explicitly revoked or expires. That is why the access graph matters more than the directory record. For NHI programmes, the failure is usually discovery and revocation coverage, not authentication strength alone.
Practical implication: Map every application to its independent authentication paths before treating offboarding as complete.
How orphaned credentials become legitimate-looking access
A residual credential is dangerous because it often looks correct to the receiving system. The username, password, token, or delegated grant belongs to a real account, so there may be no failed-login burst, no MFA prompt, and no obvious anomaly at the point of use. That makes detection harder than with sprayed passwords or active phishing. The risk increases when ownership is lost and the credential no longer ties back to a live employee, project, or vendor relationship. In practice, the control gap is ownership, not only secrecy.
Practical implication: Require every active credential to have an accountable owner and a documented business purpose.
Why OAuth grants and service credentials outlive the user
OAuth grants and service credentials are delegated trust objects, not just login artifacts. They can continue authorizing API access, customer data access, or SaaS-to-SaaS actions even after the original user leaves or the integration is abandoned. In this article, the Klue example shows that an abandoned test integration can still serve as a durable entry point years later. That persistence is what turns forgotten access into breach-grade risk: the trust relationship survives the organisational decision to stop using it.
Practical implication: Track delegated access separately from human accounts and revoke it on the same lifecycle trigger.
Threat narrative
Attacker objective: The attackers sought to pivot from one forgotten credential into downstream customer environments and steal data through legitimate-seeming access.
- Entry occurred when an attacker used a forgotten service credential that had remained active after a test integration was abandoned.
- Credential abuse continued through stolen OAuth tokens tied to Klue customers, allowing the attackers to move through trusted application access rather than force authentication.
- Impact followed when those tokens were used to enter dozens of Salesforce environments, including LastPass, exposing customer data and expanding the breach scope.
Breaches seen in the wild
- LastPass breach 2022: An attacker used AWS access keys and decryption keys from a DevOps engineer's corporate vault to copy LastPass customer vault backups.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Residual access is a lifecycle failure, not an authentication failure. The breach condition in this article is not that attackers broke a password system. It is that an access path remained valid after ownership ended, which means the governance problem sits in offboarding, discovery, and revocation. Identity programmes that stop at user disablement are not closing the trust relationship they created. The practitioner conclusion is simple: if access can still be used, it has not been removed.
Offboarding must cover every authentication path, not just the IdP record. Modern SaaS and NHI estates create parallel routes through local passwords, refresh tokens, browser sessions, and delegated grants. That means a complete lifecycle model has to ask where access lives, who can revoke it, and what survives directory deactivation. The operational lesson is to treat revocation as graph-wide, not account-specific.
Orphaned credentials create an ownership vacuum that governance tooling often misses. A credential without an active owner becomes hard to classify, harder to review, and easiest to forget. That is why residual access turns into breach-grade risk even without zero-days or malware. The NHI control issue is not just exposure but unassigned accountability, and that makes orphan detection a core governance requirement.
Residual credential trust debt: a useful way to describe the problem is the security debt created when delegated access outlives the business reason for it. The article shows that forgotten credentials can remain both technically valid and organisationally invisible for years. In NHI terms, that means the trust model is carrying liabilities that no one is servicing. Practitioners should read this as evidence that lifecycle closure is a control objective, not an administrative cleanup task.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Residual access is the hidden layer in identity governance: the directory may show a leaver as disabled while local passwords, refresh tokens, and app-specific grants still remain live. That mismatch is why lifecycle programmes need revocation coverage across the full access graph, not just the master identity record.
Unassigned ownership is what turns NHI into breach-grade exposure: once a credential, token, or integration no longer maps to an active owner, the organisation loses both accountability and practical revocation. The operational response is to make ownership and revocation status visible together, not in separate systems.
For practitioners
- Map all residual access paths Inventory local passwords, OAuth grants, service credentials, API tokens, recovery addresses, and persistent sessions for each application, then tie each one to a current owner and business purpose.
- Revoke access outside the IdP Build a revocation workflow that reaches applications with direct authentication and delegated tokens, not only the central directory entry.
- Flag orphaned credentials as governance exceptions Create a review queue for credentials that lack a live owner, active project, or approved integration so they cannot remain in service by default.
- Separate termination from revocation Treat employee exit, project closure, and integration retirement as triggers that must also close every related credential and token path.
Key takeaways
- Residual credentials are dangerous because they can keep authenticating after the owning user, project, or integration has been retired.
- The Klue example shows that a forgotten service credential can become a real breach entry point without malware, exploitation, or a phishing chain.
- The control that matters most is lifecycle closure across every authentication path, including tokens, sessions, and delegated grants.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on access that remained active after the owner or integration was gone. |
| NHI-03 — Vulnerable Third-Party NHI | The forgotten credential enabled downstream access through trusted SaaS relationships. | |
| NHI-07 — Long-Lived Secrets | Residual credentials and tokens stayed valid long enough to become breach entry points. | |
| Recommendation — Audit offboarding paths so every credential, grant, and session is revoked when ownership ends. Review third-party access paths and revoke delegated credentials when integrations are abandoned. Replace durable secrets with time-bound credentials and shorten the window for reuse. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attackers abused a valid credential and then moved into downstream SaaS environments. |
| Recommendation — Map residual credential abuse to credential access and lateral movement detections in your telemetry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about incomplete revocation of entitlements and authorizations. |
| Recommendation — Validate that entitlement removal covers direct logins, delegated access, and stale sessions. | ||
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 Credential: A secret, token, or service account password that remains active and valid after the NHI it was issued to has been decommissioned, or after the person or system responsible for it has left the organisation.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
- 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.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org