Accountability usually sits across HR, IT, and the application owner, but the security team owns the control design. If access survives departure, the programme failed to assign clear revocation ownership, confirm closure, or enforce cross-system checks. Identity governance should define one accountable owner for leaver state closure.
Why This Matters for Security Teams
Leaver access is not just an HR hygiene problem. It is a control failure that turns former employees into active identities after the employment relationship has ended, creating unnecessary exposure across SaaS, cloud, and code systems. The real issue is accountability for closure: someone must own revocation, verify it completed everywhere, and detect exceptions before they become incidents. NHI Management Group’s Ultimate Guide to NHIs frames this as an identity lifecycle problem, not a one-time deprovisioning task.
Security teams often inherit the blame when access persists, but the operational gap usually sits between HR termination events, IT account disablement, and application-owner confirmation. In practice, identity sprawl means one departure can leave behind SSO access, cloud keys, service tokens, shared admin accounts, and cached sessions. OWASP’s OWASP Non-Human Identity Top 10 is useful here because it reinforces that unmanaged credentials are a systemic risk, not a one-system defect. In practice, many security teams encounter lingering access only after an audit finding or post-incident review, rather than through intentional leaver-state verification.
How It Works in Practice
Accountability should be assigned to a single control owner for leaver-state closure, even when execution is distributed. Best practice is to separate responsibility for initiation, execution, and verification so no step is assumed to be complete without evidence. HR typically initiates the termination event, IT or IAM automation disables primary accounts, and the application owner confirms access removal for business systems that do not inherit central controls. Where organisations mature this process, the security function defines the control standard and monitors exceptions rather than manually chasing every account.
Practical leaver control usually includes:
- Automatic trigger from HR or contractor offboarding into IAM and PAM workflows.
- Removal of interactive access, API keys, tokens, and session grants, not just directory accounts.
- Verification against cloud platforms, code repositories, ticketing tools, and shared admin paths.
- Escalation rules when an application cannot support automated deprovisioning.
- Evidence capture showing who approved closure and when it was confirmed.
This is where 52 NHI Breaches Analysis matters operationally: identity failures often involve missed revocation, stale credentials, and poor ownership boundaries rather than sophisticated exploitation. For implementation guidance, CISA’s Zero Trust Maturity Model supports continuous validation, while NIST’s Zero Trust Architecture reinforces that access should be re-evaluated rather than trusted indefinitely. These controls tend to break down in environments with legacy applications, shared admin accounts, or manually managed cloud keys because there is no reliable system of record for final access removal.
Common Variations and Edge Cases
Tighter leaver controls often increase operational overhead, requiring organisations to balance revocation speed against application complexity and business continuity. That tradeoff is especially visible when a former employee owns critical workflows, external vendor relationships, or privileged automation that cannot simply be deleted without replacement planning. Current guidance suggests that accountability should still remain singular, but execution may need coordinated exceptions with time limits and documented compensating controls.
There is no universal standard for this yet in edge cases such as shared service accounts, joint admin ownership, or non-federated business tools. In those situations, the accountable owner must define what proof of removal is acceptable, how long temporary access may persist, and who signs off when a system cannot support immediate revocation. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is particularly relevant because leaver issues often overlap with broader credential sprawl and fragmented ownership. The practical lesson is that former-employee access is rarely a single missed checkbox; it is usually a governance gap where closure was assumed, not proven.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Leaver access often persists because credentials are not revoked across all NHI surfaces. |
| NIST CSF 2.0 | PR.AA-01 | Identity lifecycle control is central to removing access when employment ends. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires continuous identity validation, not assumed post-exit trust. |
Treat leaver revocation as continuous identity revalidation and block access until confirmed removed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
