What is SSO?
Privacy, security and identity
SSO means Single Sign-On. It is an authentication pattern in which a trusted identity provider authenticates a user once and then lets that user access multiple connected applications without signing in to each one separately. In practical terms, SSO centralises sign-in, reduces password sprawl and can make access easier to manage across cloud services. But SSO is about authentication, not the full question of authorisation. It helps prove who the user is. It does not automatically decide what that user is allowed to see, change or export inside every system. That still depends on broader IAM and access control design.
What this means
A normal non-SSO setup forces users to keep separate credentials for different applications. SSO changes that. Users authenticate with a central identity provider, and connected services trust that authentication event. In federated models, this is commonly done through protocols such as OpenID Connect or SAML.
The benefit is obvious: fewer passwords, less account recovery friction, and more consistent sign-in policy. But the practical value is not just convenience. Centralisation means the organisation can apply stronger authentication methods, see sign-in activity in one place, and connect sign-in to joiners, movers and leavers more cleanly.
Still, SSO is often overpraised. It does not, by itself, give you good permissions. A user can sign in perfectly through SSO and still have the wrong access inside the application. That is why SSO belongs inside a wider IAM model. It can centralise authentication, but authorisation, role design, review and revocation still need separate attention.
Why it matters
SSO matters because authentication quality is uneven when every application handles it differently. One system may have poor password rules, another may lack MFA, a third may be forgotten during offboarding. Central sign-in helps reduce that inconsistency. NCSC guidance is clear that using SSO can simplify account and credential management, support modern authentication practices and tie access changes into the joiners, movers and leavers process.
This becomes more important as organisations depend on multiple SaaS tools and AI-enabled services. Staff may move between file platforms, ticketing systems, admin portals, analytics tools and knowledge assistants in the same hour. If sign-in policy is fragmented, the organisation loses visibility and increases the chance of weak links.
At the same time, SSO creates concentration risk. If the identity provider has an outage, or if administrative control of it is compromised, many connected services are affected at once. That is not a reason to avoid SSO, but it is a reason to treat identity infrastructure seriously, protect admin access and plan fallback routes carefully.
SSO also matters for user behaviour. Fewer passwords can reduce reuse, insecure storage and sign-in fatigue. But convenience should not be confused with security by default. Centralisation gives you the chance to do authentication properly. It does not guarantee that you have.
How it works
At a high level, SSO works through trust between an identity provider and one or more connected applications, often called relying parties or service providers. The user signs in with the identity provider. The identity provider then sends an assertion or token to the application to confirm that authentication took place and to convey selected identity information. The application trusts that result and creates a session for the user.
In enterprise settings, SSO often sits alongside account provisioning. That means the application accounts are pre-created or synchronised, and when a user account is changed or terminated at the identity provider, the connected service can be updated too. This is where SSO becomes more than a user-experience feature. It becomes part of operating access at scale.
The important boundary is between authentication and authorisation. Authentication proves identity. Authorisation determines what the authenticated party can do. SSO handles the first part. The second part still depends on application roles, groups, entitlements or policy conditions.
This is why SSO is usually paired with other controls. MFA strengthens the sign-in event. IAM processes make sure accounts exist only while needed. RBAC or ABAC decide permissions within systems. Logging and alerting help detect abnormal access. Emergency or break-glass arrangements provide a route when normal identity dependencies fail.
A useful mental model is that SSO gives you one front door for many rooms, but you still need locks inside the building.
Where it shows up in real workflows
A typical example is a professional services firm using a central identity provider for Microsoft 365, HR software, finance tools and a knowledge assistant over internal documents. A new starter receives one managed identity, signs in once, and reaches the systems attached to their role. When they leave, disabling the central identity prevents ordinary access across connected services rather than relying on each application owner to remember separately.
A second example shows the limitation. A company rolls out SSO for an internal product wiki and then claims the access problem is solved. It is not. Staff can now sign in conveniently, but if the wiki permissions are still over-broad, too many people can still view unpublished strategy notes. SSO improved authentication. It did not fix authorisation.
A third example involves resilience. An organisation uses federated sign-in to a cloud service. One day the normal identity path is unavailable because of an identity provider fault. NCSC and Microsoft guidance both point to the need for break-glass or emergency access arrangements. The lesson is practical: centralised authentication reduces sprawl, but you must plan for the day the centre is not available.
In AI-enabled work, this matters when teams connect assistants to multiple corporate services. SSO may make access easier for the user, but the identity provider, provisioning pipeline and fallback model become more critical because more of the work depends on them.
Common misunderstandings
The most common misunderstanding is that SSO equals security. It does not. SSO can reduce password sprawl and make it easier to apply strong sign-in policy consistently, but if MFA is weak, admin controls are poor or connected applications are misconfigured, SSO can centralise weakness as easily as it centralises strength.
The second misunderstanding is that SSO decides permissions. It does not. Authentication and authorisation are related but distinct. SSO proves identity to connected services. Those services still need rules about what an authenticated user may access.
Another misunderstanding is that SSO is only about user convenience. Usability matters, but so do lifecycle and visibility. SSO becomes valuable because account changes and sign-in policy can be handled more centrally.
Finally, some organisations assume fallback is optional. It is not. If SSO becomes the main route into multiple services, outage planning, emergency access and protected admin recovery processes become part of the design, not a postscript.
Risks and boundaries
SSO introduces concentration risk. A compromise of the identity provider, its administrators or its trust relationships can affect many services quickly. An outage can also stop work across connected applications. NCSC guidance specifically warns organisations to consider provider availability and to plan emergency access, and Microsoft publishes detailed guidance for emergency access accounts in federated and cloud-only scenarios.
There is also a dependency boundary. If your emergency path depends on the same broken systems as your normal path, it is not real resilience. Break-glass access needs clear ownership, monitoring and secure storage, and it should be irritating enough that people do not use it for convenience.
Another boundary is scope. Not every system integrates cleanly with SSO, and not every business use case should rely on one external identity source without thought. Service-to-service authentication, legacy systems and third-party tools may need separate treatment.
The practical message is balanced: SSO is often a sensible default for modern cloud estates, but only when it is paired with strong authentication methods, clear authorisation design, protected administration and tested fallback arrangements.
What leaders should do next
Leaders should ask three simple questions. Which systems already use SSO, which still do not, and what happens if the identity provider is unavailable? Those answers usually reveal whether SSO is being treated as a strategic access layer or just a convenience feature.
Then review the surrounding controls. Check MFA strength, privileged admin protections, provisioning and deprovisioning processes, and emergency access plans. Make sure critical services have a recovery route that does not rely on the same failed dependency chain.
Finally, keep the language straight inside the business. Use SSO to improve authentication consistency, but do not let it stand in for real access governance. Pair it with role design, periodic review and clear ownership of permissions inside each connected system.
FAQs
Is SSO the same as using Google or Microsoft to sign in to lots of apps?
That is one familiar form of federated sign-in, but enterprise SSO is usually broader. It relies on trust between a central identity provider and connected applications so one authentication event can support access across many services. In a business setting, it is typically tied to lifecycle management, logging, MFA and provisioning rather than being just a convenience feature for consumer accounts.
Does SSO remove the need for passwords?
Not necessarily. Some SSO implementations still use passwords at the identity provider, often alongside MFA. Others increasingly use phishing-resistant methods such as passkeys, security keys or certificate-backed approaches. The point is not that SSO abolishes passwords by itself. The point is that SSO centralises authentication so the organisation can apply stronger methods more consistently than if every application handled sign-in separately.
What should we do if our SSO provider goes down?
You need a tested resilience plan before that happens. That usually means tightly controlled emergency access or break-glass arrangements, secure storage of credentials or devices, clear monitoring of any emergency use and a review process after activation. The fallback should avoid circular dependency on the same unavailable systems. If your only recovery route depends on the same broken federation path, it is not a credible backup.
Sources
National Institute of Standards and Technology: Digital Identity Guidelines: Federation and Assertions - Formal SSO definition, federation concepts, enterprise application single sign-on, provisioning APIs and account synchronisation.
National Cyber Security Centre: Authentication methods: choosing the right type - Security and usability trade-offs, federated SSO explanation, OIDC references, and provider security and availability considerations.
National Cyber Security Centre: Using a cloud platform securely - SSO for simplifying account management, applying consistent authentication best practice, and integrating with joiners/movers/leavers.
National Cyber Security Centre: Protecting how you administer cloud services - Emergency access principles, alarms and practical expectations when normal access routes are unavailable.
National Cyber Security Centre: Principle 10: Identity and authentication - Need for authenticated and authorised identities, integration with joiners and leavers, and separation between identity proof and access control.
National Cyber Security Centre: Use policies to authorise requests - Break-glass concept and alerting expectations where normal access policy cannot be satisfied.