Organisations get started with Decentralised Identifier (DID) by deciding which use case needs portable, user-controlled identifiers and which trust framework will support them. They should assess issuer, holder, and verifier roles, key management, recovery, and revocation, then pilot with limited partners before expanding to production identity workflows.
What organisations should decide before piloting a DID
The first practical step is to treat DID as an identity architecture choice, not a technology experiment. Organisations need a specific use case, a trust model, and a clear answer to who issues identifiers, who holds them, and who verifies them. For most teams, the biggest early mistake is starting with tooling before agreeing on governance, recovery, and revocation rules.
A useful starting filter is whether DID actually improves the workflow compared with conventional identifiers. If the answer is only “it is more modern,” the pilot will usually stall. If the use case needs portability, cross-organisation verification, reduced dependence on a central registrar, or selective disclosure, DID becomes easier to justify. The Verifiable Credentials Guide is the natural companion for understanding how DIDs fit into a broader verifiable credential flow.
Deciding the trust framework matters as much as choosing the identifier method. A DID pilot needs rules for onboarding partners, agreeing which DID methods are acceptable, and defining what level of assurance the verifier will accept. The strongest pilots usually begin with one bounded relationship and one credential type rather than trying to redesign an entire identity estate at once.
How issuer, holder, and verifier roles shape the rollout
DID succeeds or fails based on role clarity. The issuer creates trust in the credential, the holder controls presentation, and the verifier decides whether the assertion is sufficient for access or business action. If those roles blur, the design quickly turns into a brittle custom integration that is hard to support or audit.
Organisations should map these roles to the existing business process before they build. That means identifying which party is authoritative for identity proofing, which party stores the wallet or agent, and which party is allowed to rely on the presentation. A DID rollout that cannot explain those three positions usually has an unresolved governance problem, even if the cryptography works.
Most implementation friction appears at the trust boundary, not in the identifier itself. Verifiers need a reliable way to decide whether the issuer is trusted, whether the credential is current, and whether the presentation is bound to the expected holder. For teams that are new to this model, Digital Identity, eID and Identity Wallets Guide helps place DID in the larger wallet and trust-framework landscape.
Recovery and revocation are part of the role design, not an afterthought. If a holder loses access, a device is replaced, or a credential must be withdrawn, the organisation needs a documented path that preserves trust without manual exceptions becoming the norm. That is especially important when the DID is being used for recurring business transactions rather than a one-time proof.
What a safe first pilot looks like
A good pilot is narrow, measurable, and reversible. It should involve limited partners, a single workflow, and a small set of credentials or identifiers that can be validated without disrupting production identity systems. The objective is to prove trust exchange, operational ownership, and recovery handling before widening the scope.
Organisations should test the full lifecycle in the pilot, not just issuance. That includes onboarding, key rotation, wallet or agent replacement, lost-device recovery, revocation, and the verifier’s decision when a presentation fails freshness or trust checks. If those edge cases are not exercised early, the first real outage becomes the pilot’s true design review.
Technical integration should also stay small enough to observe. Start with one or two verifiers that can enforce a consistent policy, then expand only after the organisation knows how exceptions will be handled. The practical question is not whether DID can work in principle, but whether the business can operate it repeatably with clear support ownership.
Risk and Threat Considerations
DID introduces trust and lifecycle risk if organisations treat it as self-validating. Compromised keys, weak recovery procedures, revocation gaps, or overbroad verifier trust can turn a portable identifier into a durable access path that is hard to unwind.
Failure mechanism: A holder, issuer, or verifier accepts stale, misbound, or unrecoverable identity state, allowing false assertions or prolonged access after trust should have ended.
Impact: The organisation can lose control over who can present identity, who can rely on it, and how quickly compromised or obsolete credentials are contained.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | DID rollout depends on identity assurance, authenticators, and verifier trust decisions. |
| Recommendation — Apply digital identity assurance and authenticator guidance to the issuer, holder, and verifier model. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DID pilots must handle key and credential lifecycle, including rotation and revocation. |
| IA-9 — Service Identification and Authentication | DID deployments often authenticate systems and services in addition to people. | |
| AC-2 — Account Management | DID programs still need governance over identity creation, suspension, and removal. | |
| Recommendation — Manage credential and key lifecycle so DID trust can be revoked or refreshed safely. Use mutual authentication controls where DID-backed systems or services exchange trust signals. Tie DID lifecycle events to account and entitlement governance so stale access is removed promptly. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | DID is an identity management approach that needs governance over identifier lifecycle and use. |
| Recommendation — Define identity lifecycle ownership, approval, and revocation rules for DID issuance and recovery. | ||
Practitioner Guidance
What to prioritise: Define the trust framework and recovery model before selecting wallets, DID methods, or partner integrations. If those decisions are deferred, the pilot will produce technical activity without an operationally trustworthy identity model.
What to verify: Confirm who can issue, who can hold, who can verify, and what happens when a credential must be revoked or a holder loses access. The pilot is only useful if those decisions are explicit enough to survive partner onboarding and exception handling.
Practitioner takeaway: The best DID starts are narrow trust pilots with disciplined lifecycle rules, not broad identity transformations. If the organisation cannot explain recovery, revocation, and verifier trust in plain terms, it is not ready to scale.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org