Leaver offboarding gaps still create orphaned accounts and audit risk

At a glance

What this is: This is a leaver offboarding checklist analysis showing that manual workflows often leave orphaned accounts, stale access and audit exposure across identity, SaaS, VPN, data and physical controls.

Why it matters: IAM, IGA and PAM teams need to treat offboarding as a cross-system revocation problem, because incomplete leaver handling leaves access paths open after ownership and accountability have moved on.

👉 Read Clarity Security's IT offboarding checklist and leaver workflow guidance

Context

Leaver offboarding is the point where identity governance, access revocation and audit evidence either work together or fail separately. In practical terms, the problem is not just removing a user from one system, but closing every place where that identity still has residual access.

For NHI and human IAM programmes alike, manual offboarding creates a gap between termination and full revocation. The article makes clear that this gap can include SSO, SaaS accounts, active sessions, VPN, cloud storage, shared credentials, physical badges and the evidence trail needed for audit confidence.

That makes offboarding a lifecycle control, not an administrative afterthought. When the process is fragmented, the organisation inherits orphaned access, delayed reclamation of licences and incomplete proof that access was actually removed.

Key questions

Q: What breaks when manual leaver offboarding is not in place?

A: The revocation chain breaks. A user may be disabled in the identity provider while still retaining SaaS accounts, active sessions, VPN access, shared credentials or physical entry rights. That creates orphaned access and makes it impossible to prove that the former identity has actually been closed everywhere it mattered.

Q: Why do partially offboarded users increase audit risk?

A: Because auditors need proof that access was actually removed across the full estate, not just in the primary directory. If SaaS accounts, tokens, or shared resources remain active, the organisation cannot demonstrate complete control over sensitive data. That weakens compliance evidence for standards that require lifecycle access governance.

Q: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

Q: What should organisations do when a terminated user still has live access?

A: Treat it as an unresolved offboarding event, not as a minor exception. Revoke the remaining access path immediately, rotate any shared credentials, verify session termination and capture the action in the evidence log so the termination is closed consistently across systems.

Technical breakdown

Why leaver offboarding fails across control planes

Leaver offboarding breaks when access is treated as a single event instead of a set of independent control planes. Disabling a user in an identity provider does not automatically close SaaS-native accounts, terminate active sessions, revoke VPN access or remove physical badge access. That is why orphaned accounts persist after termination. The technical issue is control coverage, not task speed: each downstream system has its own state, and each state must be explicitly changed before the former identity can no longer be used.

Practical implication: Map every joiner-mover-leaver step to the control plane that actually enforces it, instead of assuming one upstream change revokes everything.

Why active sessions and shared credentials extend the attack window

A terminated user can retain meaningful access even after primary credentials are disabled if web sessions, mobile sessions or shared passwords are not revoked. Session tokens and cached authentication state can outlive the account state change, while shared credentials create a separate reuse path that is invisible to ordinary user disablement. This is the classic offboarding blind spot: access is removed at the directory layer, but not at the session or secret layer. The result is a residual window where legitimate identity removal has not yet translated into effective denial of access.

Practical implication: Add session termination and credential rotation to the same offboarding sequence as account disablement, not as follow-up tasks.

Why evidence logs matter for audit and accountability

An offboarding evidence log turns revocation work into auditable control evidence. Without a timestamped record of what was removed, when it was removed and by which process, the organisation cannot prove that access was actually closed. That is especially important when different teams handle HR, IT, security and facilities work in separate queues. Audit failure here is often an evidence failure first and a control failure second. The operational question is not whether offboarding happened, but whether it can be reconstructed with enough detail to show completeness.

Practical implication: Capture revocation actions as they happen so audit review can verify closure rather than infer it from tickets.

Threat narrative

Attacker objective: Exploit residual post-termination access to enter systems, reuse still-valid credentials or create audit exposure around incomplete offboarding.

1. Entry occurs when a former employee still has access through an orphaned account, stale SaaS login, active session or unreclaimed physical badge after termination.
2. Credential access persists because the account was not fully deprovisioned and shared credentials or session tokens were not rotated or terminated.
3. Impact follows when that residual access becomes a usable entry point for threat actors or a failed audit finding that exposes governance breakdowns.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Manual leaver offboarding is a control-chain problem, not a ticketing problem. The article shows that identity, SaaS, session, VPN, data and physical controls all have to close together or the leaver remains reachable through the weakest surviving path. That is why offboarding maturity is measured by revocation completeness, not by how quickly a request was opened. Practitioners should treat offboarding as a chained control with a single closure requirement.

