What is the difference between single sign-on and federated identity management?

Single sign-on is the user experience of signing in once and reaching multiple resources without repeated logins. Federated identity management is the broader trust framework that lets different organizations or domains share identity, authentication, and authorization information securely. SSO can be one outcome of federation, but federation also covers the inter-organizational trust relationships behind it.

Identity at the user session level versus identity between organisations

Single sign-on describes the login experience and session reuse. It reduces repeated prompts by allowing one successful authentication to access multiple connected services. The control problem is mostly about how the user session is created, accepted, and reused safely across applications, not how separate organisations decide to trust one another.

federated identity management is the broader trust arrangement behind that experience. It defines how one identity provider, organisation, or domain asserts identity to another party, how assertions are accepted, and which authentication and authorization signals can cross a trust boundary. In practice, federation is the architecture; SSO is one possible outcome.

When practitioners compare the two, the easiest test is scope. If the question is “how does the user avoid logging in repeatedly?”, you are talking about SSO. If the question is “how do two domains exchange trusted identity information securely?”, you are talking about federation. The distinction matters because federation can support SSO, but it can also support other cross-domain access patterns that do not feel like classic SSO.

Where the technical differences show up in practice

SSO usually lives inside a single trust environment or a tightly controlled set of connected applications. The main operational concern is session handling, token acceptance, and reducing password fatigue without weakening authentication strength or increasing blast radius if the session is compromised.

Federation introduces additional design choices. Teams must agree on trust anchors, token or assertion formats, claim mapping, and the conditions under which one party will accept another party’s identity assertion. Those choices affect interoperability, revocation behaviour, account linking, and what happens when the external identity source is unavailable or misconfigured.

A useful way to think about it is that SSO answers “how many times does the user sign in?”, while federation answers “who is allowed to vouch for the user, and under what rules?”. That is why a system can have SSO without broad federation, and federation without a polished SSO experience.

SSO is outcome-focused: one login, multiple resources.
Federation is trust-focused: shared identity and authentication between domains.
SSO may use federation protocols, but it does not require cross-organisational trust in every deployment.

Risk and Threat Considerations

The main risk is conflating convenience with trust. SSO centralizes access, so a session or primary authenticator compromise can cascade across many applications. Federation expands the trust boundary, so errors in assertion handling, claim mapping, or partner trust can expose data or permit access across organisations.

Failure mechanism: A weakly protected SSO session, stolen token, or overtrusted federated assertion can be replayed or accepted too broadly, especially when applications rely on implicit trust instead of validating audience, issuer, expiry, and revocation conditions.

Impact: One compromise can become broad unauthorized access, cross-domain account takeover, or unintended third-party data exposure, with recovery complicated by distributed ownership and different revocation controls across the trust chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Federation and Assertions — Federation and Assertions	Federation relies on trusted identity assertions across domains.
Recommendation — Validate assertion issuer, audience, and expiration before granting access.
NIST Zero Trust (SP 800-207)	Explicit Verification — Explicit Verification	Both SSO and federation depend on verifying each request, not just the initial login.
Recommendation — Revalidate trust and context at each access decision.
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	The question concerns access control and authenticated access across services and domains.
Recommendation — Define authentication and access rules that limit reuse of identity trust.
CIS Controls v8	6.3 — Account Access Control Management	SSO and federation both change how accounts are accessed and governed.
Recommendation — Restrict and review account access paths that rely on shared identity trust.

Practitioner Guidance

What to verify: Confirm whether the architecture is only authenticating users once, or whether it is also exchanging trusted identity assertions across domains. That distinction determines whether your review should focus mainly on session controls or on partner trust, claim validation, and external identity governance.

Common mistake: Treating every SSO deployment as if it were full federation. If the system only reuses an internal session, federation controls such as trust agreement lifecycle, assertion policy, and partner onboarding may be unnecessary; if external identities are involved, those controls become essential.

Practitioner takeaway: SSO is about the user’s login journey, but federation is about the security of the trust relationship that makes that journey possible. When you evaluate risk, always ask whether you are protecting a session, a trust boundary, or both.