IT offboarding gaps leave former employee access alive

At a glance

What this is: Zluri outlines a seven-step IT offboarding checklist and shows that leaving ex-employee access, shared accounts, remote login paths and ownership gaps unresolved creates security, compliance and cost risk.

Why it matters: IAM and IGA teams need to treat leaver offboarding as a governed lifecycle process because lingering access across SaaS, SSO and remote access can outlive employment and widen operational blast radius.

By the numbers:

• 20% of businesses have experienced data breaches connected to former employees.
• 70% of IT decision-makers surveyed said it could take up to an hour to deprovision all of a single former employee’s corporate application accounts.
• 50% of former employee accounts remain active for longer than one day after departure.
• 25% of accounts remain active for a week or longer after departure.

Context

IT offboarding is the controlled removal and transfer of access, ownership and assets when an employee leaves or changes role. In practice, the hardest part is not the final account disablement but the sequence: transfer files, revoke application access, remove SSO entitlements, reset shared credentials, and confirm remote pathways are closed.

This article argues that spreadsheet-driven offboarding creates a patchy leaver process that leaves access alive across SaaS, identity providers, remote login methods and shared accounts. That is an identity governance problem as much as an operations problem, because the former employee relationship ends before all the access paths do.

The article is focused on human identity lifecycle control, but its implications extend into NHI governance where shared accounts, tokens and service access are often owned or used by people who move on. When offboarding is incomplete, the identity programme inherits lingering entitlements, orphaned ownership and unclear accountability.

Key questions

Q: What breaks when a former employee account is not fully revoked?

A: A retained former employee account can preserve the exact permissions an attacker needs to alter, delete, or exfiltrate cloud and SaaS assets. The failure is usually not login bypass but lifecycle failure: access, sessions, tokens, and entitlements remain valid after employment ends. That makes offboarding a security control that must terminate authority, not just accounts.

Q: When should organisations prioritise ownership transfer over access revocation?

A: Ownership transfer should happen before or alongside access revocation when the departing user owns documents, subscriptions or application admin rights. If you revoke first, you may lose the ability to move data, edit plans or recover business records. The sequence matters because ownership is part of operational continuity, not just housekeeping.

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 is the difference between SSO disablement and full offboarding?

A: SSO disablement cuts off one authentication path, while full offboarding removes access from downstream applications, remote methods, shared accounts and ownership structures. They are not equivalent. A user can be blocked from the directory and still retain live sessions, cached access or control over assets elsewhere.

Technical breakdown

Why former employee access persists after offboarding

Former employee access persists when revocation is treated as a single event instead of a dependency chain. SSO disablement only removes one entry point; applications may retain live sessions, remote desktops may remain reachable, and shared credentials may still work. Ownership transfer matters as much as access removal because files, subscriptions and admin rights can otherwise remain stranded. The technical failure is not just missed cleanup, but a broken sequencing model that assumes the identity provider is the only control plane.

Practical implication: deprovision access in dependency order and verify each application and remote path independently before closing the leaver record.

Why shared accounts and remote login paths are high-risk

Shared accounts and remote access channels create a second life for the leaver’s identity footprint. If a shared Zoom-style credential, VPN profile or remote desktop path is not reset, the departing user may still authenticate with valid secrets or cached sessions. This is especially dangerous because the control is often outside the primary SSO workflow and therefore missed by standard offboarding checklists. The risk increases when teams rely on broad remote-access groups rather than explicit, user-specific entitlements.

Practical implication: reset shared secrets and revoke remote-access entitlements as separate offboarding steps, not as a side effect of disabling the user directory account.

Why license and ownership gaps turn into security gaps

Unused licenses and stranded ownership are not just cost waste. They are evidence that the organisation has lost control of who can edit, transfer or recover data after departure. When a user owns documents, integrations or subscriptions, access removal without ownership reassignment can break business processes while leaving residual data exposure in place. That is why offboarding needs visibility into applications, owners and entitlements before revocation begins, not after.

Practical implication: inventory application ownership before offboarding, then transfer ownership and licenses before you revoke the user’s remaining access.

