The SSO Tax is Smart Business, and Bad Security

For years, people have criticized the “SSO Tax”, SaaS companies' practices of limiting single-sign-on to only their more expensive plans, effectively imposing a tax on organizations that care about security. The critique is straight-forward: SSO is good for security, if you charge more for it fewer people will buy it, and you’ll get less security. Sometimes this is generalized into: it’s bad to charge for any security features, for the same reason (some people replace “bad” with “unethical”). The basic observation here is accurate: if you charge more for security, you’ll get less security. But that’s not enough to tell us what to do.

Our first question needs to be: Why do SaaS companies impose an SSO tax in the first place? And the primary answer is that they need some way to segment their customers. SaaS companies frequently have free or cheap plans, and frankly, those often have nearly all the functionality one needs to use the core of their product. SaaS companies need something they can charge enterprises for, in order to make the financial arithmetic work: charge enterprises a large premium, while providing substantially the same service to companies on the free plan. And security features, particularly SSO, are the sort of thing an enterprise will pay for. This is a fairly textbook example of customer segmentation. Any alternative we want to see in the world has to account for this.

The other reason I’ve heard companies identify for their SSO tax is customer support. Configuring SSO can be fiddly, with customers often locking themselves out of their accounts entirely. Therefore, offering SSO requires a greater investment in customer support, and cannot reasonably be supported on cheap or free plans. Unlike the customer segmentation rationale, this is not intrinisic to SSO: presumably if customer support needs for SSO were dramatically reduced, companies would not raise this concern.

A topic many policy makers care about is small businesses' security. They are also one of the cohorts most negatively impacted by the SSO tax. Their economics rarely allow paying the SSO tax, they lack the IT and security staff to compensate for the lack of SSO, and their security is nevertheless important. From a public policy perspective, if we want small businesses to have better security, we need to make it economical for them, which means finding some way to square the SSO tax circle.

The most muscular public policy we could imagine is: it is unlawful to charge more for security features, any security feature that you make available must be included in your cheapest plans. Alas, this has a significant downside (probably it has quite a few, but we’re going to focus on just one of them). One of the motivations for a company to develop new security features is to charge for them. While some security features must be developed in order to close any sales, many are basically discretionary, and the alternative to charging for them is not to make them free, but rather that they won’t be developed at all. For this reason, I think it’s clear that whatever we think about the SSO tax, any potential intervention doesn’t generalize to all security taxes.

To find a way out of this puzzle, we need a way for SaaS companies to segment their users, while still providing SSO to all customers. To accomplish this, my plea to SaaS companies is: include basic self-service SSO with a basic set of providers to all customers, and instead of segmenting on SSO, segment on more advanced capabilities, like SCIM, ability to use SAML providers, and central management of groups and roles.1 These are the sorts of capabilities that larger enterprises need, and will pay for, but which smaller businesses can manage without, while still giving them access to the baseline security benefits of SSO.

Offering self-service SSO for a limited set of providers has the auxiliary benefit of addressing the customer service consideration. The greatest configuration challenges (and risk of lockout) come when using things like custom SAML integrations or more advanced features; basic Google Workspace OIDC configurations are straightforward and can be supported with minimal customer service investment.

Slack is an example of a product that takes this approach, Google OIDC SSO is included in their cheapest paid plan, while SAML SSO is only available in more expensive plans. This a) demonstrate that this model can work, b) shows that the observation that companies can segment on things beyond SSO is not a novel observation, and thus asking nicely for companies to stop imposing an SSO tax is probably not sufficient.

This brings us to the conclusion that accomplishing the public policy goal of improving security (and particularly improving security for small businesses without overly burdening them) is impeded by incentives regarding SaaS pricing for SSO, and that a policy intervention is likely required to realign it. However, to make progress we need creative ideas for ways to eliminate the SSO tax, without the deadweight loss of the most obvious interventions. My hope is that by articulating this tension, it will encourage someone to use this as a jumping off point to identify new and better approaches.

  1. I have concerns that this encourages further consolidation in the market for identity providers. ↩︎