Who is accountable when access remains active after a mass exodus?

Accountability should sit with the identity and application owners who can prove revocation across the full access chain. HR may trigger the event, but IAM, security operations, and system owners are responsible for ensuring the access is actually removed and for documenting any exceptions.

Why This Matters for Security Teams

When access remains active after a mass exodus, the failure is rarely one control. It is usually a chain of missed ownership, delayed deprovisioning, and incomplete inventory across HR, IAM, application teams, and downstream service accounts. The practical risk is simple: departed users, contractors, and system identities may still hold credentials, tokens, or delegated access long after employment ends. That gap is exactly the kind of condition exploited in incidents covered in the 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10, where lingering machine access often persists far longer than human access.

Accountability matters because “HR initiated the exit” is not the same as “access was removed.” The owners of the identity source, the application, and any privileged path must be able to prove revocation end to end, including API keys, sessions, OAuth grants, service accounts, and backup access paths. In mature programs, the question is not who caused the exit event, but who can demonstrate that the access chain was closed.

In practice, many security teams discover the gap only after a former worker or contractor is still able to authenticate weeks later, rather than through intentional deprovisioning verification.

How It Works in Practice

Effective accountability starts with defining ownership before the event. HR can trigger the offboarding workflow, but IAM typically owns identity lifecycle controls, security operations validates revocation, and application or platform owners confirm that access is removed in the systems they run. For NHI environments, that includes workload credentials, service accounts, certificates, tokens, and automation identities that may outlive the human user who created them.

Current guidance suggests treating deprovisioning as a control chain, not a single ticket. A strong process usually includes:

• Source-of-truth update from HR or vendor management.
• Automatic disablement in the primary identity store.
• Revocation of active sessions, refresh tokens, API keys, and certificates.
• Removal of role assignments, group memberships, and delegated admin rights.
• Validation by the system owner that the account can no longer authenticate.
• Exception logging when access must remain temporarily active for legal, operational, or recovery reasons.

For autonomous workloads and agentic systems, this becomes even more important because access may be embedded in workflows rather than tied to a person. The Ultimate Guide to NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks both reinforce that identity sprawl is what makes revocation hard: one worker exit can leave behind multiple machine identities, each with different owners and different expiry rules. That is why modern programs increasingly pair lifecycle automation with continuous attestation rather than relying on manual sign-off.

In practice, this guidance breaks down when entitlements are scattered across SaaS tools, local admin accounts, and long-lived service credentials that are not connected to a central identity workflow.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance rapid revocation against business continuity, audit evidence, and recovery access. Best practice is evolving here: there is no universal standard for every exception case, especially where legal holds, shared break-glass accounts, or regulated retention requirements apply.

The most common edge case is a mass exodus involving both humans and non-human identities. A departing engineer may have created automation, rotated secrets, or delegated access to an agentic workflow. If those assets are owned by the application team but managed by central IAM, accountability becomes shared, and the risk is that each group assumes the other has already acted. That is where documented control ownership matters more than informal handoffs.

Another variation appears when access removal is partially successful. A directory account may be disabled, but cached tokens, SSH keys, CI/CD secrets, or external SaaS grants remain valid. For that reason, current guidance from OWASP Non-Human Identity Top 10 should be read as lifecycle discipline, not just password hygiene. The practical test is whether the former identity can still reach production, even indirectly. When a business insists on keeping access alive for a transition period, the exception should be time-bound, explicitly approved, and revalidated until fully removed.

Related resources from NHI Mgmt Group

• Who is accountable when access is left active after a role change or departure?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when a workload secret remains active after compromise?
• Who is accountable when a user remains active after directory removal?