What Is Single Sign-On (SSO) and How Does It Work?

What Is Single Sign-On (SSO) and How Does It Work?

Single sign-on (SSO) is an authentication method that lets a user log in once and gain access to multiple applications without having to sign in separately to each one. Instead of managing a different username and password for every tool, the user authenticates with a central identity provider, which then vouches for them across connected apps.

It matters because every separate password is a separate point of failure. Reducing the number of credentials a person manages  and the number of places those credentials are entered  directly reduces the opportunities an attacker has to steal one.

Why Does SSO Make Such a Measurable Difference?

The scale of the password problem is larger than most people expect. The average employee juggles over 80 different application passwords, each representing a potential security vulnerability, and password-related support costs and lost productivity are estimated to cost organisations around $5.2 million annually.

The security impact of consolidating that down to one is significant. While 94% of data breaches involve compromised credentials, implementing SSO can reduce security incidents by up to 50%, while also cutting help desk costs by 30-50%.

The reasoning is straightforward. Every additional password a person manages is a password they might reuse, write down, or enter into a phishing page that mimics a familiar login screen. SSO removes most of those entry points by routing authentication through a single, centrally managed provider  one that can be monitored, secured, and updated in one place rather than across dozens of separate app logins.

There's a trade-off worth naming honestly. A single point of failure is one of the recognised risks of SSO, which is why additional tools like MFA are needed for robust security. SSO isn't a replacement for MFA or conditional access;  it's the layer that makes both easier to apply consistently, because there's only one sign-in point to protect rather than dozens.

Where Does SSO Fit Into a Broader Identity Strategy?

SSO is most effective when it's treated as the front door to an identity and access management strategy, not the whole strategy. SSO solutions strengthen security by reducing the number of passwords users need to manage while enforcing multi-factor authentication, and many industries have regulatory requirements around data protection and authentication that SSO helps organisations meet.

For organisations governed by frameworks like HIPAA, GDPR, or PCI DSS, the centralisation SSO provides has a direct compliance benefit. A centralized, comprehensive audit trail over systems and data access is made possible by SSO, enabling IT and security teams to monitor user access regardless of where employees are working from. Instead of pulling access logs from dozens of individual applications during an audit, a single sign-in event tells the full story.

This is also where SSO connects directly to conditional access. Once authentication runs through a single identity provider, conditional access policies can apply consistently to every connected application — device checks, location restrictions, and session controls all take effect at the SSO layer rather than needing to be configured separately, app by app. Centralising authentication through SSO is a foundational step — but it only delivers its full security benefit when it's configured correctly and paired with the right conditional access and MFA policies. Our SaaS Security for Microsoft 365 and Google Workspace course covers exactly how these pieces fit together in real tenants.

How Should Organisations Configure SSO Securely?

Choosing the right identity provider is the first decision, and it shapes everything that follows. Whether using an internal identity provider like Active Directory or integrating with a third-party provider, the SSO solution should support open standards like SAML or OIDC to ensure compatibility across platforms. Picking a provider that supports these standards avoids being locked into proprietary integrations that become difficult to maintain or replace later.

Before rolling out SSO, the application landscape needs to be mapped properly. This means auditing application access needs — mapping out which applications users need to access and grouping them by role, department, or use case. This step often surfaces "shadow IT"  applications that teams have been using independently, outside any central oversight, which need to be brought into the SSO setup or flagged for review.

Cleaning up identity data before connecting applications matters more than it sounds. Verifying that all user accounts in your directory are up to date prevents a common problem: SSO rollouts that quietly carry forward stale accounts, duplicate identities, or former employees who were never fully offboarded, now with centralised access to everything connected.

Pairing SSO with MFA from day one — rather than as a follow-up project — closes the single-point-of-failure risk directly. Since SSO concentrates authentication into one event, that event needs to be protected with more than a password. This is also the point where conditional access policies should be layered in, so that the single sign-in event is evaluated for device compliance, location, and risk before access is granted across every connected app.

Finally, the audit trail SSO creates is only useful if someone reviews it. A centralized audit trail allows IT and security teams to monitor user access regardless of where employees are working from  but this requires a defined process for who reviews sign-in activity, how often, and what triggers a closer look at an unusual pattern.

Frequently Asked Questions

Is SSO the same as using a password manager?

No, though they solve a related problem differently. A password manager stores and autofills separate passwords for each application; the user still has individual credentials for every service, just managed in one place. SSO removes the separate credentials entirely; users authenticate once with a central identity provider, which then grants access to connected applications without a second password.

Password managers are often used for applications that aren't connected to SSO — older tools, smaller vendors, or services that don't support SAML or OIDC. In a well-configured environment, SSO handles the majority of an organisation's core applications, while a password manager covers the smaller set that can't yet be integrated.

What happens if the SSO identity provider goes down?

This is the practical version of the "single point of failure" concern. If the central identity provider is unavailable, users may be unable to sign in to any connected application until it's restored — which is why identity providers used for enterprise SSO need to meet a high standard for uptime and resilience.

Most organisations mitigate this with break-glass accounts, emergency accounts with direct access that bypass SSO, used only when the identity provider itself is unavailable. These accounts need their own strict controls, since they sit outside the normal authentication flow by design, and should be included in the same access reviews as every other privileged account.

Centralising authentication through SSO is one of the highest-leverage changes an organisation can make to its identity setup — but only if it's configured with MFA and conditional access from the start, not added afterwards. Our SaaS Security for Microsoft 365 and Google Workspace course walks through SSO configuration alongside both, using real Microsoft 365 and Google Workspace tenants.