Everyone can see the SSO tax. It's on the invoice. The cost nobody itemizes is the one you pay for governing without visibility: the manual hours, the orphaned accounts, the access reviews that certify a third of your environment while the other two-thirds accumulates risk. We're calling it the Access Tax. It's time to start budgeting for it.
The SSO tax debate is legitimate. Charging 200-400% premiums for SAML support is a genuine vendor practice, well documented by the SSO Wall of Shame and much complained about in procurement conversations. The frustration is earned.
But while IT teams fixate on the tax they can see, they're simultaneously paying a larger one they can't. One that doesn't appear on any invoice, isn't captured in any vendor negotiation, and doesn't get smaller when you pay for more SSO coverage. In fact, it often gets worse.
This piece names that cost, maps what it covers, and explains why the architecture most organizations have built to contain it was never going to work.
Why Paying the SSO Tax Doesn't Solve the Problem
Most organizations approach the SSO tax as the central identity budget decision: pay it for the critical apps, skip it for the long tail, hope the coverage is enough. A 1,000-person company spending $600K annually to cover 20 critical platforms while leaving 80+ department tools outside SSO is making the best call available within the constraints. For the full breakdown of who pays, what it costs, and how to prioritize, see: The SSO Tax.
The problem isn't the decision. It's the assumption underneath it: that the apps where you do pay the tax are now governed. They're not. They're authenticated. Those are different things, and the gap between them is where the Access Tax lives.
When IT teams pay the SSO tax, they're buying two promises: centralized visibility into who's accessing which apps, and automated lifecycle management through SCIM. Both promises break in predictable ways, and the breakage is what generates the Access Tax.
Promise One Breaks: SSO Can Only See What It's Connected To
SSO governs the applications connected to it. Full stop. An application that was never brought into the SSO federation is, from SSO's perspective, absent. Not flagged as risky. Not flagged as unmanaged. Simply not there.
In practice, 60-80% of a typical SaaS stack exists outside SSO coverage: tools teams adopted on corporate cards, departmental subscriptions IT never approved, free trials that quietly became production dependencies, AI-powered tools teams started using last quarter. None of it generates a signal in SSO. None of it is in any deprovisioning workflow. None of it appears in an access review built on SSO group data.
So you pay the SSO tax for visibility. You get visibility into a third of your environment. The other two-thirds stays blind, ungoverned, and accumulating orphaned accounts with every departure and access drift with every role change.
This isn't a criticism of SSO as a product. It's an architectural constraint built into the model: SSO can only report on apps that authenticate through it. The shadow IT blind spot is structural, not a flaw.
Promise Two Breaks: SCIM Is Account Creation, Not Access Provisioning
Even in the apps where you've paid the SSO tax and enabled SCIM, the automation isn't complete. SCIM creates the user account. It doesn't provision their actual access.
The clearest way to see this is a single example. A new sales rep joins your Boston office. Here's what SCIM does and what someone still does manually in Slack alone:
SCIM handles: Creates @john.smith
Someone manually handles:
- #sales (department)
- #northeast-region (location)
- #senior-reps (seniority level)
- #enterprise-accounts (role scope)
- #all-hands (company-wide)
- #sales-leadership (manager status)
SCIM handled one step. A human handles six. Now multiply that across Salesforce (profiles, permission sets, account territories), Notion (workspaces, pages, databases), Jira (projects, issue types, board access), Confluence, Linear, and 95 other apps. You've automated roughly 20% of the provisioning work. The remaining 80% is still manual, still error-prone, and still entirely dependent on someone remembering to do it.
Three structural gaps explain why SCIM lands here:
The granularity gap. SCIM operates at the account level. It creates and deletes. It doesn't add users to groups, channels, projects, or permission sets based on department, location, seniority, or role. And when someone leaves, SCIM deletes the account but doesn't transfer document ownership, reassign open tickets, revoke device access, archive messages for compliance, or handle any of the app-specific actions that real offboarding requires. Those need deep integration with each application's own capabilities, which SCIM's standardized model was never built to provide.
The complexity gap. Implementing SCIM correctly requires configuring attribute mappings per vendor, debugging non-standard SCIM payloads when integrations break, and managing divergent vendor implementations of what's nominally a standard protocol. This is identity engineering work. Mid-market IT teams are three to five generalists managing helpdesk, procurement, security, and now identity. There's no capacity for part-time integration engineering on top.
The lifecycle gap. SCIM was designed for the endpoints of the identity lifecycle: joiner and leaver. The middle, which is where most access risk lives, isn't in the model. Promotions that add permissions without removing old ones. Lateral moves between departments. Contractor engagements with defined end dates. Leaves of absence that require suspension rather than deletion. Every one of these is handled manually, inconsistently, and at scale becomes the source of the privilege creep that auditors find.
The honest summary: you pay the SSO tax to get SSO and SCIM. SSO delivers visibility into 30% of your app estate. SCIM delivers automation for one step of the provisioning workflow. Neither delivers governance.
Introducing the Access Tax
This is the cost that has no line item.
The Access Tax is the cumulative operational cost of governing identities without complete visibility into access. It's what organizations pay when they don't know who has access to what, can't see where permissions have drifted, and are running governance programs against a fraction of their actual environment.
It shows up in four concrete ways:
Manual provisioning overhead that never goes away. Every new hire whose account SCIM creates but whose actual access (groups, channels, permission sets, project memberships) someone has to configure by hand. Every role change that requires touching a dozen apps individually. Every access request that routes through a Slack message because there's no governed request path. IT teams at organizations with 500+ employees routinely absorb 40 to 60 hours monthly on provisioning work SCIM doesn't reach. That's a full-time resource burning on a problem that doesn't appear in any budget line.
Orphaned accounts and ungoverned access piling up silently. When someone leaves, deactivating their SSO account blocks their federated login. It doesn't remove their account inside each application, revoke their API tokens, or touch anything in the 70% of the stack outside SSO. Those accounts stay active indefinitely. At normal turnover rates, organizations running this model accumulate orphaned accounts faster than any manual cleanup process can address them. Each one is a credential an attacker can purchase, a license seat being billed for nobody, and an access review finding waiting to happen.
Access reviews that certify a fraction of reality. A quarterly access review built on SSO group data covers the apps connected to SSO and nothing else. The 80 apps outside the perimeter don't appear in the review queue. Certifiers approve or revoke what they can see while two-thirds of the actual access landscape goes uncertified. The review completes on schedule. Compliance gets its checkbox. The risk accumulates in the blind spot.
Privilege creep that compounds with every lifecycle event. Every promotion that grants new permissions without removing old ones. Every lateral move that adds access to the new team's tools while the previous team's access persists. Every contractor engagement that outlasts its defined scope. SCIM's joiner-leaver model handles the endpoints; everything in between is managed manually, inconsistently, and at scale becomes the entitlement sprawl that auditors flag and attackers exploit.
Unlike the SSO tax, which is linear (a fixed per-app, per-month charge you can predict and budget), the Access Tax compounds. Each of these problems feeds the next. Orphaned accounts make access reviews harder. Manual provisioning errors create privilege creep. Blind spots in the SaaS stack mean lifecycle events in shadow IT apps go untracked entirely. There's no invoice tracking any of it, just steadily increasing manual overhead and the persistent sense that governance is broken despite everything that's been paid for.
The Compounding That Makes It Dangerous
The SSO tax is predictable and budgetable. The Access Tax grows with the organization and becomes visible only in retrospect: when the auditor asks for deprovisioning evidence and none exists, when the incident review traces an orphaned account to someone who left eight months ago, when the quarterly access review takes three weeks and still only covers a third of the environment.
Known Universe Governance: The Trap High SSO Coverage Creates
There's a dangerous assumption embedded in most identity security programs: that achieving high SSO coverage means identity governance is under control.
It doesn't. SSO tells you authentication happened. SCIM tells you an account was created. Neither tells you whether the access is appropriate, what permissions the user holds inside the app, whether their role still justifies it, or what they have access to in the apps outside your SSO perimeter entirely.
The result is what we call known universe governance: running a thorough, well-documented governance program against the slice of the environment that was already best managed, while the ungoverned slice accumulates the risk that eventually surfaces in an audit or an incident.
Consider a typical quarterly access review without discovery. You export users from your 20 SSO-connected apps, review names without entitlement context, miss the 80 apps outside SSO coverage, spend 60 hours, and certify a third of your environment. The review completes on schedule. The auditor signs off. The other two-thirds of the access landscape is untouched.
The alternative is discovery-first: start from the full application estate rather than the SSO-connected slice, pull actual entitlement data rather than account lists, surface orphaned accounts and excessive permissions before certifiers see the queue, and run a review that covers what actually needs covering. Same governance program. Fundamentally different coverage.
Discovery isn't a nice-to-have that comes after governance is working. It's the prerequisite. Governing without it means certifying what you can see while exposure accumulates where you can't. Automating provisioning without it means automating a subset of the problem and hand-managing the rest.
What Eliminates the Access Tax
Even if every SaaS vendor dropped the SSO tax tomorrow, the Access Tax would remain. The root problem isn't authentication pricing. It's the access you can't see and the lifecycle work that no standard protocol automates.
Traditional IGA platforms (SailPoint, Saviynt) were never designed for this at below-enterprise scale. They assumed the conditions large enterprises bring to a deployment: discovery already solved, identity engineers already on staff, six-to-twelve-month implementation timelines as a fact of life. The Access Tax they address is a subset of what mid-market organizations actually face, and the investment required to get there exceeds most mid-market identity budgets entirely.
The principle that eliminates the Access Tax is simpler than the traditional IGA pitch: visibility must precede governance. You can't review access you can't see. You can't deprovision from apps you don't know exist. You can't enforce least privilege across a permission structure you've never mapped. Start with the full picture, then govern it.
Getting the full stack right requires three layers:
Layer 1: Your SSO (foundation). Google Workspace, Entra ID, or Okta as the source of identity truth: who works here, core attributes, authentication. Every organization needs this layer and it should stay exactly where it is.
Layer 2: SSO and SCIM, deployed selectively. Pay the SSO tax for the 15-20 critical company-wide platforms where centralized authentication and automated provisioning genuinely earn their cost. Skip it for the long tail of departmental tools where the math doesn't work, and govern those apps through the layer below rather than trying to force federation where it isn't justified.
Layer 3: Visibility-first IGA. This is Zluri's layer, and it's where the Access Tax actually gets eliminated. Discovery runs through nine parallel pathways (direct API integrations, finance and expense system data, endpoint agents, MDMs, CASBs, browser plugins, HRMS feeds, SSO data, and manual entry) so the full estate appears in one inventory regardless of whether apps are federated. Provisioning goes past SCIM's account creation to handle granular, attribute-based access across the full app estate. No-code workflows that IT managers can configure without identity engineering resources. Full joiner-mover-leaver coverage including the mid-lifecycle changes (promotions, lateral moves, contractor engagements, leaves) that SCIM's model doesn't reach. Access reviews that cover the entire environment and give certifiers actual entitlement and usage data, not account lists.
This architecture is additive to Okta, Entra, or whatever SSO you run. The SSO layer keeps doing what it does best. The IGA layer governs everything it can't reach. The Access Tax stops compounding because the governance program finally covers the full environment that generates it.
The Only Tax Worth Stopping
The SSO tax debate isn't wrong. The Wall of Shame should keep shaming vendors who charge 200-400% premiums for what is, at this point, a baseline security feature. That pressure has worked in some cases and should continue.
But the SSO tax is capped. You pay it once per app, per user, per month. It's predictable, it's visible, and it's something procurement can negotiate.
The Access Tax has no cap. It grows with headcount, with SaaS sprawl, with every role change that nobody tracked and every shadow IT app that never entered a deprovisioning workflow. It's invisible until it isn't, and by the time it surfaces in an audit finding or a breach investigation, the cost is far higher than any SSO markup ever was.
So run the SSO tax negotiation. Get the best rate. Push vendors on bundling. And then build the governance architecture that makes the Access Tax stop compounding.
Start with visibility. Everything else follows from there.
Frequently Asked Questions
What is the Access Tax?
The Access Tax is the cumulative operational cost of governing identities without complete visibility into access. It shows up as manual provisioning overhead IT teams absorb every month, orphaned accounts accumulating across shadow IT and non-SSO apps, access reviews that certify a fraction of the actual environment, and privilege creep from lifecycle changes no standard protocol tracks. Unlike the SSO tax, which appears as a predictable invoice line, the Access Tax is distributed across dozens of manual processes and becomes visible only when it surfaces as an incident, audit finding, or governance failure.
Is the Access Tax a Zluri concept, or does the industry recognize it?
Zluri is naming and defining the Access Tax as a distinct category of identity cost, but the underlying pattern (manual provisioning overhead, shadow IT blind spots, incomplete lifecycle coverage) is documented across practitioner communities and reflected in industry research. 74% of security and IT professionals say SSO is not a complete solution for securing employee identities (1Password, 2025). 53% of breaches involve orphaned accounts that should have been deprovisioned. The Access Tax is the name for what those numbers represent in operational terms.
Does the Access Tax go away if you pay for more SSO coverage?
No, and this is the core insight. The SSO tax and the Access Tax are different costs. Paying for more SSO coverage doesn't address shadow IT (apps SSO never federated), SCIM coverage gaps (apps SSO-connected but with incomplete provisioning automation), lifecycle complexity (mid-lifecycle changes SCIM's model doesn't handle), or the entitlement visibility gap (what users can actually do inside apps, not just whether they have an account). High SSO coverage reduces one slice of the Access Tax. It doesn't eliminate it.
Why do traditional IGA platforms not solve the Access Tax for mid-market companies?
Traditional IGA platforms (SailPoint, Saviynt) were built for large enterprises and assume the conditions large enterprises bring: discovery already solved elsewhere, identity engineering teams on staff, and implementation timelines of six to twelve months. For mid-market IT teams running three to five generalists across helpdesk, procurement, security, and identity, the operational prerequisites for traditional IGA are the same as the problem they're trying to solve. Visibility-first IGA (Zluri's architecture) inverts the assumption: start with discovery across the full estate, then build governance on that foundation, without requiring a dedicated identity engineering function to get there.
What's the difference between the SSO tax and the Access Tax?
The SSO tax is a vendor pricing practice: charging a premium for SSO/SCIM support to gate it behind an enterprise tier. It's visible on invoices, predictable per app and user, and addressable through procurement and vendor pressure. The Access Tax is an operational cost: the cumulative burden of governing identities without complete visibility. It's invisible on invoices, compounds with organizational growth, and isn't addressable through vendor negotiation. You can eliminate the SSO tax entirely and still pay the Access Tax at full rate.
.svg)
