Topic starter
12/06/2026 12:45 am
TL;DR: Manual offboarding leaves former employees, apps, and data access active long after departure, while Zluri’s analysis says 37% of companies rely on SSO for SaaS deprovisioning and 18% still do it manually. The real issue is that access revocation, data backup, and app-level removal are often disconnected from identity lifecycle governance.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “How IT Teams Can Automate Deprovisioning During Offboarding”.
By the numbers:
- 37% of companies rely on SSO for deprovisioning access to SaaS tools.
- 67% of executives have security concerns regarding former employees causing security breaches unintentionally.
Key questions
Q: What breaks when offboarding removes SSO access before application access?
A: Teams can strand active application sessions, preserve app-level admin rights, and lose the ability to transfer ownership cleanly.
Q: Why does incomplete deprovisioning increase breach risk after an employee leaves?
A: Incomplete deprovisioning leaves former users with live access paths to customer records, employee data, and internal files.
Q: How do security teams know whether offboarding is actually working?
A: Security teams should measure completion, not process start.
Practitioner guidance
- Map the full offboarding sequence Document each revocation step from termination trigger to access removal, data backup, license removal, and SSO disconnect so the workflow is auditable end to end.
- Test app-level session termination Validate whether each SaaS app ends its own sessions when a user is deprovisioned, especially where SSO tokens or local sessions can remain active after removal.
- Inventory orphaned SaaS ownership Track applications without a current owner and require an ownership resolution step before the departing user is fully offboarded.
Bottom line: The article shows that SSO removal alone does not guarantee offboarding, because SaaS apps can keep their own session and account state alive.
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 10:11 am
SSO-only deprovisioning is a control boundary error: The article shows that federation removal is not the same as application revocation. Access can remain valid inside the SaaS layer after the identity provider is already cleared, which means the offboarding programme is measuring the wrong boundary. For IAM and IGA teams, that makes lifecycle governance incomplete by design.
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.
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
A question worth separating out:
Q: Should organisations prioritise app-level revocation over SSO deactivation?
A: Yes, because SSO deactivation alone does not always remove the user from the application or end an active session. App-level revocation is the control that actually closes access in the SaaS layer. SSO should support offboarding, but it cannot be the only deprovisioning mechanism.
👉 Read our full editorial: Offboarding deprovisioning exposes the limits of SSO-only control
This post was modified 4 days ago by NHI Mgmt Group