Who is accountable when a former employee still has access after offboarding?

Why This Matters for Security Teams

Offboarding is not a single action; it is a chain of revocation events across directories, SaaS, CI/CD, and workload systems. When a former employee still has access, the failure is usually not limited to one control owner. It reflects gaps in lifecycle governance, session invalidation, and application-level enforcement, which is why accountability often spans IAM, IT operations, and the relevant application owner.

That matters because stale access is rarely harmless. NHIMG’s 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, showing how often revocation stops at the directory and never reaches the applications actually granting access. Current guidance from the OWASP Non-Human Identity Top 10 also treats lifecycle failures as an identity risk, not merely an HR process issue.

In practice, many security teams encounter offboarding failures only after a departed user has already used an active session, API token, or delegated app permission rather than through intentional access review.

How It Works in Practice

Accountability should be assigned by control layer, not by assumption. IAM teams typically own directory disablement and group removal. IT operations often own endpoint collection, device wipe, and broader account deprovisioning workflows. Application owners must remove app-specific entitlements, revoke OAuth grants, invalidate refresh tokens, and terminate active sessions. If privileged access is involved, PAM owners need to remove elevation paths and temporary grants. For cloud and platform services, workload and secrets owners must also rotate any credentials that may have been exposed to the departed user.

A useful operating model is to treat offboarding as a revocation workflow with explicit checkpoints:

• Identity source disabled in the directory and HR trigger confirmed.
• All SaaS sessions, API tokens, and delegated authorisations revoked.
• Application roles, shared mailboxes, repos, and automation accounts reviewed.
• Secrets, certificates, and service credentials rotated where user knowledge or access existed.
• Evidence captured for audit and exception handling.

This is consistent with the broader lifecycle approach in NHIMG’s NHI Lifecycle Management Guide and with the control emphasis in NIST Cybersecurity Framework 2.0 on shared responsibility for identity governance. For application-specific access, policy should be enforced at runtime with documented ownership, not left to directory deprovisioning alone. These controls tend to break down in federated SaaS and shadow-IT environments because the directory owner cannot see or revoke every downstream session, token, and app-level grant.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance fast employee exits against complete revocation and evidence collection.

There is no universal standard for one owner to carry all accountability. In regulated environments, legal and compliance teams may require a formal attestation chain, while engineering-led organisations often rely on ticket ownership and automated workflows. Best practice is evolving toward control-plane accountability: whoever operates the system that can still authorise access must prove revocation happened. That includes SaaS administrators, cloud platform teams, and application owners who manage non-directory credentials.

Edge cases matter. Shared accounts can obscure who is responsible for removal. Break-glass accounts may require exception handling and separate logging. Former employees who used personal tokens, external integrations, or long-lived secrets can retain access even when all standard accounts are disabled. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights why visibility gaps and excessive privilege make these scenarios difficult to contain. For teams formalising the control model, the 52 NHI Breaches Analysis is a practical reminder that lifecycle failures are rarely isolated. The real test is whether every system that can still authenticate the user is included in offboarding, because that is where accountability becomes operational rather than theoretical.

Related resources from NHI Mgmt Group

• Who is accountable when former employees still have admin access?
• Why do former employees still keep access after offboarding in many organisations?
• Who is accountable when a leaver still has SaaS access after offboarding?
• Who is accountable when offboarding leaves access behind?