What is the difference between federated identity and self-sovereign identity in practice?

Why This Matters for Security Teams

federated identity and self-sovereign identity are often treated as competing models, but in practice they solve different trust problems. Federated identity centralises trust in an identity provider or broker so services can accept a shared assertion. Self-sovereign identity shifts more control toward the holder of the credential, which can improve portability and consent handling, but it also changes how verification, recovery, and revocation work. For security teams, the key question is not ideology. It is where trust is anchored, who can assert identity, and how quickly that trust can be withdrawn when risk changes.

This distinction matters because identity architecture shapes the blast radius of compromise. When the upstream trust source is weak, every relying service inherits that weakness. That is why NHIMG’s Ultimate Guide to NHIs emphasises lifecycle control and revocation discipline, while the 52 NHI Breaches Analysis shows how identity failures cascade into broader compromise. In practice, many security teams discover the trust gap only after an issuer, broker, or wallet path has already been abused.

How It Works in Practice

Federated identity usually means a central identity provider authenticates the subject and issues a token or assertion that other services trust. That model works well for workforce SSO, partner access, and B2B collaboration because it reduces password sprawl and gives administrators a clear place to enforce MFA, session policy, and deprovisioning. A relying party accepts the federation relationship because it trusts the issuer, not because it knows the subject directly. The practical strength is operational simplicity. The practical weakness is dependency on the federation hub and the assumptions embedded in that trust chain.

Self-sovereign identity, by contrast, is built around the idea that the holder controls credentials, often through a wallet or other presentation layer, and selectively discloses claims to verifiers. Current guidance suggests treating SSI as a consent and portability model, not as a way to eliminate trust. A verifier still has to trust the issuer of the credential, the revocation mechanism, and the presentation method. In other words, SSI moves control closer to the holder, but it does not remove the need for governance.

• Federation is usually better when the organisation needs central policy, easier offboarding, and auditable enterprise control.
• SSI is usually better when users need selective disclosure, portability across domains, or stronger user-held credential control.
• Both models still require issuer trust, revocation checks, and clear recovery processes.

For baseline control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the most practical reference for access governance, while identity-specific lifecycle and visibility gaps are covered in NHIMG’s Top 10 NHI Issues. These controls tend to break down when identity is federated across many external tenants and revocation timing is not synchronised with downstream session caches.

Common Variations and Edge Cases

Tighter identity control often increases onboarding, recovery, and interoperability overhead, requiring organisations to balance convenience against assurance. That tradeoff is especially visible when federated identity is extended beyond employees into contractors, customers, or machine identities. Best practice is evolving, but there is no universal standard for SSI assurance levels, wallet recovery, or cross-domain trust frameworks yet. As a result, many deployments use a hybrid model rather than a pure one.

Common edge cases include delegated administration, multi-tenant SaaS, and cross-border data sharing. A federated model may still be preferable when legal or operational accountability must remain with the enterprise issuer. SSI may fit better when the holder needs to carry credentials across services without repeated re-enrolment, but the organisation still has to decide what happens if a wallet is lost, a credential is compromised, or an issuer is no longer trusted. In practice, the hardest part is not presentation. It is revocation, assurance, and exception handling across multiple trust domains.

For identity risk patterns that show how trust assumptions fail under pressure, the Ultimate Guide to NHIs and Cisco DevHub NHI breach are useful references. In mixed environments, the guidance breaks down when organisations try to apply a single trust model to both high-assurance enterprise workflows and low-friction consumer-style credential presentation.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between identity governance and identity execution in enterprise environments?
• What is the difference between proofed identity and simple remote onboarding for contractors?
• What is the difference between identity management for business users and authentication for application developers?