Offboarding deprovisioning exposes the limits of SSO-only control

At a glance

What this is: This is an analysis of why manual offboarding and SSO-only deprovisioning leave residual access, data exposure, and orphaned apps behind.

Why it matters: It matters because identity teams must treat offboarding as a full lifecycle control across human accounts, SaaS apps, and downstream access paths, not just an HR exit task.

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.

👉 Read Zluri's analysis of automated deprovisioning during offboarding

Context

Offboarding is the point where identity governance either closes the loop or exposes the gaps. In practice, the problem is not only terminating a person’s account, but revoking every connected SaaS session, API path, data store, and delegated entitlement that may still function after the employment relationship ends.

For IAM and IGA teams, this is a lifecycle issue, not a single control. If deprovisioning stops at SSO or HR termination, the organisation can still carry residual access in application sessions, orphaned apps, and retained data copies that outlive the employee’s role by days or weeks.

Key questions

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. That creates a mismatch between identity governance and actual access. Teams need to verify revocation at the application layer, not assume federated logout is enough.

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. If those paths are not explicitly closed, the user can still view, copy, or alter company information. The risk is lifecycle residue, not just malicious intent.

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. Good signals include cleared sign-in activity, removed app entitlements, transferred file ownership, and no remaining subscription charges for abandoned tools. If any one of those is missing, the workflow is incomplete.

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.

Technical breakdown

Why SSO-based deprovisioning leaves residual access

Single sign-on centralises authentication, but it does not automatically terminate every application session or internal authorisation state. Many SaaS applications maintain their own session lifetime, cached tokens, or independent logout behaviour, which means revoking the federated login can leave access active until the app expires the session on its own. That creates a mismatch between identity source control and application enforcement. In lifecycle terms, the identity may be offboarded in one system while still alive in another.

Practical implication: inventory which apps honour federated revocation immediately and which keep sessions alive after SSO removal.

Why offboarding must include data backup and reassignment

Offboarding is not only about removing access. It also has to preserve business continuity by transferring documents, ownership, and operational context to the next responsible person. If data backup and reassignment happen too late, teams risk losing institutional knowledge, interrupting workflows, or forcing users to recover files from personal copies. The governance gap appears when identity revocation is treated as separate from data stewardship, even though both are part of the same exit process.

Practical implication: build data handoff into the same workflow that revokes access, rather than treating it as a separate manual task.

Why orphaned apps are a lifecycle and spend problem

Applications can remain active without a clear owner when employees self-provision tools outside central governance. After departure, those apps may continue billing, retain data, and preserve hidden access paths that no one is monitoring. This is a classic lifecycle failure because the application survives the identity that created it. From an IAM perspective, the issue is not merely unused software, but unmanaged entitlements with no accountable owner or offboarding trigger.

Practical implication: assign ownership to every business app and tie deprovisioning checks to application discovery, not just HR exit lists.

Threat narrative

Attacker objective: The attacker objective is to preserve or exploit access after offboarding in order to reach company data that should have been withdrawn.

1. Entry occurs when a former employee still has an active SaaS session, cached token, or app-specific access after the HR exit event.
2. Escalation happens when SSO revocation does not clear the application’s own session state, allowing continued use of data, files, or connected tools.
3. Impact follows when retained access is used to read, alter, or remove business data, or when orphaned apps keep exposing information after the employee has left.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

SSO-only deprovisioning creates a false sense of finality. SSO centralises the user journey, but it does not guarantee application-level revocation, especially where SaaS vendors preserve their own session windows. This is the kind of control gap that turns termination into residual access risk. IAM teams should assume the user may still be present until every connected application has explicitly confirmed revocation.

Orphaned applications are hidden identity assets with no accountability owner. When employees self-provision tools and leave, the app can keep renewing, storing data, and retaining access paths long after the original user has gone. That breaks the basic governance assumption that every access path has a current steward. The implication is that discovery and ownership mapping must be part of offboarding, not a separate hygiene exercise.

Retrieval, revocation, and reassignment are the three offboarding primitives that matter. Separating them creates blind spots where data is preserved but access remains, or access is removed but ownership is lost. The article is effectively describing a full identity lifecycle control, not a point-in-time admin task. Practitioners should align HR triggers, app-level revocation, and data handoff in one governed workflow.

Lifecycle governance is the only durable answer to post-employment risk. The article’s core lesson is that former employees become a security problem when the organisation lacks a complete view of where their access persists. That spans human identity, SaaS access, and the downstream data plane. Security teams need to measure offboarding completeness, not just completion speed.

From our research:

• 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.
• That pattern aligns with the NHI Lifecycle Management Guide, which frames lifecycle closure as a governance process, not a single administrative action.

What this signals

Offboarding maturity is becoming a practical test of whether an identity programme can see beyond the login event. When 67% of executives already worry about former employees causing unintended breaches, the operational issue is not awareness but execution across apps, data, and ownership handoff.

Residual access debt: this is the accumulation of app sessions, orphaned subscriptions, and unrevoked entitlements that survive the formal exit event. Programmes that cannot measure residual access debt will keep mistaking deprovisioning activity for deprovisioning outcomes.

The next maturity step is to connect HR triggers, SaaS discovery, and access audit evidence into one offboarding control loop. That is where the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs becomes useful as a lifecycle reference point, even when the subject is human identity.

For practitioners

• 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. Use that map to eliminate SSO-only assumptions and verify that revocation reaches each app that stores company data.
• 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. This reduces data loss and avoids leaving critical content trapped in ex-employee accounts.
• Create an orphaned-app review at every exit Check for self-provisioned applications, unmanaged integrations, and any renewed subscriptions that remain after departure. Tie the review to app discovery and expense systems so abandoned tools cannot keep renewing without an accountable owner.
• Verify access removal with audit and sign-in evidence Confirm that the departing user no longer appears in access logs, sign-in records, or app audit trails after the offboarding workflow completes. Where evidence still shows activity, treat the workflow as incomplete and reopen the case.

Key takeaways

• The article shows that offboarding breaks down when identity revocation is not matched by application-level session termination and data handoff.
• The scale of the problem is visible in Zluri's own figures, including 37% of companies using SSO for SaaS deprovisioning and 18% still doing it manually.
• The control that matters most is a governed lifecycle workflow that closes access, transfers data, and clears ownership in the same process.

Key terms

• Offboarding: Offboarding is the controlled removal of a person’s access, data dependencies, and application ownership when they leave the organisation. In identity programmes, it must cover authentication, app entitlements, session state, data transfer, and accountable ownership so that the departure does not leave residual access behind.
• Residual Access: Residual access is any permission, session, token, or app-specific state that continues to work after a user should no longer have access. It is a lifecycle failure, not just a permissions error, because the organisation has formally ended the relationship but the technical access path still exists.
• 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, 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Automation How IT Teams Can Automate Deprovisioning During Offboarding. Read the original.