Threat narrative

Attacker objective: The objective is to retain usable access to business systems and data after employment has ended, allowing unauthorised entry, persistence or misuse.

1. Entry occurs through still-active former employee access across SaaS, identity provider, remote login or shared account channels after departure.
2. Credential or session abuse follows when revoked users retain valid credentials, shared secrets or buffered application access.
3. Impact emerges as unauthorised data access, licence waste, compliance exposure and possible breach activity that should have been blocked at leaver offboarding.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

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

Leaver offboarding is a lifecycle control, not an admin cleanup task: The article shows that access removal, ownership transfer and asset recovery are interdependent governance steps. If organisations treat them as separate tickets, they create a residual-access window that outlives the employment relationship. The practical conclusion is that joiner-mover-leaver governance must be sequenced, verified and owned as a single control domain.

Former employee access is a lifecycle failure, not just an SSO problem: Revoking directory access does not guarantee application logout, remote access removal or shared credential reset. That means identity programmes that stop at the identity provider are blind to the residual paths that matter most. Practitioners should read this as a reminder that offboarding scope must include downstream applications and secondary access channels.

Offboarding creates identity blast radius if ownership is not reassigned first: When documents, subscriptions and admin rights remain with a departing user, the organisation inherits both operational interruption and hidden access persistence. The failure mode is orphaned ownership, where no one can manage the assets yet the old identity still anchors them. Teams should treat ownership transfer as part of access removal, not an optional follow-up.

The named concept here is leaver access persistence: It describes the period in which a former employee no longer belongs to the organisation but still controls active access paths, cached sessions or shared secrets. That persistence is what turns ordinary turnover into security exposure. The practitioner takeaway is simple: if offboarding cannot prove revocation, accountability has not actually ended.

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

Leaver lifecycle control has to move upstream: Organisations should stop treating offboarding as the final IT ticket in a departure workflow. The control point is earlier, when ownership, application access and shared credentials are still visible enough to transfer or revoke cleanly, before the identity can disappear from the directory.

Offboarding failure often shows up as orphaned access, not obvious compromise: The practical risk is a residual identity footprint that remains usable after the employment relationship ends. That footprint may sit in SaaS applications, remote login methods or shared accounts, so the governance challenge is cross-system closure rather than one-time account deletion.

Leaver access persistence: This is the governance gap where former employees retain active paths into business systems after offboarding should have closed them. Teams should measure success by whether access disappears across every route, not whether a ticket was marked complete.

For practitioners

• Define offboarding as a multi-control workflow Map the leaver process across ownership transfer, application access, SSO removal, remote access revocation, shared credential rotation and asset recovery before you automate it.
• Remove application access before SSO disablement Use application-level revocation first so that disabling the identity provider does not strand admin rights, sessions or ownership inside downstream systems.
• Reset shared credentials at departure Rotate passwords, tokens and session secrets for any shared account the departing user could access, especially collaboration and productivity tools.
• Revoke remote access pathways explicitly Separate VPN, remote desktop and any other remote login methods from the main deprovisioning step, then confirm those channels no longer authenticate the leaver.
• Monitor for post-offboarding account activity Review logs after deprovisioning to catch applications with delayed deletion windows, buffered sessions or failed revocation states.

Key takeaways

• Incomplete offboarding leaves a former employee identity footprint active across applications, remote channels and shared secrets.
• The article connects this failure to breach risk, compliance exposure and wasted licences, which makes offboarding a governance issue rather than a back-office task.
• Practitioners need sequencing, ownership transfer and verification across systems before the leaver process can be considered complete.

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.
• Ownership Transfer: Ownership transfer is the point at which an extension changes hands, either through sale, account compromise, or developer handoff. It matters because the extension can keep the same name, rating, and install base while becoming a materially different security object after the transfer.
• Shared credentials: Shared credentials are passwords, tokens, or access secrets used by more than one person or system. They weaken attribution and revocation because no single identity owns the secret cleanly, which increases blast radius when the credential is exposed or abused.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.