Accountability usually sits with both the business owner of the identity and the teams responsible for provisioning and deprovisioning. In regulated environments, that includes IAM, IGA, security operations, and the application owner. If access remains active after departure, the control owner failed to enforce the lifecycle boundary.
Why This Matters for Security Teams
When a former worker still has access to sensitive records, the issue is not just a missed checkbox. It is a lifecycle failure that crosses identity governance, application ownership, and operational control. The accountable parties are the business owner who approved access, the IAM or IGA team that executed deprovisioning, and the application or data owner who should verify removal. OWASP’s Non-Human Identity Top 10 is a useful reminder that identities with lingering access create lasting exposure when offboarding is incomplete.
In practice, retained access often appears after a termination event, contractor end date, or role change, especially when legacy applications bypass centralized workflows. That is why NHI Management Group consistently emphasizes lifecycle visibility in the Ultimate Guide to NHIs. The same governance gap shows up in human and non-human identities alike: if access is not revoked at the source, downstream controls cannot compensate. In practice, many security teams discover stale access only after an audit finding, not through a reliable offboarding control.
How It Works in Practice
Accountability is usually shared, but responsibility should be explicit. The business owner defines whether the worker should still have access, IAM or IGA enforces deprovisioning, and the application owner confirms that access was actually removed. For records systems, data owners should validate that permissions, group memberships, sharing links, and delegated admin paths are also cleared. Where access is federated, the identity provider and the target application both need closure checks, because removing one layer does not always remove the other.
A practical offboarding workflow usually includes:
- Immediate disablement of primary credentials and sessions
- Removal from groups, roles, and privileged access paths
- Revocation of tokens, API keys, certificates, and recovery factors
- Verification that application-specific entitlements are removed
- Logging and evidence capture for audit and incident response
This is especially important because NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification in the Ultimate Guide to NHIs — Key Challenges and Risks. That delay matters because stale access often survives in service layers, cached tokens, and manually maintained exceptions. Current guidance from OWASP Non-Human Identity Top 10 and identity governance practice is to make revocation observable, not assumed. These controls tend to break down when old accounts exist outside centralized IAM, because the offboarding owner cannot see or enforce the last mile.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance fast deprovisioning against system compatibility and auditability. The basic answer changes when the former worker was a contractor, a shared account holder, a delegated admin, or the sponsor of a non-human workflow. In each case, the accountable business owner may differ, but the control expectation does not: access must end when the relationship ends. Where there is no universal standard for this yet, best practice is evolving toward explicit ownership matrices and automated evidence collection.
Two common edge cases deserve attention. First, some records platforms retain access through inherited permissions even after direct membership is removed, so the reviewer must check nested groups and application-specific sharing models. Second, modern environments may use service identities or automation tokens tied to a departing worker’s workflow; in those cases, the question becomes whether the credential belongs to the person, the process, or the business function. The 52 NHI Breaches Analysis shows how lingering identity paths can persist well after the original operator leaves. For control design, NIST’s OWASP Non-Human Identity Top 10 aligns with a simple rule: assign one owner for revocation, one verifier for closure, and one audit trail for proof.
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-01 | Stale access after departure is a lifecycle and revocation failure. |
| NIST CSF 2.0 | PR.AA-2 | Identity lifecycle control requires timely removal of access rights. |
| NIST AI RMF | GOVERN | Accountability for access decisions depends on clear governance ownership. |
Define ownership, approval, and verification roles for every identity lifecycle event.
