Single sign-on gets bought on a security line item and deployed as a convenience project. Both of those are defensible. The problem is that the security value and the convenience value arrive at different times, and most organisations stop after the convenience has arrived.
What it genuinely buys you
Three things, and they are worth the money on their own.
One place to disable someone
This is the real prize and it is worth more than the other two combined. A leaver becomes one action instead of forty, and the forty were never going to happen on the same afternoon. They were going to happen across three weeks, with two forgotten entirely, and you were going to find out about those two during an audit.
One place to decide how they prove it
MFA, device requirements and session length become a decision you make once, in one console, rather than a setting you hunt for in every product's admin area and then fail to keep consistent.
One log instead of forty
Most of the value of an audit trail is that somebody can actually read it. Forty separate authentication logs in forty different formats is not an audit trail, it is a research project you will start after the incident.
What it does not do
SSO does not remove the local password underneath it. Connecting an application to your identity provider does not, by itself, disable that application's own login form. Both continue to work. One of them is protected by everything you just configured, and the other is protected by whatever password somebody chose in 2021.
It does not stop a stolen session. If an attacker has a valid session token, the sign-in has already happened and your sign-in policy is not consulted again.
And it does not cover the tool somebody bought on a company card, which is usually the one holding customer data.
The three steps, and the one people stop before
- Connect the application to the identity provider.
- Migrate the users onto it.
- Disable local authentication.
Step one proves it works. Step two makes people happy. Step three is the one that converts a convenience control into a security control, and it is the one that gets deferred, because it is the only step that can break someone's morning.
It is also the step that nobody schedules, because after step two the project looks finished from the outside. The ticket is closed. The rollout email has gone out. The only person who knows step three is outstanding is the person who did steps one and two, and they have moved on to the next application.
What to do about it
Keep a list of applications with three columns: connected, migrated, local auth disabled. Not a maturity model, a spreadsheet. The third column is the only one that matters and it is the one that will be mostly empty.
Then work down it. Each row is usually twenty minutes and one uncomfortable conversation with whoever owns that application.
Sources
Product behaviour changes. Everything above was checked against vendor documentation when it was written, and you should re-check before you build anything on it.