Pricing and packaging

The SSO tax

There is a public list on the internet of software companies that put single sign-on behind their most expensive plan. It has been there for years, it is long, and most of the names on it are otherwise well regarded. That a shaming list was needed at all tells you something about how the practice is viewed by the people who have to buy around it.

What the tax actually is

Single sign-on lets your company’s identity provider decide who may open an application, and, more importantly, decide when someone may no longer open it. When somebody leaves, you switch off one account and their access to everything ends. Without it, offboarding is a checklist run by a human against a list of applications that is never quite complete.

That is a security control. It belongs in the same category as audit logging and access review, not in the same category as a premium reporting add-on.

The tax is what happens when a vendor prices it as though it were the premium add-on. The pattern is consistent enough to describe generically: the base plan carries the product, the middle plan carries the features most teams need, and the top plan carries single sign-on alongside a bundle of enterprise features that a fifty-person company does not want and cannot use. To adopt one security control, you buy the bundle.

Why it happens

It is not usually malice, and it is worth being precise about that, because the honest version of the argument matters.

Enterprise identity integration does cost something. SAML behaves differently across identity providers. Misconfiguration generates support tickets that are slow to resolve and easy to get wrong. Once you sell to companies that require SSO, you inherit their procurement processes, their security questionnaires and their compliance calendars, and all of that lands on a team that was previously shipping features.

So there is a real cost, and a real price is defensible.

What is not defensible is the size of the jump. The tax appears when SSO stops being priced as a feature with a cost and starts being used as the fence around a tier. At that point its price is not related to what it costs to run. It is related to how badly the buyer needs it, which is the definition of a captive market.

What it costs the buyer

Three things, in ascending order of seriousness.

You pay for features you did not want, because the bundle is the only door. That is annoying but survivable.

You delay the control, because the jump does not fit the budget this year. That is the common outcome, and it is the one nobody puts in a case study: the company that knows it should have SSO, has priced it, and has postponed it twice.

Or you adopt the control and cut somewhere else to fund it. This is the worst outcome and the least visible, because the thing you cut is usually another piece of security work that had no lobby inside the company.

How to price around it

If you are buying, treat the tier jump as a line item and ask the vendor to justify it directly. The question that works is not “why is SSO in the top tier”, which invites a story about enterprise readiness. The question that works is: what in this tier, other than SSO, do you expect us to use? If the honest answer is “not much, most customers buy it for the SSO”, you have learned what the tier is.

Then price the alternative honestly. Strong unique credentials in a manager, mandatory two-factor everywhere it is offered, and a written offboarding checklist naming every system, run by a named person, within a stated number of hours. That is meaningfully worse than SSO, and it is meaningfully better than nothing, and it costs you a process rather than a tier.

It does not stop at single sign-on

Once a tier is built as a fence, the fence needs maintaining, and the cheapest way to maintain it is to move more security controls behind it. So the pattern spreads, and it spreads in a predictable order.

The audit log goes next, which is a strange thing to sell, because the log is being written either way. Storage is not the question. What you are buying is permission to read the record of what was done to your own data, and you need that record most acutely in a dispute, an investigation or a departure that turned hostile, which are exactly the moments when you have the least leverage to negotiate a tier upgrade.

Then automated user provisioning, so that the identity system you were told to adopt cannot actually create or remove accounts without a further purchase. Then IP allow-listing. Then, in the more aggressive cases, the ability to enforce two-factor authentication as a policy rather than leaving it to each employee to remember.

Each of these has a defensible engineering cost, and none of those costs is why they cluster in the same tier. They cluster because they are the controls a security review asks about, which makes them the controls a buyer cannot walk away from.

What a fair price looks like

There is a straightforward test, and it does not require you to know anything about the vendor’s cost structure.

A feature priced on its cost scales with usage or complexity, and it can be bought on its own. A feature priced as a fence scales with your desperation, and it can only be bought as part of something else. Ask whether you can buy the control by itself. If you cannot, and the vendor cannot explain why not in terms of how the software is built, you have your answer.

The second test is what happens to the price when you say no. A cost-based price does not move much, because the cost did not move. A fence price moves a great deal at the end of a quarter, which tells you it was never about the cost.

Neither test requires you to accuse anyone of anything. Both are just questions, and an honest vendor answers them without difficulty.

Where we stand

We do not have single sign-on. It is not built, it is not sold, and no plan here withholds it from you, because there is nothing to withhold. When it exists it will carry real support and compliance weight, and it will be priced as the feature it is rather than used as the fence around a tier.

We are saying that now, before we build it, precisely because it is easy to say afterwards and worth nothing then. Our reasoning about where charging is honest is on the manifesto, and the controls that do exist today are listed with the evidence for each on the security page.

Common questions

What is the SSO tax?

It is the industry practice of placing single sign-on behind the most expensive plan, so that a company adopting a basic security control has to buy an entire tier of unrelated features to get it. The term became common enough that a public list exists naming vendors who do it. The economic argument against it is simple: SSO reduces credential risk for the vendor as well as the customer, so pricing it as a luxury charges the buyer for something that protects both parties.

Does single sign-on genuinely cost a vendor more to support?

Some, yes, and honest vendors say so. SAML configurations differ by identity provider, misconfigurations generate support load, and enterprise identity work carries real compliance weight. That justifies a price. It does not justify a price that is ten times the base plan, which is what happens when SSO is used as the fence around a tier rather than sold as the feature it is.

What should a small company do if it cannot afford the SSO tier?

Enforce what you can at the identity layer you already pay for: strong unique passwords in a shared manager, mandatory two-factor on every application that supports it, and a written offboarding checklist that names every system a leaver must be removed from. That checklist is the control SSO would otherwise automate, and running it manually is far better than not running it.

That was the argument. The free core is where you check it.