The SSO tax looks like a budget line. It's actually a decision about which applications live inside your identity perimeter and which ones you'll manage by hand, indefinitely.
Here's a decision every IT leader has made, usually without framing it this way: an app your team already uses offers SAML support, but only on the enterprise tier, at three times the per-seat price. You look at the delta, decide the app isn't critical enough, and stay on the standard plan.
Reasonable call. Except that app just exited your identity perimeter.
Nobody offboards its users when they leave, because your SSO doesn't know the app exists in that workflow. Nobody enforces MFA on it, because MFA enforcement lives at the SSO level and this app never connected to it. Nobody reviews who has access, because your access review tooling pulls from the systems you've integrated, and this one sits outside them. The money you saved became risk you now carry, and unlike the invoice, the risk doesn't show up in any dashboard.
That's the SSO tax. Not the pricing practice itself, which is well documented and much complained about, but its downstream effect: a fragmented identity perimeter where the apps behind SSO feel governed and the majority outside it are effectively unmanaged.
What the SSO Tax Is
The SSO tax is the practice of gating single sign-on support (usually SAML or OIDC) behind a vendor's most expensive tier, even when the customer needs nothing else from that tier.
The markup is rarely modest. Community-maintained trackers like ssotax.org have documented vendors charging two to four times the base per-seat price for the tier that includes SSO, with some cases running far higher. The customer isn't buying advanced features. They're buying one checkbox: the ability to authenticate through their own SSO.
The vendor logic is straightforward price discrimination. SSO is a feature that companies with security requirements need, and companies with security requirements tend to be enterprises, and enterprises can pay. So SSO becomes the fence between the self-serve plan and the sales-assisted plan. It works commercially, which is why it persists despite years of public pressure.
The problem is what it does to the buyer's security posture. SSO isn't a luxury feature like advanced analytics or custom branding. It's the mechanism by which an organization extends its authentication policy (MFA, session controls, conditional access, centralized revocation) to a third-party app. Pricing it as a premium feature means pricing basic security hygiene as a premium feature.
The Real Cost Isn't the Invoice
Most SSO tax coverage stops at the pricing complaint. The more useful question is what happens to the apps where you decide not to pay, because in any real SaaS stack, that's most of them.
The average mid-size company runs hundreds of SaaS applications. Even organizations with mature identity programs typically have only a fraction of those connected to SSO. Some apps don't support SSO at all, but for many others, the tax is the reason: multiplied across dozens of tools, paying it everywhere is genuinely unaffordable. So teams pay for the critical systems and skip the rest.
Every skipped app inherits the same four problems:
Offboarding breaks. Someone has to remember the app exists and remove the user by hand. Orphaned accounts become the steady state, not the edge case.
Authentication policy stops at the perimeter. MFA enforcement and session controls only apply to apps behind SSO. Everything outside is on its own.
Access reviews go blind. Apps outside SSO never appear in a review built on SSO group membership. You certify what you can see and miss the rest.
Shared credentials creep in. When per-seat pricing meets an unconnected app, teams share logins. The access can't be attributed to an individual, which is a problem the moment an auditor or incident responder asks who did what.
None of this shows up when the decision is made, because the decision is made in a procurement context: is this app worth 3x? The security consequence lands months later, never traced back to the pricing decision that caused it.
This hidden, compounding cost is large enough that we've mapped it as its own concept: the Access Tax, the cumulative price of governing identities without complete visibility. [Link: From SSO Tax to Access Tax.] For this article, the short version is enough: every app you skip the tax on needs a governance plan of its own.
Deciding Which Apps Are Worth the Tax
Since paying the tax everywhere isn't realistic, the practical question is prioritization. Three factors do most of the work.
Data sensitivity. Apps holding customer data, financial records, source code, or PII justify the tax before anything else does. If a breach of the app would trigger disclosure obligations, it belongs behind SSO.
Blast radius of the access. An app with admin capabilities over other systems (a CI/CD platform, an MDM, a data warehouse) concentrates more risk than its seat count suggests. Rank by what the access can do, not by how many people have it.
Compliance scope. If the app touches systems in scope for SOX, HIPAA, PCI DSS, or your SOC 2 audit, the cost of demonstrating access controls manually, audit after audit, usually exceeds the tax within a year or two. Pay it and centralize the evidence.
Everything below those thresholds is where the tax genuinely isn't worth paying. Which leaves the real problem: those apps still need discovery, offboarding, and access review coverage. Skipping the tax can't mean skipping governance.
Closing the Gap Without Paying the Tax
The standard workarounds fall short in predictable ways. Password managers give non-SSO apps better credentials, but don't provide offboarding automation or access visibility. Spreadsheet inventories decay the week after they're built. Accepting the risk works until the first orphaned account with live access to something that mattered.
The structural fix is separating two things the SSO tax bundles together: authentication and governance. SSO gives you both for connected apps, which is why it's valuable. But governance (knowing the app exists, knowing who has access, removing access when someone leaves, reviewing access on a schedule) doesn't have to depend on SAML support.
Zluri is an identity security platform for autonomous enterprises, built to govern access across every application, whether it sits behind SSO or not. Its discovery engine works through five parallel pathways (direct API integrations with the applications themselves, finance and expense system data, and endpoint-level signals) so an app surfaces in your inventory even when it never touches your SSO. From there, the governance workflows that SSO-connected apps get by default extend to everything else: automated deprovisioning removes a departing employee's access inside each application rather than only at the SSO level, and access reviews can be scoped at the application, group, or user level so non-SSO apps appear in the same certification cycle as everything else.
The effect on the SSO tax decision: it goes back to being what it should have been all along, a cost decision. You pay the tax where centralized authentication genuinely matters, skip it where it doesn't, and either way, the app stays inside your identity perimeter. The vendor's pricing tier stops deciding your security posture.
Frequently Asked Questions
What is the SSO tax?
The SSO tax refers to the practice of SaaS vendors offering single sign-on support (SAML or OIDC) only on their most expensive pricing tier, often at two to four times the base price. Customers who need SSO for security reasons are forced to buy a tier whose other features they may not need.
Why do vendors charge extra for SSO?
It's price discrimination. Companies that require SSO tend to be larger organizations with security and compliance requirements, and they have more budget. Gating SSO behind the enterprise tier lets vendors segment those buyers into higher-priced plans, even though the marginal cost of providing SAML support is low.
Is the SSO tax a security risk?
Indirectly, yes. Because the tax makes SSO unaffordable across a full SaaS stack, most organizations connect only a fraction of their apps to SSO. Every app left outside loses centralized offboarding, MFA enforcement, and access review coverage, creating orphaned accounts and audit blind spots.
Which apps should I pay the SSO tax for?
Prioritize apps that hold sensitive or regulated data, apps with administrative control over other systems, and apps in scope for compliance frameworks like SOX, SOC 2, HIPAA, or PCI DSS. For those, the tax typically costs less than managing access manually and proving it to auditors.
How do I secure apps that aren't behind SSO?
Treat governance separately from authentication. Use a platform that discovers applications through pathways beyond SSO (direct APIs, finance data, endpoint signals), automates deprovisioning inside each app, and includes non-SSO apps in scheduled access reviews. Zluri's discovery and governance workflows are built to cover applications regardless of whether they support SAML.
Is anyone pushing back against the SSO tax?
Yes. Community projects like ssotax.org publicly track vendors' SSO pricing markups, and there's ongoing industry pressure to treat SSO as a baseline security feature rather than an enterprise upsell. Some vendors have responded by unbundling SSO from their top tier, but the practice remains widespread.
.svg)
