Who is accountable when access remains active after a leaver event?

Why This Matters for Security Teams

leaver event are not just administrative cleanup. They are control failures that can leave active access, secrets, and service paths exposed long after an identity should have been removed. In non-human identity programs, the same gap often appears in tokens, API keys, service accounts, and delegated access that survive because ownership is split or evidence is missing. NHI Management Group’s Ultimate Guide to NHIs frames this as a lifecycle governance problem, not a one-time deprovisioning task. The OWASP Non-Human Identity Top 10 also treats stale credentials and weak ownership as recurring exposure points.

The accountability question matters because “shared responsibility” often becomes no responsibility in practice. If the offboarding workflow spans HR, IT, application owners, and security, each group may assume another has completed revocation. That creates a dangerous blind spot where access remains active even though the person has left, the certificate is still valid, or the service account still functions. In practice, many security teams discover this only after a suspicious login, a data access review, or an audit finding, rather than through intentional control testing.

How It Works in Practice

The accountable party should be the named business owner of the identity process, with the system owner responsible for revoking access in the target application and the governance team defining the standard for completion and evidence. That division matters because accountability is about who must ensure the outcome, not who merely participates in the workflow. Current guidance suggests that every leaver path needs a single control owner, even when implementation is distributed across teams.

Operationally, the process should include four linked steps: detect the leaver event, identify every access path, revoke or disable access, and retain evidence that the revocation occurred. For human accounts, that may mean disabling SSO, removing group memberships, and invalidating sessions. For NHI assets, that may mean rotating secrets, deleting API keys, expiring certificates, or disabling workload credentials. The 52 NHI Breaches Analysis is useful here because it shows how weak lifecycle control repeatedly turns identity sprawl into exposure.

• Assign a single owner for closure, even if HR, IAM, and app teams each perform different tasks.
• Define what “complete removal” means for each system: disable, delete, rotate, or expire.
• Require evidence retention, such as ticket closure, logs, and revocation timestamps.
• Set time limits for remediation so access does not remain active during manual handoffs.

Where possible, lifecycle controls should be automated and measured against authoritative records, because manual coordination breaks down when one system lacks integration, when SaaS apps are managed outside central IAM, or when service accounts are embedded in code and forgotten after staff departure.

Common Variations and Edge Cases

Tighter offboarding control often increases process overhead, requiring organisations to balance speed of removal against the need for audit-ready evidence. There is also no universal standard for this yet in mixed human and non-human environments, so current guidance is evolving on how to prove that all dependent access has actually been removed.

One common edge case is partial ownership. A business owner may approve the process, but a platform team controls the actual credentials, which can blur accountability unless the control standard names a final approver. Another is inherited access, where a leaver is removed from primary systems but still holds access through shared groups, vaulted secrets, or machine-to-machine trust. The DeepSeek breach illustrates how exposed secrets and unmanaged data paths can magnify the impact of poor lifecycle discipline.

In mature programs, the strongest model is to tie leaver closure to both ownership and technical proof: who signed off, what was revoked, when it was revoked, and how the evidence was preserved. That approach aligns with NHI Management Group’s position that accountability must be explicit, because shared workflows do not self-enforce. The control tends to break down when offboarding is handled by email, when SaaS tools sit outside central identity governance, or when secret rotation is treated as optional after personnel changes.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when access remains active after a mass exodus?
• Who is accountable when user access remains active after offboarding?
• Who is accountable when server access remains active after offboarding?