Orphaned access is the visible symptom of a deeper lifecycle failure. When an identity is removed from the directory but still exists in SaaS, billing, storage or badge systems, governance has failed at the lifecycle boundary. This is exactly where JML, PAM and identity governance intersect: the organisation has not truly offboarded the subject if any access remains administratively alive. The practitioner implication is to govern termination as a multi-system state change, not a single action.

Offboarding evidence is part of the control, not an afterthought to the control. The article’s emphasis on logs, scheduling and review shows that auditability depends on provable revocation, not verbal assurance. In practice, incomplete evidence is often indistinguishable from incomplete execution. Teams should design for reconstructability so every leaver event can be demonstrated end to end.

Residency of access after termination creates identity blast radius. The longer a user retains residual access, the more places an attacker, insider or simple process failure can use that account to move laterally. The concept is useful because it reframes offboarding from a compliance chore into a blast-radius control. Practitioners should focus on shrinking the time and surface area between termination and complete revocation.

Formal offboarding remains uneven because many organisations still manage revocation as separate administrative tasks. The source article and the supporting research statistic point to a market-wide pattern: offboarding and revocation are often not designed as one governed lifecycle. That means practitioners need to re-evaluate whether their leaver process is policy-led, system-enforced and evidenced well enough for audit, not just operationally convenient.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity blast radius is the right way to think about leaver risk. The issue is not only that one account survives termination, but that one incomplete revocation can leave several systems reachable at once. Teams that measure offboarding only by HR completion are missing the broader access surface that still needs to be closed.

Offboarding should be governed as a lifecycle control with evidence attached. Manual handoffs between HR, IT, security and facilities create avoidable blind spots, especially when SaaS, shared credentials and badge systems sit outside the main identity provider. The practical signal for practitioners is whether a leaver event can be reconstructed end to end without guesswork.

For practitioners

• Tighten the leaver revocation sequence Disable the identity at the source, then revoke SaaS accounts, terminate active sessions, close VPN access and remove physical badge access in one governed workflow.
• Rotate shared credentials immediately If the departing user had access to shared passwords or other reused secrets, rotate those credentials as part of the same offboarding event rather than treating them as a separate task.
• Build an offboarding evidence log Record exactly what access was removed, when it was removed and which system enforced the change so audit teams can verify closure later.
• Audit for orphaned and shadow accounts Review accounts that are not governed by the identity provider or do not appear in normal offboarding queues, then confirm they are disabled and scheduled for deletion.

Key takeaways

• Manual offboarding fails when identity, SaaS, session, VPN, data and physical access are revoked as separate tasks instead of one governed closure event.
• The article shows that orphaned accounts and ghost access are not edge cases, they are the predictable outcome when leaver workflows are fragmented across teams and systems.
• A complete offboarding process needs immediate revocation, shared secret rotation and an evidence log that proves every residual access path was closed.

Key terms

• Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
• Orphaned Account: An orphaned account is an identity that remains active without a clear owner or business purpose. These accounts are dangerous because they often escape review, retain unnecessary access, and provide attackers with low-friction entry points into otherwise governed environments.
• Revocation evidence: Revocation evidence is the record that proves access actually ended when the task ended. It usually includes the request, approval, session timestamps, and closure event. Without that evidence, temporary access can be claimed but not reliably verified.
• Residual Access: Residual access is any permission, token, account, or data path that continues to work after a user should no longer have access. It is a common failure mode in SaaS-heavy environments because deprovisioning one system does not automatically shut down all downstream connections.

What's in the full article

Clarity Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step offboarding checklist items for IdP, SSO, SaaS, VPN, storage and physical access revocation
• Guidance for preserving business continuity while transferring ownership of files, inboxes and applications
• A template-driven approach to logging what was removed and when for audit readiness
• Examples of how automated workflows can trigger notifications, tickets and access review actions

👉 The full Clarity Security article includes the checklist template, automation flow and audit logging detail.

Deepen your knowledge

NHI governance, identity lifecycle, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.