Access that should end when a person leaves a role, team, or organisation but may continue if offboarding is incomplete. It is a governance issue across human and NHI programmes because the business reason for access has expired even if the credential still works.
Expanded Definition
Leaver access is the access that should be removed when a person exits a role, team, supplier relationship, or organisation, but sometimes remains active because offboarding is delayed or incomplete. In NHI management, the same problem appears when a human owner departs but service accounts, API keys, or automation credentials are left behind with no accountable steward.
The concept is broader than simple account deletion. It includes entitlement cleanup, credential rotation, token revocation, and verifying that the departed person can no longer approve, reset, or inherit access paths. In mature IAM and NHI programmes, leaver access is treated as a lifecycle control, not a helpdesk task. The OWASP Non-Human Identity Top 10 frames this as part of identity lifecycle risk, while NHI Management Group highlights how often long-lived credentials survive normal business changes in the Ultimate Guide to NHIs.
The most common misapplication is assuming a terminated employee record automatically revokes every downstream credential, which occurs when offboarding is limited to directory deletion and ignores delegated access, shared secrets, and non-human dependencies.
Examples and Use Cases
Implementing leaver access rigorously often introduces coordination overhead between HR, IAM, application owners, and platform teams, requiring organisations to weigh faster onboarding and flexible access against the cost of timely revocation and verification.
- A developer leaves a team, but their SSH key still unlocks a build server because the deployment pipeline was never mapped to the offboarding workflow.
- A contractor exits a project, yet their API token continues to call production endpoints because the token was issued outside the central identity system.
- A manager changes departments, but approval rights in a cloud platform remain intact, allowing outdated authority to persist after the business need has ended.
- An engineer who owned a service account departs, and the account keeps working because no one has been assigned stewardship or scheduled rotation.
These cases are not merely administrative mistakes. They show how leaver access becomes a hidden control gap when access is distributed across SaaS tools, CI/CD systems, and machine identities. The same lifecycle discipline described in the Ultimate Guide to NHIs applies when access is embedded in automation rather than a user mailbox. For implementation patterns around identity binding and machine trust, OWASP Non-Human Identity Top 10 is a useful external reference.
Why It Matters in NHI Security
Leaver access is dangerous because expired business authority often outlives the person who exercised it. In human IAM, that creates residual privilege. In NHI programmes, it is worse because the credential may remain valid even after the original operator has gone, leaving service accounts, secrets, and automations without an accountable owner. NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often revocation is still treated as optional rather than mandatory.
When leaver access is not governed, attackers can exploit stale privileges, auditors find unexplained exceptions, and incident responders inherit systems that no one can confidently attest to. The issue also undermines Zero Trust because trust is no longer continuously revalidated. Organisations typically encounter the full consequence only after a departure, breach investigation, or failed audit, at which point leaver access becomes operationally unavoidable to address.
The problem becomes most visible after a compromise or termination event forces teams to ask which credentials still work, who owns them, and whether any automation is effectively orphaned.
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-02 | Covers lifecycle cleanup and secret revocation when identities or owners leave. |
| NIST CSF 2.0 | PR.AA-04 | Supports access revocation and identity lifecycle governance after role changes or departure. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous reassessment of whether access should still be valid. |
Revalidate trust and entitlement state after departure events before allowing any continued access.
