Single Sign-On for a Small Team Is Mostly Theater

Single sign-on is the purchase that makes a small company feel like a real company. One login, a dashboard of apps, a checkbox beside every tool in the stack. It is also, at nine people, frequently a subscription that adds a failure mode and removes nothing.

The case for SSO is usually made badly. It gets sold on convenience — one password instead of fourteen — which is the least valuable thing it does and the thing a password manager already solved for a fraction of the effort.

What you are actually buying

The product is not login. It is deprovisioning: one action that removes a person from every connected application at once, plus a record of who had access to what and when.

That is a real security control, and it is worth paying for under the right conditions. The question is whether your company has the problem it solves. The problem is access that outlives employment: a shared password in a document, an admin account nobody remembers creating, a contractor's login to the analytics tool that was set up in a hurry in March and never revisited.

SSO is a control for stale access, not for weak passwords. If nobody has ever left, you are buying a lock for a door that has not been installed.

The three questions that decide it

Answer these before you look at a pricing page.

How many people leave in a year, including contractors and freelancers? This is the only number that matters for the labor side of the calculation, and most small companies guess high.

How many applications hold something that would hurt if a former employee still had it? Customer data, money movement, production infrastructure, the domain registrar. Not the design tool, not the newsletter list.

Does anyone outside the core team need access on a temporary basis? Agencies, bookkeepers, fractional staff, and contractors all churn faster than employees, and churn is what SSO is for.

If the answers are fewer than three departures, under ten sensitive apps, and no outside access, you are buying a control for a risk you do not carry.

The arithmetic, done honestly

Suppose a nine-person studio has fourteen applications worth protecting, and two people leave in a year.

Manual offboarding takes roughly six minutes per app: find the admin panel, search the user, remove them, check the billing seat. That is 84 minutes per departure, call it 1.5 hours. At an illustrative loaded cost of 60 units per hour, each departure costs 90 units of admin time. Two departures, 180 units a year.

An identity provider at an illustrative 6 units per seat per month is 54 units a month, or 648 a year. Several apps charge more for SAML — typically an enterprise tier that can double or triple that app's plan — so add an illustrative 100 units for the two apps that gate it. Total around 750 units.

SSO costs roughly four times the manual process it replaces at this size. That is not an argument against SSO. It is an argument that the justification has to be the failure case, not the labor saved.

The failure case is one missed app. If the missed app is the bank or the production database, the cost is not 90 units. If it is the newsletter tool, it is an afternoon of mild embarrassment. Between those two lies the entire decision, and it is a judgment about blast radius, not about headcount.

The alternatives, and what each one controls

SSO is one of four ways to answer "who can reach this." They are not interchangeable, and most small teams need one of the other three.

The password manager column is the important one. It delivers most of the deprovisioning benefit at a fraction of the cost, provided you have a written checklist and you actually run it. The checklist is the control. The tool is only where the checklist lives.

Network-level tools solve a different problem: they replace the VPN and make internal services reachable per person rather than per network. That is genuinely valuable, and it is not SSO. A company can have perfect network identity and still leave an ex-employee with a working Salesforce login.

An access proxy is the pragmatic middle. It puts a login in front of an internal app that has no SSO support, without modifying the app. For a company with three homegrown tools and no compliance deadline, that covers the real exposure for less than an identity provider contract.

The costs the pricing page does not show

Four of them show up after the contract is signed.

The break-glass account. You need at least one identity that is not behind the identity provider, or a misconfiguration locks the company out of its own tools. That account is a permanent exception to your security policy, and it needs to be stored somewhere and tested on a schedule. Most companies create it and never test it.

Correlated outage. When separate passwords fail, one person is locked out of one app. When the identity provider fails, everyone is locked out of everything simultaneously, including the tools you would use to communicate about the outage.

Coverage gaps. Some tools in your stack will not support SAML, or will support it only on a tier you do not want. You keep the password manager anyway. That is the tell: nearly every company that buys SSO also keeps a password manager, which means the SSO purchase did not replace the thing it was supposed to replace.

Provisioning is billed separately. Creating and removing accounts automatically is usually a different feature from authenticating them, and it is often the more expensive one. Authentication without provisioning gets you a single login and still leaves manual account deletion.

When it is genuinely worth buying

Buy it when at least one of these is true, and stop arguing about the rest.

You have contractors or agency partners rotating through client systems, because their access is temporary by design and temporary access is exactly what manual processes handle worst.

You are pursuing a compliance framework or answering security questionnaires from enterprise clients. The questionnaire will ask, and "we use a shared vault" is a losing answer regardless of how well you run it.

More than fifteen applications hold customer data, at which point the manual checklist stops being reliable because nobody can hold fifteen steps in their head.

You have had an incident. If someone left and something was still reachable three weeks later, the argument is over and you should buy the control that makes it structurally impossible.

The rule of thumb

Multiply the number of people who leave in a year by the number of systems they can reach. Below about thirty, with nothing that moves money or customer data, buy a password manager with a shared vault, write the offboarding checklist, and test it once a quarter.

Above thirty, or with a single system that could end the company if it were accessed by the wrong person, buy SSO and budget for the break-glass procedure as part of the project rather than discovering it during the first outage.