What single sign-on actually gets you
By John Marta, Principal & Senior IT Architect at GO Build Labs
Single sign-on usually gets pitched as convenience. One login, one less password to forget. That is true, and it is the least interesting thing about it.
The real reason: the day someone leaves
Think about what actually happens when an employee resigns. Somebody has to remember every system they had access to and disable each one. The payroll system, the CRM, the scheduling tool, the shared drive, the thing the operations team started using last year that IT was never told about.
Most businesses do a decent job of the first three and an unreliable job of the rest. The result is orphaned accounts that stay live for months, belonging to someone who no longer works there and no longer thinks of themselves as bound by anything.
With SSO, disabling the directory account closes every door at once. That is the whole feature. Everything else is a bonus.
The support queue that disappears
Password resets are, for most small businesses, the single highest-volume support request. Every separate login is another chance to forget one, and every reset is an interruption for whoever handles it, plus a few minutes of somebody unable to work.
Collapsing five logins into one does not reduce that by 80%. It reduces it to roughly nothing, because the one remaining password is the one people type every morning and therefore never forget.
MFA you only have to win the argument about once
Getting people to accept multi-factor authentication is a cultural fight. Having that fight once, at the directory, is manageable. Having it separately for six applications is how you end up with MFA on two of them and a policy nobody follows.
The same applies to password rules, session timeouts, and blocking sign-ins from countries you don't operate in. Configure it in one place and every connected application inherits it, including the ones you add next year.
What it costs
Usually nothing you're not already paying. If you run Microsoft 365, you already have the identity provider. Connecting a custom application to it is a small piece of work at build time and essentially free to run.
This is why we build it into every platform we deliver rather than offering it as an upgrade. It costs us a day and removes an entire category of problem from your operation.
When it is not worth it
Two cases, in fairness.
If the application is used by people outside your organization, customers on a portal, contractors, residents registering for a program, they aren't in your directory and SSO does not apply. Those need their own accounts, and the interesting question there is whether they need accounts at all.
And if you have no central directory, no Microsoft 365, no Google Workspace, nothing, then SSO means standing up an identity provider first. Still usually worth it, but it is a bigger conversation than a checkbox at build time.
The question to ask
Next time anyone proposes new business software, ask whether it connects to your existing directory. If the answer is no, that is not automatically disqualifying. But it does mean you have just taken on another set of credentials to manage, another password reset queue, and another account somebody will forget to close.