Ownership should sit with the identity governance process, not with a single team acting alone. HR, IAM, application owners, and compliance all have roles, but the control must have one accountable workflow that can prove access was removed across systems and identities.
Why This Matters for Security Teams
deprovisioning is not just an HR exit task. It is an access-removal control that has to close every path an employee, contractor, or vendor might still use after separation. That means identity governance, IAM, application owners, HR, procurement, and compliance all have a stake, but only one accountable workflow should own the outcome. NIST Cybersecurity Framework 2.0 treats identity lifecycle control as a governance discipline, not a single-team activity.
For NHI-heavy environments, the same logic applies to service accounts, API keys, and delegated automation. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes leaving access behind a predictable failure mode rather than an edge case. The operational risk is not limited to the named person departing. Shared accounts, forgotten SaaS permissions, and embedded secrets can outlive the employment relationship and remain usable long after the exit date. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs places lifecycle control at the centre of this problem.
In practice, many security teams encounter residual access only after a contractor has already logged back in or a vendor token has been used to move laterally.
How It Works in Practice
Effective ownership means the identity governance process orchestrates the exit, while each supporting team performs a defined step inside the same workflow. HR or procurement triggers the event, IAM disables the primary identity, application owners remove application-specific entitlements, and compliance verifies that evidence exists for each closure. The key is not who touches the ticket, but who is accountable for proving the identity is no longer active anywhere.
For human users, this usually includes directory disablement, session termination, MFA reset where appropriate, and revocation of privileged access. For vendors and contractors, it must also include SaaS accounts, federated access, VPN profiles, shared mailbox access, portal permissions, and any API keys or certificates issued for the engagement. The NHI Lifecycle Management Guide is useful here because it frames lifecycle control as a repeatable sequence: detect, authorise, revoke, validate, and record. That sequence matters because removal is not complete until downstream systems confirm it.
- HR or vendor management records the exit date and reason.
- IAM revokes directory, SSO, and privileged access first.
- Application owners remove app-local roles, tokens, and shared secrets.
- Security validates that active sessions, API keys, and certificates are no longer usable.
- Compliance retains evidence of revocation for audit and incident response.
Best practice is to treat the workflow as a single control with multiple executors, not as a set of separate handoffs. That makes it easier to prove completion and identify gaps before a former insider or supplier retains access. These controls tend to break down when access is fragmented across SaaS admin consoles, local app role stores, and manually managed secrets because no single system can confirm the full revocation state.
Common Variations and Edge Cases
Tighter deprovisioning often increases operational overhead, requiring organisations to balance rapid access removal against business continuity and support workload. That tradeoff is especially visible when a departing employee also owns critical production systems or when a vendor account supports time-sensitive operations. The answer is not to weaken control, but to define break-glass coverage and succession ownership before separation happens.
There is no universal standard for exact timing, but current guidance suggests that privileged access should be removed immediately on termination or contract end, while lower-risk access can follow a documented grace process if justified and approved. Temporary exceptions should be time-boxed, monitored, and tied to named approvers. For shared credentials and service accounts, the organisation should rotate the secret rather than simply disabling the person’s directory account, because the residual credential may still work even after the user is gone. The Top 10 NHI Issues highlights how excessive privileges and weak lifecycle processes compound this problem.
For vendor exits, procurement and legal often own contract closure, but security should own verification that all remote access, integrations, and issued secrets have been revoked. For contractors, identity governance should confirm whether the account is personal, shared, or service-backed, because each type needs a different offboarding path. The practical rule is simple: the workflow owns the outcome, and the evidence must show that access is gone everywhere it existed.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-2 | Identity lifecycle governance covers timely deprovisioning and access removal. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Offboarding must revoke NHI credentials, tokens, and service account access. |
| NIST AI RMF | AI RMF governance supports accountable lifecycle control for autonomous access. |
Assign one accountable owner to validate that identity and access controls are consistently enforced.
