Offboarding deprovisioning exposes the limits of SSO-only control

At a glance

What this is: This is an analysis of why offboarding deprovisioning still fails when teams depend on SSO alone, with the key finding that access, sessions, and data ownership often remain active after departure.

Why it matters: IAM and IGA teams need lifecycle controls that reach beyond federation, because incomplete revocation leaves former users able to access apps, data, and licenses after 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.

Context

Offboarding deprovisioning is the process of removing a departing user’s access, data reach, and app ownership when they leave. In this article, the core issue is that SSO alone does not reliably revoke access inside SaaS applications, leaving identity lifecycle governance incomplete.

That gap matters because application sessions, device logins, backups, and orphaned apps often sit outside the SSO control plane. For IAM and IGA programmes, offboarding has to be treated as a cross-system revocation workflow, not a single sign-out action.

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. The directory may look disabled while the application still allows access or retains important data. Bottom-up deprovisioning avoids this by clearing downstream access first and only then closing the identity provider entry.

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. That extends the exposure window beyond the employment relationship and makes misuse, accidental disclosure, and compliance failure more likely. The risk grows when sessions, licenses, and app ownership are not removed together.

Q: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

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.

Technical breakdown

Why SSO-only offboarding leaves sessions active

SSO controls the authentication handoff, not always the application session itself. If a SaaS app maintains its own session timer or authentication cache, removing the user from SSO does not necessarily invalidate that session immediately. The article’s Grammarly example shows the practical failure mode: an application can keep a 30-day session alive even after SSO access has been removed. That means the control boundary sits at federation, while the real access state persists inside the app. Practical implication: offboarding must verify app-level session invalidation, not just identity provider removal.

Practical implication: Verify that SaaS apps terminate their own sessions when offboarding runs, or the user may remain active after SSO removal.

How automated deprovisioning closes the offboarding gap

Automated deprovisioning works by chaining multiple revocation steps across the identity lifecycle: disable access, back up needed data, remove the user from the application, and then remove the SSO link. That sequence matters because data ownership and entitlement removal are not the same event. The article also notes API-based integrations, which allow the workflow to interact directly with applications rather than relying on the federated login layer alone. Practical implication: offboarding design should treat revocation as an ordered workflow with separate checkpoints for access, data, and account state.

Practical implication: Use ordered revocation steps so access removal, data backup, and app account deletion happen as one governed process.

Why orphaned apps become a governance problem

Orphaned apps appear when users sign up for services without a clear owner and then leave the organisation. Those apps can continue renewing, retaining credentials, and holding company data even when nobody actively uses them. That creates both security exposure and spend waste, which is why deprovisioning is also an inventory and ownership problem. In governance terms, an offboarding process is incomplete if it does not surface hidden app ownership. Practical implication: lifecycle controls need application inventory and ownership resolution, not only termination triggers.

Practical implication: Track app ownership during offboarding so abandoned SaaS accounts do not remain active or auto-renew after departure.

Threat narrative

Attacker objective: Retain unauthorized access to company applications and data after the employment relationship has ended.

1. Entry occurs through a departing employee’s still-valid app session or retained SaaS access after SSO removal.
2. Credential or session abuse continues because the application preserves local authentication state beyond the identity provider’s control.
3. Escalation happens when the former user reaches customer, employee, or internal operational data that should have been revoked.
4. Impact can include data leakage, compliance failure, reputational damage, and misuse of company information after offboarding.

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

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.

Offboarding is a three-state governance problem, not a checkbox: Access removal, data retrieval, and entitlement reassignment are separate control states that must complete in sequence. When organisations compress them into one SSO event, they lose assurance over what was removed, what was preserved, and what remains exposed. The practitioner takeaway is that offboarding needs workflow evidence, not just intent.

Orphaned apps create identity debt after user departure: When users self-provision SaaS tools and then leave, ownership often disappears with them. That leaves live licenses, retained data, and uncontrolled access paths outside normal joiner-mover-leaver discipline. The result is not just security risk but lifecycle debt that accumulates until inventory and ownership are reconciled.

App-level revocation is the real control point for departing users: The article makes clear that the decisive action is not the logout screen, but the application’s own account state and session handling. SSO can support the process, but it cannot substitute for direct deprovisioning where the app keeps independent access state. Practitioners should treat app-native revocation as the governance anchor.

Offboarding failures are now an audit and breach issue, not an HR afterthought: Former employee access can trigger data breach, data loss, and compliance exposure when revocation is incomplete. That pushes offboarding into the same control conversation as access reviews, application ownership, and privilege recertification. The field should stop treating departure workflows as back-office administration.

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.
• 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.
• Read next: NHI Lifecycle Management Guide

What this signals

Offboarding control debt: A departure process that stops at SSO leaves a gap between identity removal and real application revocation. That gap is where former users retain access, so the governance model has to follow the app session, not just the directory state.

Teams should treat orphaned SaaS ownership as an identity lifecycle defect, not a software housekeeping issue. Once ownership disappears, access, renewal, and data retention can continue without anyone accountable for closure.

The operational test is simple: if a departing user can still reach app data after the offboarding workflow claims completion, the lifecycle process failed. That failure belongs in access reviews, audit evidence, and deprovisioning design, not in exception handling.

For practitioners

• 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.
• Separate backup from revocation Confirm that data export, preservation, and reassignment happen before entitlement removal so offboarding does not destroy needed records or leave them stranded.
• Review deprovisioning logs and alerts Use sign-in records, audit logs, and access logs to spot ex-employees who still have an active app path after the termination workflow completes.

Key takeaways

• The article shows that SSO removal alone does not guarantee offboarding, because SaaS apps can keep their own session and account state alive.
• Zluri reports that 37% of companies rely on SSO for SaaS deprovisioning and 18% still handle it manually, which helps explain why gaps persist.
• Effective offboarding requires ordered revocation, data backup, and application-level removal so former users do not retain access after departure.

Key terms

• 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.
• 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.
• Application Session: An application session is the period during which the app treats a user as authenticated and allowed to act. The session may outlive the original login event, so its lifetime, termination rules and re-authentication triggers must be governed explicitly.
• Orphaned Application: An orphaned application is a business app without a clear current owner or steward. These tools often remain active after the original user leaves, which creates hidden access, renewal costs, and governance gaps because nobody is responsible for revoking, reviewing, or retiring them.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management 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 or IGA programme, it is worth exploring.