Single sign-on for small companies: is it worth it yet?

Single sign-on gets pitched to small companies on convenience, which is the weakest argument available for it. Nobody has ever approved a budget line because signing in was mildly annoying. The argument that works is narrower and much harder to dismiss, and it only becomes obvious the first time somebody leaves badly.

This note is about whether a company under about fifty staff should bother, what it would actually be buying, and what to do instead when the answer is not yet.

What SSO is, in the vendor’s own words

Microsoft’s documentation for Entra ID describes the mechanism plainly: with SSO, users sign in with one set of credentials and can then open every assigned application without signing in again, with the identity provider verifying the user and confirming their identity to each application, so the applications no longer manage their own usernames and passwords.

That last clause is the whole product. The applications stop holding credentials. Everything worth having follows from it.

The three ways it gets implemented, which are not equivalent

The same documentation separates the options, and the distinction matters when a vendor tells you their product supports SSO.

• Federation. The real thing. Either SAML 2.0, described as the mature XML-based standard with the broadest enterprise compatibility, or OpenID Connect, built on OAuth 2.0 with JSON tokens and generally simpler to implement against modern frameworks.
• Password-based SSO. The identity provider stores the credentials and replays them to the application. It is a workaround for applications that do not support federation, and it means the credentials still exist.
• Linked SSO. Microsoft is explicit that this adds application links to a user portal but does not provide true single sign-on. It is a migration convenience, not a security control.

When a SaaS vendor says they support SSO, ask which of those three, and whether it is gated behind an enterprise tier. Both answers change the economics.

The argument that actually justifies it

Offboarding. In a company without SSO, removing someone’s access means remembering every application they had an account in and disabling each one, in a business where nobody has ever written that list down completely. The failure is not usually malice. It is a forgotten account in a tool one team adopted two years ago, still active, still receiving data.

With federation, disabling the identity closes the door on every application that trusts it, in one action. That is the purchase. Convenience, fewer password resets reaching whoever handles support, and consistent policy across applications are all real and all secondary.

The corollary is that SSO only closes the doors it is actually in front of. Every application still on its own login is still on your offboarding list, so the value scales with coverage, not with having bought something.

When the headcount does not justify it

Below roughly fifteen people, with a handful of applications and low turnover, SSO is usually not the highest-value thing you could do with the same money and attention. The list of applications is short enough to be genuinely complete, and the offboarding risk it removes is small.

What changes the answer is not headcount on its own. It is the number of applications holding company data, and how often people join and leave. A twelve-person company with thirty SaaS tools and contractor turnover has the problem. A forty-person company with six tools and stable staff mostly does not.

The cheaper middle ground

If the answer is not yet, the interim position is not nothing. It is a written inventory of every application holding company data and who has access, a shared password manager so credentials are at least centrally revocable, multi-factor authentication on the accounts that matter most, and an offboarding checklist that is maintained rather than remembered.

That combination removes most of the practical risk at a fraction of the cost and effort, and it has a useful side effect: building the inventory tells you whether you have the SSO problem. If the list is long and nobody could have produced it from memory, you have your answer.

What it costs to get wrong

Two failure modes are worth naming. Buying SSO and connecting three of twenty applications produces the cost with little of the benefit and, worse, a belief that offboarding is handled. And routing everything through one identity provider concentrates risk, so the recovery path for losing access to that provider needs to exist on paper before you need it.

Neither is an argument against SSO. Both are arguments for treating it as a project with a coverage target rather than a purchase.

A straight recommendation

Write the application inventory first, this week, because you need it either way and it is free. If it runs past fifteen or twenty applications, or if people join and leave regularly, move to federated SSO and set a coverage target rather than connecting whatever is easiest. If it does not, take the password manager and the offboarding checklist, and revisit when either number moves.

The general pattern here is one that shows up across internal tooling: the tool is not the decision, the process it enforces is. That is the same reasoning as automating manual reporting without buying a BI platform and as knowing when a spreadsheet has stopped paying for itself. And whichever way this one goes, keeping the change small and reversible is the discipline in scoping before anyone writes code.