What Is Single Sign-On?

Single sign-on lets a user authenticate once and reach many applications without signing in again. It is usually adopted for convenience and its security value is larger than the convenience argument suggests.

Without it, every application holds its own credentials. That means passwords reused across systems, no central view of who has access to what, and a departing employee whose access must be removed application by application — which is how forgotten accounts persist for years.

What centralising authentication buys

One place to enforce strong authentication, so improving the factor improves every connected application at once. One place to apply conditional access based on device and risk. One place to disable an account and end access everywhere. And one authentication log rather than a dozen.

That last point is underrated. Investigating suspicious access across fifteen applications with separate logs is materially harder than querying one.

The concentration risk is real and manageable

Centralising authentication concentrates consequence. Compromise of the identity provider is compromise of everything behind it, and an outage there is an outage of everything.

The response is to treat it as the most critical system you operate: the strongest available authentication for its administrators, tight restriction of who holds those roles, thorough logging of configuration changes, and a tested understanding of what happens during an outage.

Federation trust configuration deserves specific care. An attacker who can add a trusted identity provider or forge assertions can authenticate as anyone, and these changes are rarely monitored with the attention they warrant.

Applications that cannot federate

Every estate contains applications that do not support modern authentication — older clinical systems, industrial software, internal tools written years ago. They hold their own credentials and sit outside every control the identity provider applies.

Options, roughly in order of preference: an application proxy that authenticates at the edge and passes the legacy credential onward; a password manager with shared vaults so credentials are at least not written down; or accepting the gap with compensating controls and a documented risk.

What matters is that these are enumerated rather than forgotten. An unfederated application is an offboarding gap, and an unfederated application nobody has listed is one that will still be granting access to a departed employee in two years.

Logging is where the value compounds

Centralised authentication produces one authoritative record of who signed in, from where, to what and when. That record answers questions during an investigation that would otherwise require correlating a dozen application logs with inconsistent formats and different retention.

It is worth ensuring those logs actually reach your monitoring rather than remaining in the identity provider’s own console, and that retention is long enough to cover realistic dwell times. Thirty days is shorter than most intrusions.

The thing most worth getting right

Where to start

Count the applications in use that do not authenticate through your identity provider. Each holds its own credentials and its own orphaned accounts, and that list is the scope of your real offboarding problem.

See SSO and session management. GuardsArm runs security program reviews.