TL;DR: Employee offboarding is a significant security threat for 76% of executives, and 58% say COVID-19 made offboarding harder, with SSO session persistence and incomplete deprovisioning driving the risk, according to Zluri. That makes offboarding a governance problem across identity, data retention, and application access, not just an HR workflow.
At a glance
What this is: This case study argues that SSO deprovisioning alone does not reliably end access during employee offboarding when sessions persist and SaaS applications need separate attention.
Why it matters: IAM, IGA, and PAM teams should treat offboarding as a lifecycle control problem across accounts, sessions, applications, and data ownership, not a single disable-user action.
By the numbers:
- 58% of executives reported that offboarding processes have changed because of COVID-19 and an enforced remote workforce and have become more challenging.
- Overall, 76% of execs agreed that employee offboarding represents a significant security threat with access privileges being the biggest concern.
- Two-thirds, or 67%, of executives believe that employees exiting the organization are more likely to cause security breaches by accident than intentionally.
Context
Employee offboarding is the process of removing a departing worker's access, recovering company assets, and preserving data and responsibilities before they leave. In identity terms, it is a lifecycle problem because the account, session, and application entitlements do not all end at the same moment.
This article's central gap is that SSO deprovisioning can close an account without necessarily terminating live sessions, revoking app-specific access, or safeguarding the employee's data. That makes offboarding a governance issue across human identity, application access, and data retention rather than a simple helpdesk task.
The article is especially relevant to SaaS-heavy workplaces where remote work and app sprawl make access removal harder to verify. The author's starting position is typical of many organisations: account closure is treated as completion even when application-state cleanup is still unfinished.
Key questions
Q: What breaks when offboarding and deprovisioning are not unified?
A: Access removal becomes inconsistent, which means former users, changed roles, or stale accounts may retain access in one system after they have been removed in another. That creates both security exposure and operational confusion. The failure is usually not the policy itself, but the lack of a single enforced path from identity change to access removal.
Q: Why do delayed offboarding processes create security risk?
A: Delayed offboarding creates security risk because access can remain active after the business relationship ends. Former users may still reach email, files, CRM, or admin tools, which expands the window for data theft or disruption. The issue is not the departure itself, but the period during which stale access still works.
Q: What are the signs that offboarding device controls are failing in practice?
A: The warning signs are repeated delays, missing device returns, inconsistent handling of departures, and reliance on people remembering to act. If wipe and lock decisions vary by manager or are handled case by case, the process is not reliable. A weak audit trail is another signal, because teams cannot prove who triggered an action, on which device, and when.
Q: How should IAM teams handle data left behind by departing employees?
A: They should make data transfer or backup a required offboarding step, separate from account closure. Departing employees often leave shared files, project artifacts, and application-owned records that must be preserved or reassigned. If the organisation cannot move custody cleanly, offboarding is incomplete even when login access has been removed.
Technical breakdown
Why SSO deprovisioning can leave access alive
Single sign-on centralises authentication, but it does not automatically guarantee that every downstream SaaS session ends the moment HR or IT closes an account. If an application maintains its own session token or overrides the SSO session, the user may still perform actions after deprovisioning has started. The technical issue is the difference between identity authentication and application session state. In offboarding, those are separate control planes, and closing one does not always invalidate the other.
Practical implication: Treat SSO disablement as one control point, not proof that all access has ended.
Why application-level deprovisioning matters after account closure
Many SaaS applications hold their own permissions, data ownership, and audit trails that are not fully removed by a central identity action. Deprovisioning therefore has to reach the application layer, not just the identity provider, so that entitlements, licenses, and retained content are handled correctly. When that does not happen, the organisation can preserve access paths, create orphaned data, or leave records tied to a departed user. This is a classic lifecycle synchronization problem across systems.
Practical implication: Map which apps require direct revocation, ownership transfer, or data backup before the employee is marked fully offboarded.
How offboarding exposes identity and data retention gaps
Offboarding is not only about access removal. It also determines what happens to corporate data created or touched by the departing employee, including shared files, project artifacts, and account-linked records. If the organisation can revoke login but cannot transfer ownership or preserve data cleanly, it creates either loss risk or lingering access risk. Good governance separates deprovisioning, data retention, and evidence preservation rather than assuming one workflow satisfies all three.
Practical implication: Build offboarding runbooks that distinguish access revocation from data custody transfer and retention handling.
Threat narrative
Attacker objective: The objective is to preserve access long enough to reach data or business functions after the employee is meant to be fully offboarded.
- Entry begins when a departing employee still has active SSO-backed access and can continue using a live session after the account is closed.
- Escalation occurs when the application maintains its own session or permissions, allowing the user to keep operating despite central deprovisioning.
- Impact follows when the organisation fails to remove access cleanly or preserve data ownership, leaving sensitive content exposed or lost during transition.
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
Offboarding is a lifecycle control problem, not an HR checkbox. The article shows that closing an account does not equal ending authority, because access can survive in sessions, application permissions, and retained data. That means the governance model has to follow the identity across its full exit path, not stop at the directory event. Practitioners should treat offboarding as a state transition that must be verified across systems, not assumed from a single action.
SSO deprovisioning exposes the limits of centralised access control when the application keeps its own state. SSO is useful for authentication convenience, but the article makes clear that it does not fully govern downstream session lifetime or application-specific access removal. This is a control boundary problem: the central identity event is not the same thing as the application enforcement event. The implication is that identity teams need visibility into where each system actually revokes authority.
Data custody is part of offboarding governance. The article notes that employee-owned work product, project data, and application content still need backup or transfer when the employee leaves. That makes offboarding a three-way problem involving access removal, data retention, and ownership reassignment. Organisations that only think in terms of deactivation leave either operational gaps or unmanaged records behind, and both outcomes are governance failures.
Access removal and lifecycle offboarding must be measured separately. The article's strongest signal is that many teams believe they are secure once the user account is closed, even though applications, sessions, and files may still remain reachable. That gap creates a false sense of completion in IAM programmes. The practical conclusion is that offboarding metrics should track application-level completion, not just identity-provider closure.
Ephemeral access termination window: Offboarding assumes there is enough time between deprovisioning and session end for revocation to take effect cleanly. In SaaS environments with persistent sessions, that assumption weakens because the user may continue acting after the central account is removed. Practitioners should redefine completion around verified authority removal, not just account deletion.
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.
- Around 59% of companies report experiencing a data breach related to poorly managed offboarding processes.
- Read next: NHI Lifecycle Management Guide
What this signals
Offboarding completion needs a stronger boundary than account disablement. The article shows why identity teams should stop measuring success at the directory layer. In SaaS-heavy environments, the real boundary is whether the application, session, and data ownership state have all been cleared.
Access removal and data custody should be governed as separate events. When a departing employee's access and content are handled in the same workflow, teams often miss one of them. That creates either residual access or orphaned records, both of which weaken lifecycle governance.
Offboarding has to be measured at the system level, not the process level. A ticket can close while a session remains live or a file remains owned by the wrong person. That is why lifecycle governance should verify actual state change across every connected application.
For practitioners
- Define offboarding completion as verified access removal Track closure across the identity provider, the SaaS application, and any active session state before declaring the employee fully offboarded.
- Inventory applications with independent deprovisioning paths Identify SaaS tools that retain their own entitlements, sessions, or ownership records so they can be handled separately from SSO disablement.
- Separate data transfer from access revocation Require a distinct step for transferring ownership or backing up content before the employee record is fully retired.
- Measure offboarding by system-level closure, not ticket completion Use completion checks that confirm deactivation, data custody handoff, and license removal rather than relying on an HR or IT ticket marked closed.
Key takeaways
- Employee offboarding fails when organisations treat SSO deprovisioning as the end of access rather than the start of verification across apps and sessions.
- The article shows that remote and SaaS-heavy working patterns make offboarding harder because they multiply the places where authority and data can persist.
- A complete offboarding control should confirm account closure, application revocation, and data transfer as separate outcomes before the lifecycle is considered finished.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article is centered on failing to revoke access cleanly when employees leave. |
| NHI-05 — Overprivileged NHI | Lingering SaaS permissions after exit show how access can outlive employment scope. | |
| Recommendation — Audit offboarding workflows for incomplete revocation and verify every departure closes all active access paths. Review departed-user entitlements and remove any remaining privileges that were not explicitly retired. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Offboarding depends on timely account disablement and removal of associated access. |
| AC-6 — Least Privilege | The article highlights access that remains broader than needed during and after departure. | |
| Recommendation — Enforce account termination procedures that verify deactivation across all connected systems. Apply least privilege checks to reduce post-employment access to the minimum necessary state. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about whether authorizations are actually removed at offboarding. |
| Recommendation — Validate entitlement removal at the application layer, not only in the identity provider. | ||
Key terms
- Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
- Deprovisioning: Deprovisioning is the removal of access when a user changes roles or leaves an organisation. For security teams, it is the point where stale accounts, tokens, and permissions should disappear. Weak deprovisioning leaves residual access that can outlive the business need that created it.
- Session persistence: The tendency for access to remain valid after the original authentication event has ended or been revoked upstream. In browser-centric incidents, this is the gap between killing the login and actually terminating the live SaaS or application session that the attacker is still using.
- Data Custody Transfer: Data custody transfer is the reassignment or preservation of content owned or touched by a departing employee. It matters in offboarding because access removal without ownership transfer can leave critical files orphaned, lost, or still reachable through the wrong account.
Deepen your knowledge
Identity lifecycle management, secrets management, and workload identity security 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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org