Why do IAM tools still leave access risk behind after offboarding?

Why This Matters for Security Teams

Offboarding risk is not just a help desk cleanup problem. When IAM only disables the primary user account, any surviving API key, service principal, delegated token, or cloud role can keep working long after the person is gone. That creates a gap between “employment ended” and “all identity paths revoked,” which is exactly where attackers look for persistent access. The NHI Lifecycle Management Guide treats this as a lifecycle failure, not a single account event, and the OWASP Non-Human Identity Top 10 frames stale non-human access as a predictable control gap.

This matters because modern environments rarely store access in one place. SaaS apps, CI/CD systems, cloud control planes, and internal databases often each hold their own credentials or delegated permissions, so a clean HR termination does not equal clean technical revocation. In practice, many security teams discover residual access only after a former identity is already being reused, rather than through intentional revocation testing.

How It Works in Practice

Effective offboarding has to be identity-centric, not account-centric. The goal is to discover every live permission path tied to the person or workload, then revoke or rotate each one in a controlled sequence. That usually includes directory deprovisioning, token invalidation, API key rotation, certificate revocation, removal from groups and RBAC roles, and shutdown of any delegated access to cloud or SaaS services.

Good practice also requires distinguishing human access from NHI access. A departing employee may have created automation, scripts, or service accounts that outlive the account itself. Those NHIs need separate inventory, ownership, and expiry handling. NIST’s Cybersecurity Framework 2.0 reinforces the need for governed asset and identity lifecycle controls, while NHIMG’s Lifecycle Processes for Managing NHIs shows why revocation must reach every connected system, not just the primary directory record.

• Inventory all entitlements before termination, including cloud roles, local app tokens, and service accounts.
• Revoke or rotate secrets that cannot be centrally disabled.
• Verify downstream systems have actually stopped accepting the identity.
• Record ownership so shared or orphaned credentials do not survive staff changes.

Where this breaks down is in environments with manually managed secrets, undocumented integrations, or shared automation accounts, because no single IAM tool can reliably find every hidden credential path.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational friction, requiring organisations to balance rapid termination with business continuity. That tradeoff becomes especially visible when a role owns critical pipelines, embedded devices, or customer-facing automations that cannot simply be switched off without service impact.

Best practice is evolving for these cases. Current guidance suggests separating access removal from service continuity by transferring ownership, reissuing credentials, or replacing human-tied automations with governed service identities. This is where NHI governance becomes essential: if a script, bot, or integration was built under a person’s account, the offboarding workflow must treat it as an identity transition event, not just a personnel exit.

For teams prioritising remediation, the most useful starting point is usually the Top 10 NHI Issues, because it highlights stale credentials, orphaned ownership, and duplicated secrets as recurring causes of residual access. The issue is often worse than expected: the 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which is a strong signal that revocation processes are still not reaching the full identity surface.

That is why mature programmes test offboarding end to end, including the systems most likely to be forgotten, rather than assuming directory disablement closes the risk.

Related resources from NHI Mgmt Group

• Why do revoked sessions still matter after a password reset or offboarding event?
• Why do ephemeral credentials still leave risk in machine access models?
• When does ephemeral access still leave too much risk for AI agents?
• When does just-in-time access reduce risk, and when does it still leave exposure?