Accountability sits with the identity and IT governance function that owns the lifecycle process, not with the spreadsheet itself. The organisation needs a named control owner, explicit revocation steps, and evidence that leaver access is removed before the account remains active in downstream systems.
Why This Matters for Security Teams
Missed revocation after offboarding is not a paperwork error. It is a control failure that leaves active access in place after the human relationship has ended, and in NHI-heavy environments it often affects service accounts, API keys, tokens, and automation credentials as much as employee accounts. The issue sits at the intersection of identity governance, IT operations, and application ownership, which means ambiguity about ownership is usually the first breakdown.
NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That gap matters because revocation is only real when downstream systems actually remove entitlements, not when a ticket is closed. The control owner needs to be able to prove completion, not just intent. Current guidance from the OWASP Non-Human Identity Top 10 treats lifecycle weakness as a primary exposure path, especially where credentials outlive the account event.
In practice, many security teams encounter continued access only after a former user, contractor, or automation path is already being abused, rather than through intentional offboarding verification.
How It Works in Practice
Accountability should be assigned to the function that owns identity lifecycle governance, usually identity, IAM, or IT governance, with application teams responsible for executing the application-specific revocation steps. That split matters because directory disablement does not automatically invalidate all issued tokens, refresh secrets, SSH keys, cloud roles, or application-local permissions. A named control owner should maintain the leaver workflow, define required evidence, and reconcile the identity source of truth against downstream systems.
Operationally, strong programs use a closure sequence that includes HR-triggered notification, access inventory, revocation execution, and verification. For NHI and agentic workloads, the same logic applies to workload identities, because a token or certificate can continue to function even after the human owner has left. NHIMG’s NHI Lifecycle Management Guide and the broader lifecycle processes for managing NHIs emphasize that revocation must be measured as a completed state, not a workflow started in good faith.
- Define one accountable owner for the leaver process and one backup approver for exceptions.
- Map every offboarding trigger to the systems that issue or cache credentials.
- Require evidence of revocation, such as token invalidation logs, key deletion records, or role removal reports.
- Reconcile HR exit data against identity, cloud, SaaS, and CI/CD systems before closure.
NIST guidance on identity assurance and least privilege aligns with this model, but the exact evidence standard varies by environment. These controls tend to break down when legacy applications, shared service accounts, or manually managed cloud credentials exist outside the central IAM workflow because revocation cannot be enforced consistently across those paths.
Common Variations and Edge Cases
Tighter revocation control often increases operational overhead, requiring organisations to balance speed of offboarding against the cost of full coverage and verification. That tradeoff becomes visible in acquisitions, contractor-heavy teams, and environments with many local admins, where the fastest path is rarely the most complete one.
There is no universal standard for this yet, but current guidance suggests treating exceptions as temporary and auditable. Shared accounts are the hardest case because accountability blurs between the account owner, the platform owner, and the business team that depends on the credential. For automation, the same problem appears when a pipeline or bot account is “owned” by a person who has already left. In those cases, revocation should be paired with replacement ownership, not just deletion.
Security teams should also distinguish between human offboarding and NHI lifecycle closure. A former employee’s access may be removed, but a connected NHI can remain active and continue to authenticate. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis show how lifecycle gaps and exposure patterns often persist well after the employee record is closed. Where service accounts, long-lived API keys, or delegated tokens exist, revocation ownership must extend beyond HR exit processing to the system owner who can actually invalidate the credential.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Revocation and lifecycle failures are a core NHI exposure path. |
| NIST CSF 2.0 | PR.AC-4 | Leaver access removal maps directly to access management and least privilege. |
| NIST SP 800-63 | Identity lifecycle assurance supports proof that revoked access is no longer valid. |
Tie offboarding to authoritative identity events and confirm downstream credentials are disabled or expired.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
