Most organizations have a deprovisioning problem they don't know they have. The SSO account is disabled, the offboarding ticket is closed, and everyone believes the job is done. What nobody checks is the account still active inside Salesforce, the OAuth grant still running against the company's data warehouse, or the former employee's Slack workspace that was never connected to SSO in the first place.
SSO deprovisioning and complete deprovisioning are not the same operation. They operate at different layers, cover different scope, and leave different residual risk. Understanding exactly where SSO stops and what Zluri covers in its place is the difference between offboarding that produces real security outcomes and offboarding that produces a timestamp in an audit log.
Why SSO Was a Security Leap Forward
Before SSO, the dominant model was passwords: one per application, managed independently, with all the predictable failure modes that it produces. Users chose simple passwords they could remember, reused them across accounts, and when any one account was compromised, the attacker typically had the keys to several others. The cognitive burden of managing dozens of credentials reliably and securely is more than most humans can sustain.
SSO solved this by collapsing the credential surface. Users authenticate once through a central identity layer and that single authentication carries them through every connected application. The result is one complex password to manage (or better, no password at all with passkeys), one MFA policy to enforce, and one place to apply conditional access rules. From a security architecture standpoint, SSO is a genuine improvement on what came before it.
The problem isn't that SSO is insecure. The problem is that SSO handles authentication, and organizations have mistaken that for a complete identity security solution.
How SSO Actually Works: Authentication and Authorization
Understanding where SSO deprovisioning breaks down requires understanding what SSO is actually doing when it grants and revokes access.
SSO operates in two phases. The first is authentication: verifying that the person trying to log in is who they claim to be. This is typically handled by an identity provider (Google Workspace, Okta, Entra ID) that validates the user's credentials and issues a session token.
The second phase is authorization: checking whether the authenticated user has permission to access a specific application and at what permission level. When an IT admin grants someone access to Zoom through SSO, that grant is recorded both in the SSO system and in Zoom's own user database. When the user accesses Zoom, the SSO confirms their authentication and Zoom confirms their authorization from its own records.
This dual-system architecture is the root of the deprovisioning gap. The SSO and the application each hold a record of the user. Removing the user from SSO removes the SSO's record. It does not automatically remove the application's record.
Sessions make this worse. Once a user is authenticated and authorized, most applications maintain an active session independently of the SSO. That session continues until it expires or is explicitly terminated. For many applications, session duration is controlled by the application, not by SSO, and applications can override SSO session recommendations. Some applications set sessions to last 30 days. Others have no expiry at all. This means that even if you remove a user from SSO immediately on their last day, their active sessions in connected applications may continue running for days or weeks.
The session problem in practice: An employee signs into HubSpot through SSO on a 30-day session. They're offboarded on Day 10. Their SSO access is revoked. HubSpot's session, controlled by HubSpot, stays active until Day 30. The IT team believes offboarding is complete. The former employee can still access HubSpot for the next 20 days.
For applications with no session expiry, there is no Day 30. Access continues indefinitely until someone explicitly terminates it.
The Three Reasons SSO Coverage Is Lower Than It Looks
Even setting aside the session problem, SSO's actual reach across a typical organization's application estate is narrower than IT teams assume.
SSO requires application-side integration effort. Configuring an application to work with an SSO isn't a one-click operation from the application side. It requires development work to implement SAML, OIDC, or whatever standard the SSO supports. Many smaller SaaS vendors have done this work, but not all, and the standards landscape (SAML 1.0, SAML 2.0, OIDC, OAuth, LDAP, CAS) fragments further because different SSO vendors prioritize different standards. An application that works seamlessly with Okta may require additional configuration for JumpCloud or vice versa.
SSO is gated behind enterprise pricing. Most application vendors provide SSO support only in their highest pricing tier. This is deliberate: vendors know that SSO is a requirement for organizations with security and compliance programs, and those organizations tend to have larger budgets. The result is that organizations consistently make trade-off decisions about which applications to connect to SSO based on the cost of the enterprise tier versus the security benefit. Applications that don't make the cut sit outside the SSO perimeter entirely.
Shadow IT grows faster than SSO enrollment. Teams adopt applications continuously through corporate cards, free-tier accounts, and AI tools that came into use last quarter. Most of these never go through an IT review and never get connected to SSO. In a typical mid-size organization, the majority of applications in actual use are not behind SSO, regardless of how good the SSO program is for the applications that are.
The practical consequence is that when someone is offboarded through SSO, the SSO deactivation covers somewhere between 20% and 40% of their actual access footprint, depending on the organization's SSO adoption rate. The rest remains active until someone manually addresses it, which in most organizations means it remains active indefinitely.
What Zluri Does Differently
Zluri's core architectural difference from SSO is where it connects. SSO connects at the authentication layer: the surface where users prove who they are. Zluri connects directly with applications at the API level: the layer where user accounts, permissions, data, and sessions actually live.
This direct application integration is what makes it possible for Zluri to do things SSO cannot. SSO can tell an application that a user's authentication has been revoked. Zluri can reach inside the application and perform the specific actions required to actually remove that user's access, data, and presence.
Zluri's discovery engine finds every application in an organization's environment through eight parallel pathways: direct API integrations, finance and expense system data, endpoint agents, MDMs, CASBs, browser plugins, HRMS feeds, and SSO data. This means the full application estate surfaces in Zluri's inventory, including the shadow IT, the non-SCIM apps, and the tools that were never connected to SSO. An IT admin doesn't need to know which apps a departing employee used. Zluri has already built that picture.
The Zluri Deprovisioning Sequence
When an employee's departure is triggered (from HRMS, from SSO, or manually in Zluri), the offboarding workflow auto-populates from the employee's actual discovered access footprint. Every application they touched appears in the workflow, regardless of whether it was connected to SSO, and deprovisioning executes in a specific sequence inside each one.
- Device revocation first. Zluri revokes authentication from all of the user's devices simultaneously. If they were logged into an application across a laptop, a phone, and a tablet, all three sessions are terminated at the same time. This is the step that closes the active-session gap SSO leaves open.
- Data transfer before deletion. Before the account is removed, Zluri transfers the user's data to the appropriate owner. Documents move to the designated successor, open tickets get reassigned, Slack messages are archived for compliance, calendar events are handled, and any ongoing projects are transferred. The company's data is secured before anything is deleted.
- License removal. Zluri removes the user's account and license from the application itself, reclaiming the seat from the application's own user database, not just from the SSO.
- SSO connection removed. The SSO connection is cut last, after the application-level work is confirmed complete.
This sequence matters because the alternative (cutting SSO first and handling the rest manually later) produces the gap this article is about. The application-level steps come first. The SSO step closes the loop.
What Zluri Monitors After the Workflow Runs
Complete deprovisioning isn't a one-time action. It's a state that needs to be confirmed and maintained.
After the deprovisioning workflow runs, Zluri continues monitoring whether the former user can still access any application. If a session wasn't fully terminated, if an API token survived the revocation attempt, or if an application outside the initial workflow scope surfaces later, Zluri flags it. The offboarding isn't treated as complete until the monitoring confirms that no access remains. If a user still has access to any application, Zluri alerts the IT team with the specific application and the specific access that remains, rather than presenting a binary "done" status that may not reflect reality.
This monitoring layer is what converts a deprovisioning workflow into deprovisioning assurance.
The Specific Gaps Zluri Closes That SSO Cannot
The Audit Evidence Difference
The compliance dimension of this difference is where it becomes most visible to organizations with active audit programs.
When an auditor asks for deprovisioning evidence, the question they're actually asking is: can you demonstrate that for each application a departed employee had access to, that access was removed, when, and by what action? An SSO deactivation timestamp answers a narrower question: when was their federated login path blocked? It says nothing about what happened inside each application, and for applications that were never connected to SSO, it says nothing at all.
Zluri's Run Logs answer the auditor's actual question. Each deprovisioning action generates a log entry: the application, the action taken, the timestamp, and the result (Completed, Failed, or Pending). Failed actions are visible immediately and can be retried or escalated. The offboarding record is a per-application confirmation set, not a single timestamp that leaves the downstream picture unaddressed.
For SOC 2, ISO 27001, HIPAA, and SOX ITGC audits, where reviewers regularly ask for deprovisioning evidence and find SSO logs insufficient, this difference is material.
How Zluri and SSO Work Together
It's worth being explicit about the relationship: Zluri and SSO are not competing solutions. They operate at different layers and are designed to be used together.
SSO remains the right tool for centralized authentication: one login, one MFA policy, one conditional access framework, applied consistently across every connected application. That's genuinely valuable infrastructure and Zluri doesn't replace it.
Zluri operates on top of that foundation. It takes SSO data as one of its discovery inputs, uses it to understand the federated application estate, and then extends governance to everything outside that estate. When a user is offboarded, Zluri handles what SSO was never designed to handle: the per-application actions, the session terminations, the data transfers, the non-SSO applications, and the post-offboarding monitoring.
The complete picture is: SSO handles who can authenticate. Zluri handles what happens to the access they accumulated across their tenure, including the access that SSO never governed in the first place.
Frequently Asked Questions
Does deactivating a user in SSO automatically remove their access everywhere?
No. SSO deactivation blocks the federated login path, which prevents the user from authenticating through SSO going forward. It doesn't deactivate their account inside each connected application, revoke API tokens or OAuth grants they issued, terminate active sessions that were already live, or reach applications that were never connected to SSO. Complete deprovisioning requires per-application action at the account level.
What is the session problem in SSO deprovisioning?
Most applications maintain an active session independently of the SSO after a user authenticates. Session duration is controlled by the application, and applications can set sessions to last anywhere from an hour to indefinitely. Revoking SSO access doesn't terminate sessions that are already active. A user deprovisioned through SSO may retain active access to connected applications for days or weeks if the application-level session isn't explicitly terminated.
Does SCIM solve this?
Partially. SCIM automates account creation and deletion for applications that support it, and when properly configured, disabling a user in SSO can trigger SCIM deprovisioning in those applications. But SCIM coverage across a typical SaaS stack is incomplete, SCIM handles account existence rather than permission configuration or session termination, and SCIM has no reach into applications outside the SSO perimeter. The session problem, API token problem, shadow IT problem, and data transfer requirement are all outside SCIM's scope.
What happens to the former employee's data when Zluri deprovisions them?
Zluri handles data transfer as part of the deprovisioning sequence, before the account is removed. Documents are transferred to the designated owner, open tickets are reassigned, Slack messages are archived, calendar access is handed over. The company's data is preserved and attributed to a named owner before the account that held it is deleted. SSO deprovisioning and most SCIM implementations delete the account without a data transfer step, which can result in company data being inaccessible after offboarding.
How does Zluri find applications the employee used that were never connected to SSO?
Through eight parallel discovery pathways: direct API integrations with applications, finance and expense system data (which surfaces SaaS subscriptions regardless of SSO status), endpoint agents, MDMs, CASBs, browser plugins, HRMS feeds, and SSO data itself. Applications that were never connected to SSO still surface through financial data, endpoint signals, or browser activity, giving Zluri a complete picture of the employee's access footprint rather than only the SSO-connected slice.
What does the audit evidence look like with Zluri vs. SSO alone?
With SSO alone, the available evidence is the SSO deactivation timestamp: when the federated login path was blocked. With Zluri, the available evidence is a per-application Run Log showing each deprovisioning action, the application it was performed in, the timestamp, and the result (Completed, Failed, or Pending). For compliance frameworks that ask for confirmation of access removal at the application level (SOC 2, ISO 27001, HIPAA, SOX ITGC), the Run Log answers the question the SSO timestamp cannot.
.svg)
