They persist when the deprovisioning chain breaks silently. A connector can fail, an application may never have been automated, or a manual step can be skipped. Because the credential still works, the access often looks normal until someone uses it. That makes post departure access especially dangerous, since it creates valid live access with no obvious anomaly at the point of login.
Why This Matters for Security Teams
Offboarding is not just an HR process. It is a control point where identity, access, secrets, and application ownership must all be removed together. When one step fails, inactive employee accounts and tokens can remain valid long after separation, creating a live access path that looks legitimate at login. NIST Cybersecurity Framework 2.0 treats identity management as a core governance and protection function, not a cleanup task after the fact.
The practical risk is that dormant access blends into normal traffic until it is used for data access, token replay, mailbox forwarding, API calls, or lateral movement. NHIMG research on the 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, which shows how often deprovisioning breaks at the edge of the stack. In practice, many security teams encounter this only after an audit, incident, or helpdesk escalation reveals the account was never fully disabled.
How It Works in Practice
The root cause is usually fragmentation. Modern offboarding spans the directory, SSO, SaaS apps, cloud platforms, ticketing systems, secrets stores, and shadow services that were never fully inventoried. If the identity provider is disabled but application tokens are not revoked, access may continue. If a service account is tied to an employee-created workflow, the account can outlive the employee and still authenticate quietly.
Effective offboarding needs a deterministic sequence, not a best-effort checklist. That usually means:
- Disable the primary user account and terminate active sessions immediately.
- Revoke refresh tokens, API keys, certificates, and app-specific tokens.
- Transfer ownership of shared mailboxes, code repos, SaaS assets, and automation jobs.
- Confirm deprovisioning across connected apps, not only in the directory.
- Log and verify completion so exceptions are visible before they become dormant access.
This is why the NHI Lifecycle Management Guide matters even for employee identities: the same lifecycle discipline applies when a human departure leaves behind machine-consumable credentials. NIST SP 800-53 Rev. 5 also reinforces the need for account management, access revocation, and traceable control execution as part of routine security operations. A related pattern appears in the Top 10 NHI Issues, where residual credentials persist because the owning system was never fully mapped. These controls tend to break down when a departed employee had access to multiple SaaS tools and custom integrations because each service maintains its own token state and revocation logic.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance speed of separation against the need for complete revocation. That tradeoff becomes sharper in large environments where employees use multiple personas, delegated access, or self-service automation.
Best practice is evolving for edge cases such as shared accounts, break-glass access, contractor transitions, and long-lived service tokens tied to a person rather than a workload. Guidance suggests treating these as exceptions that require explicit ownership transfer, short token lifetimes, and post-departure validation. When the departed user also maintained secrets in code, chat, or ticketing systems, removal from HR and IAM is not enough. The Guide to the Secret Sprawl Challenge is relevant here because exposed credentials often survive in places offboarding does not touch. For control design, NIST CSF 2.0 and NIST SP 800-53 Rev. 5 both support continuous verification rather than assuming deactivation succeeded.
For security teams, the highest-risk cases are usually the least visible ones: a legacy SaaS tenant, a manually provisioned token, or a workflow that nobody documented before departure. That is why residual access remains common even in mature programmes.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Residual tokens after offboarding are a lifecycle revocation failure. |
| NIST CSF 2.0 | PR.AC-1 | Access control and identity governance cover post-departure access removal. |
| NIST SP 800-63 | Digital identity assurance depends on timely deactivation of authenticators. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification instead of trusting stale access. |
| NIST AI RMF | AI RMF governance supports accountability for lifecycle-controlled access. |
Verify every identity and token is disabled across connected systems before closure.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Why do orphaned service accounts and tokens create so much risk after offboarding?
- How can organisations reduce the risk of stale API keys and machine tokens?
- Why do contractors and partners create more offboarding risk than many employee accounts?
