Notifications
Clear all
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.
NHIMG editorial — based on content published by Zluri: Automation How IT Teams Can Automate Deprovisioning During Offboarding
By the numbers:
- 37% of the companies rely on SSO for deprovisioning access to SaaS tools, and 18% do it manually.
- 67% of executives have security concerns regarding former employees causing security breaches unintentionally.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: What breaks when offboarding stops at SSO revocation?
A: Former employees can still reach data through app-native sessions, cached tokens, or retained authorisation states even after the central login is removed.
Q: Why do former employees remain a security risk after termination?
A: Because access often persists in places HR does not directly control, including SaaS sessions, connected apps, and orphaned subscriptions.
Q: How do security teams know if offboarding is actually working?
A: Look for evidence that access removal, data transfer, and ownership reassignment completed together.
Practitioner guidance
- Map every offboarding path to application-level revocation Document which SaaS apps revoke sessions immediately, which wait for expiry, and which require direct API calls or admin actions.
- Bundle data handoff with access termination Move files, ownership records, and operational notes before license removal completes so the next owner can continue work without relying on personal copies.
- Create an orphaned-app review at every exit Check for self-provisioned applications, unmanaged integrations, and any renewed subscriptions that remain after departure.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- A step-by-step offboarding workflow for removing users from multiple SaaS applications at once
- Specific examples of how Zluri backs up user data before revoking licenses and removing access
- How the platform handles direct API integrations beyond SSO-level deprovisioning
- The discovery methods Zluri uses to identify applications and access paths during offboarding
👉 Read Zluri's analysis of automated deprovisioning during offboarding →
Offboarding deprovisioning gaps: what IAM teams are missing?
Explore further
12/06/2026 10:11 am
Offboarding failures are usually lifecycle failures, not authentication failures. The article shows that identity removal can happen in one system while meaningful access remains alive in another through sessions, app-native permissions, or neglected ownership. That means the control problem sits in governance orchestration, not in a single sign-out event. Practitioners should treat offboarding as a cross-system closure process, not a federated login action.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: Who is accountable when orphaned apps keep running after an employee leaves?
A: Accountability sits with the business owner, IAM team, and application owner together, because the failure crosses identity, application, and spend governance. If nobody owns the app, nobody can revoke it cleanly. Organisations need a named steward for every application before offboarding can be reliable.
👉 Read our full editorial: Offboarding deprovisioning exposes the limits of SSO-only control
