What is the difference between self-sovereign identity and traditional centrally managed identity?

Self-sovereign identity shifts control of identity attributes toward the user, who decides what to share and when. Traditional centrally managed identity usually places that control with the organisation, which stores and validates the data. The practical difference is whether the enterprise holds the identity records or verifies claims with less direct data exposure.

Why This Matters for Security Teams

Self-sovereign identity changes who controls claims, but it does not remove the need for governance, assurance, or revocation. For security teams, the practical question is not whether identity data is decentralised, but whether trust decisions remain auditable when claims are presented outside a central directory. That matters because identity is now tied to access, fraud prevention, privacy, and incident response.

Traditional centrally managed identity gives the organisation a single point for onboarding, policy enforcement, and recovery. Self-sovereign identity can reduce data exposure and improve user control, but it also introduces new verification and interoperability challenges. Current guidance suggests treating it as a trust model shift, not a replacement for IAM fundamentals. The NIST Cybersecurity Framework 2.0 still applies: know what identities exist, protect the assertions behind them, and detect misuse quickly.

For NHI programs, the lesson is even sharper. Identity systems often fail because credentials, claims, and lifecycle controls drift apart. NHIMG research shows that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which is a reminder that control only works when the identity source and the enforcement point stay aligned. In practice, many security teams encounter identity trust failures only after access has already been abused, rather than through intentional review.

How It Works in Practice

Traditional identity systems centralise authentication, attribute storage, and policy enforcement. A directory, identity provider, or IAM platform usually issues or validates identities, then applications trust that central authority. Self-sovereign identity reverses part of that flow: the subject holds verifiable claims, often in a wallet or similar container, and presents only the minimum information needed to prove a statement.

In practical deployments, that means security teams must separate three functions:

• issuance of claims, which still requires a trusted authority

• presentation of claims, which may be user-controlled and selective

• verification of claims, which must be cryptographically and operationally reliable

The architecture may reduce the amount of personal data stored by the enterprise, but it does not eliminate identity governance. Teams still need policy for proofing, revocation, dispute handling, and assurance levels. That is why decentralised models are usually paired with standards-based trust fabrics and strong verification logic rather than ad hoc application checks. For reference, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows how lifecycle discipline remains essential even when credentials are not centrally stored.

For enterprises, the best comparison is this: centrally managed identity optimises for administrative control, while self-sovereign identity optimises for selective disclosure and user-held claims. Both still depend on reliable trust anchors, revocation mechanisms, and policy enforcement. That is why security architects should evaluate them through assurance, not ideology. The transition becomes fragile when applications require real-time cross-domain verification and the issuer ecosystem cannot guarantee revocation freshness or consistent claim semantics.

These controls tend to break down in federated environments with inconsistent issuers and weak revocation checks because the relying party cannot confidently tell whether a presented claim is still valid.

Common Variations and Edge Cases

Tighter privacy controls often increase verification complexity, requiring organisations to balance user data minimisation against auditability and fraud resistance. That tradeoff is not always obvious, and there is no universal standard for this yet. Best practice is evolving, especially where wallets, verifiable credentials, and federated trust frameworks intersect.

One common edge case is when an organisation uses self-sovereign identity for customer onboarding but still relies on centrally managed identity for workforce access. That split is normal. Another is when a centrally managed provider issues verifiable credentials, which can look decentralised at the presentation layer while remaining centralised at issuance. In those cases, the real question is who can revoke, who can attest, and who bears liability when a claim is false.

Security teams should also watch for implementations that treat self-sovereign identity as a password replacement only. It is not. Recovery, account binding, and proofing still matter, and low-assurance identity recovery can undermine the entire model. For operational context, NHIMG notes in the Top 10 NHI Issues that overprivilege and lifecycle gaps are recurring failure modes in identity programs, whether the identity is human or non-human. The same principle applies here: decentralisation changes custody, not accountability. In environments with strict legal hold, high churn, or centralised fraud review, central IAM often remains the more defensible control plane.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between federated identity and self-sovereign identity in practice?
• What is the difference between private, public, and permissioned blockchains for identity use cases?
• What is the difference between centralised identity management and decentralised identity management for data sharing?