Accountability should sit with a defined lifecycle owner, not with informal manager follow-up. Identity, HR, and application owners all have a role, but the process needs a single trigger and a clear revocation policy. Without that, offboarding becomes a coordination problem instead of a governance control.
Why This Matters for Security Teams
access removal after an employee leaves is not an administrative cleanup task. It is a control point that determines whether dormant access, inherited privileges, and orphaned secrets remain usable after separation. The practical failure mode is simple: HR closes the record, but identity, application, and secrets owners do not receive the same trigger at the same time. That gap is where residual access survives.
NHI Management Group’s Ultimate Guide to NHIs shows why lifecycle ownership matters across identities, credentials, and offboarding. Even though this question is about a human departure, the same governance weakness often leaves service accounts, API keys, and shared credentials behind. OWASP’s OWASP Non-Human Identity Top 10 reinforces the same point: identity removal is only effective when it is tied to credential revocation, not just directory status.
The accountable party should be a defined lifecycle owner, usually in identity governance or IAM operations, with HR as the authoritative trigger and application owners responsible for removal inside their systems. In practice, many security teams encounter lingering access only after a former employee’s account, token, or API key is discovered during incident response rather than through intentional offboarding review.
How It Works in Practice
Effective access removal depends on one accountable owner and one reliable trigger. HR normally owns the employment status event, but HR does not own the technical revocation steps. The lifecycle owner should translate the departure into a coordinated sequence: disable directory accounts, remove group membership, revoke active sessions, invalidate tokens, remove app entitlements, and confirm deletion or rotation of any credentials tied to the employee’s role.
That sequence should be explicit in policy. A good control model separates responsibility by layer:
-
HR triggers the termination event and confirms the effective timestamp.
-
Identity or IAM operations executes directory deprovisioning and session revocation.
-
Application owners confirm removal from business systems and privileged tools.
-
Secrets owners or platform teams revoke API keys, tokens, certificates, and shared credentials.
For higher-risk environments, the trigger should also feed privileged access workflows, vaults, and PAM tooling so that standing access is removed without waiting for manual follow-up. NHI Management Group’s 52 NHI Breaches Analysis is a useful reminder that missed revocation is rarely a single-system issue; it tends to be a chain failure across identity, secrets, and application control planes. The operational best practice is to test offboarding as a workflow, not as a checklist, and to verify completion with evidence rather than email acknowledgment. These controls tend to break down when organisations rely on manual manager approval chains because the revocation path becomes inconsistent across SaaS, cloud, and legacy applications.
Common Variations and Edge Cases
Tighter offboarding often increases coordination overhead, requiring organisations to balance speed against completeness. That tradeoff becomes visible in environments with shared mailboxes, delegated admin rights, contractors, or break-glass access, where removing one person’s access can disrupt team operations if ownership records are incomplete.
Current guidance suggests that the accountable owner should still be singular, even when execution is distributed. There is no universal standard for naming that role yet, but the control objective is consistent: one party owns the end-to-end removal outcome, while others own execution steps inside their domains. In matrix organisations, that owner is often IAM or identity governance, with application owners accountable for application-specific deprovisioning and audit evidence.
Edge cases include delayed terminations, legal holds, leave of absence, and partial offboarding. In those scenarios, access may need to be suspended rather than fully removed, but the policy should still define who decides and who verifies the outcome. The same logic applies to third-party accounts and shared secrets: if a departing employee knew the secret, the secret itself may need rotation, not just account disabling. For most organisations, the practical question is not whether the manager should “follow up,” but whether the control design can prove that every residual path was closed.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Offboarding failures often leave NHI credentials active after staff leave. |
| NIST CSF 2.0 | PR.AC-4 | Access removal is a core identity and access management control. |
| NIST SP 800-63 | Identity proofing and lifecycle management support timely account disabling. |
Use authoritative status changes to drive immediate account suspension and closure.
Related resources from NHI Mgmt Group
- Who is accountable for exposed NHI secrets after an employee leaves?
- Who is accountable when an application keeps access after a user leaves the directory?
- Who is accountable when a former employee still has access after offboarding?
- Who is accountable when orphaned apps keep running after an employee leaves?
