Residual access persists after the leaver event is complete, especially in systems that were granted access informally or outside the upstream IGA workflow. That creates audit gaps, unnecessary standing access, and a larger attack surface. The problem is not the termination policy on paper, but the scope it actually reaches.
Why This Matters for Security Teams
Termination failures are not just a human offboarding problem. When access was granted out of band, through a script, a direct API key, a shared vault entry, or a temporary exception, the normal leaver workflow may never see it. That leaves residual access active after employment ends, after a contractor rolls off, or after a service account is no longer needed. The result is a control gap between policy intent and actual reach.
This matters because out-of-band access often bypasses the ownership records that IAM and IGA depend on. Security teams may believe access has been removed, while credentials, tokens, or delegated permissions remain valid in downstream systems. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why termination coverage is still so fragile. The issue is closely related to the risks described in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.
In practice, many security teams encounter lingering access only after an audit, incident, or privilege review has already exposed it.
How It Works in Practice
A complete termination process has to remove access wherever it exists, not just where the HR or IGA workflow thinks it exists. For non-human identities, that means tracing entitlements across vaults, CI/CD systems, cloud consoles, SaaS admin panels, service meshes, and local configuration stores. The control objective is simple: no credential, token, certificate, or delegated role should remain usable after the access owner is retired or the task ends.
Current guidance suggests treating offboarding as an inventory and revocation problem first, then a workflow problem second. The NHI Lifecycle Management Guide is useful here because lifecycle state has to drive revocation, not just HR status. In practice, teams should combine authoritative identity records with discovery of shadow access. That usually includes:
- Revoking API keys, SSH keys, certificates, refresh tokens, and vault secrets tied to the leaver.
- Closing direct grants created outside standard provisioning, including manual console changes and break-glass exceptions.
- Checking downstream systems for copied secrets, cached tokens, and service account impersonation paths.
- Rotating shared secrets if they were exposed to the departed person or the former workflow.
- Logging proof of revocation for audit and forensics.
Where possible, offboarding should be paired with just-in-time access and short-lived credentials so that termination is a containment event rather than a cleanup exercise. For broader lifecycle failure modes, the Top 10 NHI Issues and OWASP guidance both emphasize that unmanaged credentials often survive longer than the systems that created them. These controls tend to break down when access was created in embedded tooling or third-party platforms that do not report back to the central identity system.
Common Variations and Edge Cases
Tighter termination coverage often increases operational overhead, requiring organisations to balance revocation speed against the risk of disrupting active workloads. That tradeoff is most visible with shared service accounts, vendor-managed integrations, and automation jobs that are not mapped cleanly to a single owner. Guidance is still evolving on how much confidence is enough when an access path is indirect, but the safest assumption is that any untracked credential may still be live.
One common edge case is access that was never in the upstream termination workflow at all. For example, a developer may have created a token in a local tool, copied a certificate into a build pipeline, or stored a secret in a personal automation script. Another edge case is delegated authority that survives the individual leaver event, such as group memberships, app roles, or token minting rights. In those cases, removing the person does not remove the capability.
Residual risk is also higher when external parties are involved. NHIMG notes that 92% of organisations expose NHIs to third parties, which makes offboarding dependent on both internal controls and supplier discipline. If a platform cannot confirm revocation, then manual validation and post-termination rotation become necessary. There is no universal standard for this yet, but best practice is to verify removal in the systems where access was actually used, not just where it was requested. The failure mode is clearest when an old secret remains valid in a downstream system that never consumed the central termination event.
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 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-05 | Out-of-band access is a lifecycle revocation gap for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Termination must remove access beyond the primary IAM path. |
| NIST AI RMF | GOVERN | Termination gaps in agentic or automated access create unmanaged accountability risk. |
Discover every secret and token, then revoke and rotate anything not covered by standard offboarding.
