TL;DR: Offboarding gaps leave SaaS access behind after employees depart, and Zluri cites a Gartner-backed study showing only 14% of surveyed companies have systems and processes for SaaS deprovisioning. The real control failure is not removal intent but incomplete revocation across SSO, sessions, app-level entitlements, and shadow IT.
At a glance
What this is: This is an analysis of SaaS offboarding control gaps, showing that revoking one layer of access often leaves other paths open.
Why it matters: It matters because IAM and IGA teams need offboarding to close every access path, not just disable a primary login, or former users can retain access to company data and tools.
By the numbers:
- Only 14% of the companies surveyed have systems and processes around SaaS deprovisioning while offboarding.
Context
SaaS offboarding is the process of removing a departing employee's access to the applications, sessions, and entitlements tied to their work. The control problem is that many programmes still treat deprovisioning as a single SSO action, even though access can persist at the app, session, and shadow IT layers.
That gap turns offboarding into an identity governance issue, not just an IT task. If inventory is incomplete, sessions remain valid, or app-level permissions are not revoked, former users can keep reaching sensitive corporate data after their accounts should be closed.
Key questions
Q: What breaks when SaaS offboarding only removes SSO access?
A: Partial offboarding leaves residual risk because application-level permissions, active sessions, and data custody may still persist. A user can appear removed from the identity provider while remaining reachable in the application or through transferred data paths. Effective offboarding must verify that access is removed everywhere it exists.
Q: Why do SaaS offboarding gaps create compliance and breach risk?
A: Because a departed user may still reach sensitive data after their account is supposed to be closed. That creates a control failure for least privilege, access review, and data handling, and it can also undermine investigations if audit trails do not show where access persisted. The risk is residual access, not just slow administration.
Q: How can security teams know if deprovisioning is actually working?
A: Security teams should test whether a terminated user still has any live access in downstream applications, not just whether the central directory shows removal. The best signal is a sampled termination that confirms groups, app-local accounts, and active sessions all disappear. If any one layer remains, deprovisioning is only partially working.
Q: What should IAM teams do when a departing employee used shadow IT?
A: Treat unsanctioned apps as part of the offboarding scope, not an exception. If the application was discovered late, revoke it manually, document the closure, and feed it back into discovery and governance so the same blind spot does not repeat. Offboarding is only reliable when discovery and revocation are connected.
Technical breakdown
Why SSO revocation does not end app access
Single sign-on centralises authentication, but it does not automatically terminate every live application session or remove app-native permissions. A departing user may lose their primary login yet still have an active session token, a cached browser session, or a direct app entitlement that remains valid until its own expiry or revocation event. That is why offboarding has to account for the identity provider, the SaaS application, and the session layer as separate control points. In practice, the hidden failure is assuming authentication deprovisioning equals authorization removal.
Practical implication: Treat SSO disablement as one control step, not the end of offboarding, and verify downstream session and app revocation.
Why shadow IT breaks revocation coverage
A spreadsheet or manual inventory can only revoke what it knows exists. Shadow IT creates unmanaged SaaS accounts and app signups that never enter the official inventory, so offboarding workflows cannot target them at all. The result is a governance blind spot where access survives because the system of record is incomplete, not because the revocation process failed at execution time. This is a classic identity lifecycle problem: deprovisioning cannot close what was never discovered and governed.
Practical implication: Continuously discover SaaS usage so offboarding can target both sanctioned and unsanctioned apps.
Why access revocation must cover data transfer and log visibility
Offboarding is not only about denying future access. It also has to preserve business continuity by transferring ownership, moving data, and retaining audit evidence about who had access and when. Without that layer, teams may revoke the account but lose the operational context needed for investigations, compliance checks, or handover to the replacement owner. Identity governance therefore depends on both closure and traceability, especially when the former employee already had access to sensitive systems and shared data.
Practical implication: Build offboarding workflows that combine revocation, ownership transfer, and access logging into one governed process.
Threat narrative
Attacker objective: Retain access to corporate applications and data after employment ends, whether for misuse, opportunistic access, or accidental exposure.
- Entry occurs through normal employee access to SaaS tools that were provisioned during employment and later forgotten during offboarding.
- Credential and session persistence keep access alive after deprovisioning, especially when only the SSO layer is revoked and app sessions remain valid.
- Impact follows when the former user can still reach data or tools, creating exposure to data loss, misuse, or security incidents after departure.
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
Access revocation is a lifecycle problem, not a single control event. Offboarding fails when teams assume that disabling the primary login is enough to remove a departed user's access. SaaS environments layer SSO, app-native permissions, cached sessions, and unmanaged signups, so the real control is lifecycle closure across every layer.
Shadow IT turns offboarding into an incomplete inventory problem. If an app is not in the governance record, it cannot be revoked with confidence. Manual spreadsheets and employee memory do not scale to modern SaaS estates, which means the offboarding gap is often a discovery failure before it becomes a revocation failure. Practitioners need governance over the full application surface, not just the approved catalogue.
Session persistence is the hidden reason SaaS access survives departure. The article's Slack example shows the core flaw clearly: revoking SSO can leave an existing application session alive until expiry. That means offboarding must be validated at the session and application layers, because authentication removal alone does not equal access termination.
Offboarding maturity should be measured by how completely it closes residual access, not by how quickly it deactivates a user record. Zluri's cited finding that only 14% of surveyed companies have systems and processes for SaaS deprovisioning signals that many organisations still lack lifecycle discipline. The practical test is whether a former employee can still reach any tool, token, or entitlement after the offboarding workflow finishes.
Vendor-managed SaaS estates need the same governance posture as internally built systems. The fact that SaaS access can persist through app sessions, shadow IT, and separate entitlement stores means identity governance has to operate across the service, the identity provider, and the application itself. Practitioners should treat deprovisioning as a governed cross-system state change, not an administrative checkbox.
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
Access revocation gap: SaaS offboarding fails when identity teams treat deprovisioning as an SSO-only event. Sessions, app entitlements, and shadow IT can all outlive the departure workflow, so the control boundary has to move from login removal to complete lifecycle closure.
The practical signal for programmes is whether they can prove residual access is gone, not just that the user record is disabled. If your offboarding process cannot enumerate all SaaS applications and verify session termination, you do not yet have governed deprovisioning.
For practitioners
- Map every offboarding control point Inventory the identity provider, live sessions, app-native entitlements, and unmanaged SaaS signups so revocation covers the full access path.
- Validate session termination separately Test whether disabling SSO actually kills active application sessions, especially for tools that keep tokens alive after account removal.
- Discover shadow IT before offboarding starts Use continuous SaaS discovery so the leaver workflow can include apps that never appear in the official entitlement record.
- Transfer ownership before revoking access Move data, app ownership, and operational responsibility to the successor so revocation does not break business continuity or auditability.
- Log the full deprovisioning sequence Retain sign-in, audit, and access logs for each application touched during offboarding to support investigations and compliance evidence.
Key takeaways
- SaaS offboarding breaks down when teams revoke the primary login but leave sessions, app permissions, or hidden apps accessible.
- The source article says only 14% of surveyed companies have systems and processes for SaaS deprovisioning, which shows how immature this control still is.
- The control that matters is end-to-end revocation across discovery, session closure, ownership transfer, and audit evidence.
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 and MITRE ATT&CK address 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 fundamentally about offboarding gaps that leave SaaS access behind. |
| NHI-03 — Vulnerable Third-Party NHI | SaaS applications and delegated access create third-party identity risk during leaver handling. | |
| NHI-05 — Overprivileged NHI | Residual permissions and app entitlements can leave departed users with more access than they should have. | |
| Recommendation — Audit offboarding workflows for complete identity closure across every SaaS account and session. Revoke third-party SaaS access through governed lifecycle controls before vendor or user departure. Review app entitlements on departure and remove any permissions not required for closure or handover. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle management is directly implicated when offboarding leaves access behind. |
| Recommendation — Use authenticator management controls to ensure departed users lose all valid access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is whether permissions and entitlements are fully removed during offboarding. |
| Recommendation — Apply entitlement controls to confirm each SaaS permission is removed or transferred during offboarding. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Residual sessions and accounts can be abused for credentialed access and movement across SaaS tools. |
| Recommendation — Map residual SaaS access to credential access and lateral movement risk in your detection program. | ||
Key terms
- SaaS offboarding: The process of removing a departing user from software access while also closing the related account, subscription, and data-handling obligations. In mature programmes, it includes license recovery, file transfer, inbox ownership changes, and evidence that the app lifecycle has ended cleanly.
- 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.
- Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
- 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.
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.
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