SSO doesn't have a security vulnerability problem. It has a coverage problem. The credential gets phished, the session token gets stolen, the orphaned account sits active for months: in each case, the failure isn't a bug in SSO. It's a gap in what SSO was ever built to cover. Treating these as the same kind of problem produces the wrong response to most of them.
The conventional SSO security checklist reads like a hardening guide: enforce MFA, shorten token lifetimes, implement conditional access, audit regularly. These are real controls that address real risks at the authentication layer.
They're also incomplete. The risks that produce the most persistent and hardest-to-detect exposure live below that layer, in the governance gaps SSO creates by design when it leaves most of an organization's application estate outside its perimeter.
Understanding which risks are authentication problems and which are governance gaps is the prerequisite for a program that actually closes them. The two categories require completely different responses.
The Authentication Risks (Real, But Often Overstated)
SSO concentrates authentication risk. By routing all access through one credential and one session model, it raises the stakes on any failure at the authentication layer. These risks are genuine and require genuine controls. They're also the risks the industry understands best and invests in most heavily.
Credential compromise through AiTM. The threat most organizations are underdefended against isn't basic phishing. It's Adversary-in-the-Middle phishing, which intercepts the authentication session in real time and captures the session token after MFA has already completed. Push-notification MFA doesn't protect against this. The user approves the prompt; the attacker receives a valid session. Phishing-resistant MFA (FIDO2 security keys or passkeys) closes this vector because authentication cryptographically binds to the legitimate domain. A captured credential cannot replay against a spoofed page. For SSO admin accounts specifically, this isn't optional. They're the single most valuable phishing target in any environment.
Session token theft. A session token is what downstream applications trust after authentication. Stealing it bypasses SSO entirely because the authentication event already happened. Browser-based token exfiltration via malware or compromised extensions is common enough that endpoint security and SSO security now belong in the same conversation. Short token lifetimes, device binding, and step-up re-authentication for high-risk actions are the controls.
Single point of failure. If SSO goes down, authentication breaks across every connected application simultaneously. In practice, major providers run at high availability and true outage risk is lower than most organizations' other failure modes. The version that actually occurs is a locked account with no rehearsed recovery path. Breakglass procedures and tested recovery paths are the answer.
The key point about all three: they have authentication-layer controls. Better MFA type, tighter session policy, breakglass procedures. Legitimate hardening practices, worth doing. But they address what SSO was built to do. The governance gaps are different in kind, not just in degree.
The Governance Gaps (Persistent, Structurally Created, Not Patchable)
A common and costly misunderstanding: Many organizations believe SSO handles identity governance because it manages authentication and controls who can log in. It doesn't. SSO was designed to centralize the login event. What happens before that event (how access was provisioned), after it (what permissions the user holds inside the application), and beyond it (the 60-80% of the stack that was never connected to SSO) are outside SSO's scope by design. This isn't a gap vendors will fill with a configuration change. It's an architectural boundary.
The risks below exist not because SSO has weaknesses, but because SSO has boundaries. These gaps aren't bugs. They're the inevitable consequence of what authentication infrastructure was designed to do, and what it was never asked to do.
Gap One: The Provisioning Gap
The misunderstanding: SSO provisions users into applications, so access should be correct from day one.
The reality: SSO and SCIM provision user accounts. They don't provision the actual entitlements inside applications.
Creating an account in Salesforce is one action. Assigning the right profile, the right permission sets, the right account territories, and the right report visibility is a separate set of actions that happens manually after the account exists. The same pattern repeats across every application: account creation is automated, permission configuration isn't.
At join, users often get broader access than their role requires because it's faster to give them what the previous person in the role had than to scope carefully from scratch. Over every subsequent role change, access accumulates rather than adjusts.
SCIM's model was designed for joiners and leavers, not the mid-lifecycle changes (promotions, lateral moves, contractor engagements, leaves of absence) where most privilege accumulation happens. The gap compounds over the typical tenure of an employee, and no SSO hardening practice closes it. It's structural.
Gap Two: The Deprovisioning Gap
The misunderstanding: Disabling someone's SSO account removes their access. Offboarding is complete.
The reality: When an employee leaves and the SSO account is deactivated, one thing happens: the federated login path is blocked. Everything else survives.
The account inside each connected application stays active unless something explicitly removes it. API tokens and OAuth grants issued from that account remain valid until separately revoked. Active sessions that were already running continue until they expire on the application's own schedule, which can be 30 days or indefinite depending on the application's session management. Every application outside the SSO perimeter is untouched entirely because SSO never governed it.
The session problem in practice: An employee signs into HubSpot on a 30-day session. They're offboarded on Day 10. Their SSO account is disabled immediately. HubSpot's session runs until Day 30, controlled by HubSpot's own session management, not by SSO. The IT team believes offboarding is complete. The former employee has active HubSpot access for 20 more days. For applications with no session expiry, access continues indefinitely.
SCIM narrows this gap for applications that support it. But SCIM coverage across a typical SaaS stack is partial, SCIM handles account existence rather than API tokens and active sessions, and SCIM has zero reach into applications outside the SSO perimeter. The deprovisioning gap that remains is structural.
Gap Three: The Privilege Accumulation Gap
The misunderstanding: SSO manages group-based access, so access stays aligned to roles over time.
The reality: Group-based access is efficient to configure and systematically prone to decay.
Someone joins a group for a project. The project ends. The membership persists. Across promotions, lateral moves, and role changes, users accumulate group memberships that nobody tracks and nothing removes. Groups that started specific become broad through accumulated convenience. Mappings that bundle three applications because one rule was easier than three produce access nobody consciously decided to grant together.
Access reviews are the control, but access reviews built on SSO group data are reviewing group membership, not entitlements. "Member of the Engineering group" tells a certifier nothing about which GitHub repositories, which AWS accounts, which database schemas, or which deployment pipelines that membership grants. Reviews at the group level generate compliance checkboxes. They don't catch privilege creep at the permission level where it actually lives.
No SSO control prevents this. It's the expected behavior of a group-based access model without periodic entitlement review.
Gap Four: The Perimeter Gap
The misunderstanding: SSO covers all apps. If it's connected, it's governed. If it isn't connected, the team doesn't need it.
The reality: In most organizations, the majority of the SaaS stack was never connected to SSO, and it's not because nobody tried.
Some applications don't support SAML or OIDC. Others support SSO only on enterprise pricing tiers that organizations chose not to pay (the SSO tax). Others are shadow IT: tools adopted on corporate cards, free-tier accounts, AI tools that teams started using last quarter without IT involvement.
For all of them, SSO's controls don't apply. No centralized authentication, no MFA enforcement through SSO policy, no federated deprovisioning, no appearance in SSO-based access reviews.
A typical mid-market organization has SSO enrollment covering somewhere between 20% and 40% of its actual application estate. The other 60-80% exists outside the SSO perimeter entirely, holding real data, with real access, that receives none of the governance the SSO program was supposed to provide.
This is not a configuration failure. It's the architectural consequence of an SSO tax that makes universal enrollment economically unviable and a shadow IT growth rate that outpaces any IT enrollment process. The perimeter gap is structural, and it grows.
Why the Two Categories Require Different Responses
Authentication risks require authentication controls: a better MFA type, tighter session policy, conditional access rules, breakglass recovery paths. These are configuration and deployment decisions within the SSO platform itself, addressable without adding a new layer to the identity stack.
Governance gaps require a governance layer. No SSO configuration closes the provisioning gap, because SSO wasn't designed to configure permissions inside applications. No SSO configuration closes the deprovisioning gap, because SSO can't reach into applications to terminate sessions and revoke tokens. No SSO configuration governs the perimeter gap, because SSO has no visibility into applications outside its federation.
These gaps exist at the boundary of what authentication infrastructure does. Closing them requires infrastructure designed to operate beyond that boundary.
The reason most SSO security programs underperform isn't that the authentication hardening is wrong. It's that the governance gaps never get a governance layer.
The Compound Risk
Authentication controls and governance gaps don't operate independently. They multiply.
Authentication controls reduce the probability of the initial compromise. Governance controls reduce the severity of what follows. A security program that invests in one without the other is optimizing half the equation.
The blast radius of a compromised SSO credential is determined entirely by the entitlement structure behind it. In an organization with mature access governance (least privilege enforced at the permission level, access reviews current, shadow IT contained, deprovisioning complete), one compromised credential is a serious incident with limited scope.
In an organization where entitlements have accumulated across role changes, where 70% of the application estate is outside SSO, and where orphaned accounts persist from departures months ago, the same compromised credential reaches an order of magnitude more. Same authentication failure. Completely different outcome. The difference is governance.
What Closes the Governance Gaps
Each gap has a specific closure requirement that SSO cannot provide.
The provisioning gap closes when lifecycle automation configures actual permissions inside applications, handles mid-lifecycle changes that SCIM doesn't model, and enforces least privilege at the permission level rather than the group level.
The deprovisioning gap closes when per-application workflows execute inside each application at the account and permission level, terminate active sessions directly rather than waiting for expiry, revoke API tokens and OAuth grants, and cover the non-SSO application estate through discovery pathways beyond what SSO can see.
The privilege accumulation gap closes when access reviews use actual entitlement data (what permissions a user holds inside each application, when they were last used, whether they align with the current role) rather than group membership lists.
The perimeter gap closes when discovery finds applications through pathways SSO doesn't: finance and expense system data, endpoint agents, browser signals, MDM data, and direct API integrations. Applications that never generated an SSO signal still surface through financial data and endpoint activity.
Zluri is an identity security platform for autonomous enterprises built to close these gaps alongside whichever SSO platform is already in place.
Discovery runs through eight parallel pathways (direct API integrations, finance and expense system data, endpoint agents, MDMs, CASBs, browser plugins, HRMS feeds, and SSO data) so the full application estate surfaces in one inventory.
IRIS, Zluri's Identity Risk Intelligence System, continuously scores identity risk across the full estate and surfaces remediations through 1,500+ automated actions.
Lifecycle automation handles provisioning and deprovisioning at the application level with per-action Run Logs confirming completion. Access reviews run with actual entitlement and usage data across the full estate, including non-SSO applications.
SSO handles authentication. Zluri handles the governance terrain that authentication infrastructure wasn't designed to cover.
Frequently Asked Questions
Is SSO a security risk?
SSO is a net security improvement over distributed password-based authentication. The risks associated with SSO are concentration risks (one credential now covers more surface) and coverage gaps (the majority of most organizations' application estates sit outside SSO). The concentration risks are addressed by SSO-layer controls. The coverage gaps require a governance layer that SSO wasn't designed to provide.
What's the difference between an SSO vulnerability and an SSO governance gap?
An SSO vulnerability is a weakness in the authentication layer itself: a credential that can be phished, a session token that can be stolen, a platform that can go down. These have authentication-layer fixes. An SSO governance gap is a category of risk that exists not because SSO is weak but because SSO has architectural boundaries. It governs what's connected to it and has no reach into what isn't. These require a governance layer, not better authentication controls.
Why doesn't a phishing-resistant MFA solve the deprovisioning gap?
Phishing-resistant MFA closes the AiTM credential relay attack vector at the authentication layer. The deprovisioning gap is a different category of problem: it exists because SSO deactivation doesn't remove accounts inside applications, revoke API tokens, terminate active sessions, or reach applications outside the SSO perimeter. MFA hardening and deprovisioning completeness are solutions to different problems.
What is the perimeter gap?
The perimeter gap is the population of applications in actual use that were never connected to SSO. In most organizations this represents 60-80% of the SaaS stack by application count. Applications outside the SSO perimeter receive none of SSO's controls: no centralized MFA, no federated deprovisioning, no access review coverage. The gap is structural, driven by the SSO tax, incomplete SAML support across vendors, and shadow IT adoption that outpaces IT enrollment.
Does Zluri replace SSO?
No. Zluri and SSO operate at different layers and are designed to complement each other. SSO handles authentication at the login event. Zluri handles identity governance across the full application estate and the full identity lifecycle. SSO data feeds Zluri's discovery as one of eight pathways, and Zluri's governance extends to everything SSO can't reach.
.svg)
