Accountability usually sits across HR, IT, security, and application owners, but security leadership should own the control objective. If an identity still has access after departure, someone must be able to show where the process failed and which systems were not covered. Governance needs clear ownership and audit evidence.
Why This Matters for Security Teams
Offboarding failures are not just an HR cleanup issue. They are a control failure that can leave service accounts, API keys, OAuth grants, tokens, and SaaS entitlements active long after employment ends. The accountability question matters because unresolved access gaps create audit exposure, incident response ambiguity, and a weak chain of custody for identity lifecycle controls. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which shows how often the ownership model breaks down in practice.
Security teams should treat offboarding as an end-to-end identity risk, not a ticket that closes when one directory account is disabled. The real question is which owner can prove that every downstream system, integration, token, and delegated permission was removed or expired. The OWASP Non-Human Identity Top 10 is useful here because it frames lifecycle and privilege failures as a recurring attack path, not an edge case. In practice, many security teams encounter lingering access only after an audit, a credential leak, or a post-incident review has already exposed the gap.
How It Works in Practice
Accountability for offboarding should be split between operational owners, but security leadership owns the control objective: no access remains beyond approved termination. HR typically triggers the event, IT or IAM executes directory disablement, application owners remove app-specific access, and security validates that the process covers all systems. That shared model works only if one function is explicitly accountable for the evidence trail.
Practically, mature teams define a revocation workflow that includes identity disablement, token invalidation, secret rotation, session termination, and confirmation from application owners for exceptions. The lifecycle must cover both human and non-human identity touchpoints because terminated employees often leave behind delegated access, shared mailbox permissions, CI/CD credentials, and cloud roles. NHIMG’s NHI Lifecycle Management Guide is a strong reference for mapping those lifecycle handoffs across discovery, ownership, rotation, and deprovisioning.
- Assign a single control owner for offboarding evidence, even when execution is distributed.
- Require application owners to attest that app-native access was removed.
- Validate token revocation and secret rotation, not just directory disablement.
- Track exceptions with expiry dates and compensating controls.
For governance teams, the right test is whether they can show who approved revocation, when it occurred, and which systems confirmed closure. That aligns with current guidance from identity governance programs and the operational emphasis in the Top 10 NHI Issues. These controls tend to break down in highly integrated SaaS and cloud environments because access is often granted through nested groups, service links, and inherited roles that the offboarding ticket never directly touches.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance rapid employee exit handling against complete revocation coverage. That tradeoff becomes more visible in mergers, contractor-heavy environments, and distributed SaaS estates where no single team controls all entitlement paths. There is no universal standard for this yet, but current guidance suggests the control owner should be the function best positioned to demand evidence, challenge exceptions, and escalate unresolved access.
Edge cases usually involve shared accounts, long-lived API keys, delegated admin roles, and machine identities tied to a former employee’s workflow. In those cases, the question is not only who disabled the person’s account, but who owned the dependent access model. If a former employee’s access persists because an application owner never removed an embedded credential, accountability should still terminate at the control owner who failed to ensure downstream verification. The 52 NHI Breaches Analysis shows how often lifecycle gaps become breach pathways when identity hygiene is treated as a one-time event rather than a monitored process.
Security leadership should therefore require documented ownership, periodic access recertification, and audit-ready evidence for every offboarding path. In environments with autonomous service accounts or highly dynamic cloud permissions, that evidence model becomes the only reliable way to prove the organisation did not leave access behind.
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-03 | Directly addresses lifecycle revocation and stale NHI access after offboarding. |
| NIST CSF 2.0 | PR.AC-4 | Covers access authorization and removal across systems after role or employment changes. |
| NIST AI RMF | Governance and accountability apply to automated or agentic identities that persist beyond departure. |
Verify every offboarding path disables identities, revokes tokens, and rotates exposed secrets.
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
