Topic starter
11/06/2026 11:24 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “4 Ways of Revoking Access to Tools While Offboarding Employees”.
By the numbers:
- Only 14% of the companies surveyed have systems and processes around SaaS deprovisioning while offboarding.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SaaS offboarding breaks down when teams revoke the primary login but leave sessions, app permissions, or hidden apps accessible.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
12/06/2026 8:03 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SaaS offboarding exposes the access revocation gap teams miss
This post was modified 4 days ago by NHI Mgmt Group