Who should own offboarding when multiple systems are involved?

Why This Matters for Security Teams

offboarding breaks down when ownership is assumed to be “everyone’s job” but no one is accountable for proving completion. That gap matters because a user can lose a badge and still retain SaaS access, API tokens, group membership, or entitlements in downstream systems. NIST’s NIST Cybersecurity Framework 2.0 treats identity lifecycle control as a core governance issue, not a clerical task. The same logic applies to NHIs: if the record is incomplete, the exposure remains live.

NHI Management Group research shows how common this failure is in practice. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs highlights that only 20% of organisations have formal processes for offboarding and revoking API keys. That is a warning sign for human offboarding too, because the same control weakness often affects SSO, app licenses, and service entitlements at once. In practice, many security teams encounter residual access only after an incident review or license cleanup exposes what was never revoked.

How It Works in Practice

The cleanest operating model is to give one team end-to-end accountability, while allowing multiple teams to execute tasks. Identity or IAM usually owns the workflow because it spans SSO, directories, provisioning tools, and audit evidence. HR typically triggers the event, application owners remove application-specific access, and security validates that removal met policy and risk requirements. That division avoids the common failure mode where each team assumes another system is “out of scope.”

A practical offboarding workflow should include:

• A single case or ticket that becomes the system of record for every access removal step.
• Automated deprovisioning across directory, SSO, SaaS, PAM, and license systems where integration exists.
• Manual checks for apps that do not support SCIM or API-driven revocation.
• Proof of completion, including timestamps, entitlement diffs, and exception handling.
• Escalation when an owner cannot confirm removal within a defined service window.

This is why the NHI Lifecycle Management Guide is useful even for human access programs: it frames lifecycle management as continuous control, not one-time administrative work. Current guidance suggests that offboarding should be measured by verified revocation, not by request closure. If an account is tied to a third-party SaaS tool, a shared mailbox, or a delegated admin role, the accountable owner must still prove that the access path is gone. These controls tend to break down in highly federated environments because identity signals, app ownership, and license management live in separate systems that do not reconcile automatically.

Common Variations and Edge Cases

Tighter offboarding control often increases coordination overhead, requiring organisations to balance speed against evidence quality. That tradeoff becomes more visible during layoffs, M&A activity, contractor exits, and emergency terminations, where the business wants rapid cutoff but the control owner still needs proof across many systems. Best practice is evolving, but there is no universal standard for this yet on exactly how much evidence is enough across every environment.

Edge cases matter. A shared service account may need immediate credential rotation rather than simple deletion. A privileged account may require dual approval from IAM and security before removal from PAM. A contractor may retain access to one managed platform for legal or operational reasons, which means the ticket must record an exception, an expiry date, and the approving owner. For NHIs, the same logic applies to tokens, keys, and service identities that survive role changes unless someone explicitly revokes them.

The operational takeaway is straightforward: HR can initiate, application owners can execute, and security can verify, but one accountable team must own completion across the full identity surface. The Top 10 NHI Issues reinforces that lifecycle gaps and excess privileges are persistent risk drivers, especially when access spans multiple systems. When ownership is split without a final verifier, offboarding becomes a distributed failure rather than a completed control.

Related resources from NHI Mgmt Group

• What breaks when offboarding does not remove access across all SaaS systems?
• Who should own SaaS governance decisions when multiple teams are involved?
• What breaks when an IAM tool cannot support offboarding well?
• Why do organisations need post-offboarding access reviews?