Charging extra for SSO is charging extra for not getting breached

Pick a SaaS product. Find its pricing page. Look for SAML.

It’s in the enterprise tier. There’s no price next to it. There’s a “Contact Sales” button, and the jump from the tier below is frequently three or four times the per-seat cost — for a feature that is, on the vendor’s side, a well-documented library and a settings page.

This has a name — the SSO tax — and it’s been a running argument for years, with a website that names offenders. The argument gets framed as pricing gouging, and it is, but that framing undersells the problem.

What you’re actually being sold

SSO is not a convenience feature. It’s not “one less password.” It is the mechanism by which access to a system is derived from employment rather than stored independently of it.

Without it, every SaaS product your company uses holds a separate credential with its own lifecycle. When somebody leaves, offboarding is a checklist — a human being visiting forty admin panels and clicking Remove, in an order nobody documented, with no way to verify completeness. The failure rate on that process is not zero and it is not close to zero. Accounts get missed. They get missed for years.

With SSO — and with SCIM, which is usually paywalled alongside it and is the half that actually matters — deprovisioning in the identity provider revokes access everywhere, immediately, verifiably. That’s not a nicer login experience. That’s the difference between “we removed their access” being a claim and being a fact.

So the pricing model says: the ability to reliably remove a departing employee’s access is an enterprise feature. Small companies, who have the least security staff and the highest turnover volatility, get the version where offboarding is a spreadsheet.

The defense, and why it’s half-true

Vendors say enterprise SSO customers cost more to serve. That’s genuinely true, and I’ll grant it more than most people do. SAML integrations mean supporting somebody’s twelve-year-old on-prem ADFS deployment, metadata that doesn’t validate, certificates that expire without warning, and a customer whose IdP admin is a contractor who left. Those support tickets are expensive and they are miserable.

But that’s an argument for charging for support, and the pricing doesn’t look like support pricing. It looks like segmentation: SSO is a reliable marker of “this buyer is a real company with a security review,” so it’s the flag that moves them into the tier where the price is whatever the sales team thinks they’ll pay. The feature is a proxy for willingness to pay. Everyone in the industry knows this and mostly says it out loud in private.

The tell is that OIDC — which is not ADFS, which is a JSON API and a redirect, which costs approximately nothing to support — sits behind the same wall at most of these vendors. There is no support-cost story for that. There’s only the segmentation story.

I expected this to stay broken

For years my position was that nothing changes here, because the incentive is too clean: security features are the perfect segmentation flag precisely because the buyer can’t credibly walk away from them.

I was too pessimistic, and the reason is interesting. It didn’t move because vendors got principled. It moved because security questionnaires got teeth. Once mid-market buyers started failing their own compliance reviews for using tools without SSO, the paywall stopped being a way to extract money from those buyers and started being a reason they bought something else. A few vendors noticed and moved SSO down-tier, loudly, as a marketing move. That works. It works because it’s cheap to do and it wins deals.

That’s the lever, and it’s the only one that’s ever moved this. Not shaming. Not blog posts, including this one. Procurement saying “this fails our review” — and meaning it.

What to do

Put SSO and SCIM in your evaluation criteria as a hard requirement, not a nice-to-have, and tell the vendor that’s why you’re not buying. Vendors track lost-deal reasons obsessively; it’s one of the few signals that reliably reaches product.

And if you’re the one setting pricing at a software company: put SSO in every tier. Charge for seats, charge for volume, charge for support, charge for the things that actually cost you money to provide. Don’t build a business model where your customers’ security posture is the thing you’re holding hostage. You will get away with it for a while. Then somebody’s breach postmortem will name the ex-employee account nobody could remove, and it’ll name your pricing page in the same paragraph.