Ownership should sit with the identity and access management function, but it must be enforced across HR, IT, security operations, and system owners. Offboarding fails when responsibility is fragmented or treated as a checklist item. The accountable team must ensure termination events trigger immediate access removal, log protection, and verification across every system the employee could reach.
Who should own offboarding when access spans identity, remote access, and multiple systems?
The accountable owner should be the identity and access management function, because it is the only team positioned to coordinate revocation across directories, remote access, and downstream applications. HR, IT, security operations, and system owners all have execution roles, but ownership must not be split so loosely that termination becomes a best-effort task.
When the owner is unclear, offboarding usually fails at the seams: one team closes the employee record, another disables VPN, and a third never revokes the application token or key. That gap is where dormant access persists, remote access remains usable, and verification never happens.
A practical ownership model is to make IAM responsible for the end-to-end control, with HR as the trigger source, IT as the execution partner for core platforms, security operations as the monitor for exceptions and delayed revocations, and system owners as the final approver for business-critical applications. That arrangement keeps one function accountable for completion while still forcing each platform owner to remove access in their own environment.
For identity lifecycle governance, the cleanest model is the one that already exists in Joiner-Mover-Leaver (JML) Guide: one trigger, one accountable owner, and one completion standard across all accounts and credentials. The same logic is reinforced in IAM and IGA Basics, which treats provisioning, access reviews, and deprovisioning as governance functions rather than ad hoc admin work.
What has to be revoked beyond the employee directory?
Offboarding is not complete when the human account is disabled. The owner must ensure the person’s access is removed from remote access paths, privileged sessions, shared accounts, application roles, API keys, tokens, certificates, and any delegated access that survives beyond the employee record.
That is especially important where remote access is part of the workflow. If a VPN, ZTNA, jump host, or vendor access channel remains active after termination, the person may still be able to reach systems even if the primary corporate account is closed. The owner therefore has to treat remote access revocation as part of the same control, not as a separate ticket.
This is why lifecycle controls matter more than simple account closure. Remote Access Identity Guide and Workforce Identity Security Guide both point to the same operational reality: access paths multiply faster than teams track them, so ownership has to include discovery, revocation, and verification across every reachable system.
When the subject is offboarding, the right question is not “who disabled the account?” but “who proved that all access paths were removed?” That is the difference between isolated closure and actual deprovisioning.
How should accountability work across HR, IT, security operations, and system owners?
The accountable team should define the process, the trigger, the SLA, and the evidence standard. HR should initiate termination events, IT should execute baseline removal, security operations should watch for failed or late revocations, and system owners should confirm completion for their platforms. If one of those roles is missing, the process becomes brittle at the exact point where speed matters most.
A strong operating model uses a single offboarding workflow with explicit ownership handoffs and a final verification step. That means the owner must be able to answer four questions quickly: who triggered the event, which systems were reached, what was removed, and what remains blocked or pending. If the answer to any of those is unclear, the process is not controlled.
Practitioners should also make use of the governance patterns in Top 10 NHI Issues and the lifecycle focus in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Even though those resources are broader than employee offboarding, they reinforce a useful governance lesson: if revocation is spread across multiple owners without one accountable control point, stale access is almost guaranteed to persist.
Risk and Threat Considerations
Fragmented offboarding creates a real exposure window. An ex-employee, contractor, or compromised account can continue using remote access, stale tokens, or unrevoked credentials long after termination if no single team owns completion and verification.
Failure mechanism: The termination event is processed in one system but not propagated to every connected identity store, remote access tool, application, or credential source, leaving usable access behind.
Impact: Dormant access can support unauthorized data access, privileged abuse, or lateral movement, especially when remote access paths remain live after the person is supposed to be offboarded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke credentials, tokens, and keys across systems. |
| AC-2 — Account Management | The question is about who owns account removal and termination processing. | |
| AC-6 — Least Privilege | Offboarding should remove residual access and prevent continued excess privilege. | |
| Recommendation — Revoke and expire authenticators immediately when access must end. Assign account termination ownership and enforce prompt deprovisioning. Remove unnecessary access paths and verify privilege is fully withdrawn. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Lifecycle revocation across identity and remote access is central here. |
| Recommendation — Define a single accountable owner for identity lifecycle revocation. | ||
| CIS Controls v8 | 5 — Account Management | Offboarding depends on managed account disabling, review, and removal. |
| Recommendation — Centralize account disablement and confirm removal across all systems. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed when employment ends or role changes. |
| Recommendation — Remove access rights promptly and retain evidence of completion. | ||
Practitioner Guidance
What to verify: The owner should verify revocation in the systems that matter most, not just the HR record or the primary directory. That includes VPN or ZTNA, privileged access, application roles, shared mailboxes, tokens, and any externally managed access path.
Decision rule: If a departing user can still authenticate anywhere, treat the offboarding as incomplete. Immediate remediation should focus on cutting the live access path first, then reconciling the remaining systems and recording any exception for follow-up.
Practitioner takeaway: Ownership should be singular even when execution is distributed, because offboarding only works when one team is accountable for proving that every access path is gone.
NIST SP 800-207 Zero Trust Architecture
Related resources from NHI Mgmt Group
- Who should own access evidence when multiple teams manage IAM, IGA, and PAM?
- Who should own identity control evidence when multiple teams share access governance?
- How should security teams manage role-based access for mixed identity populations across multiple countries and business units?
- How should security teams manage identity and access across multiple cloud platforms without losing control of least privilege?