Join our Newsletter — 33% off our NHI Course

did:key

did:key is a decentralised identifier method that derives a DID directly from a public key, with no separate registry or network lookup. It is simple to deploy, but key compromise is permanent for that identifier, so lifecycle control, key storage, and revocation strategy must be designed carefully.

What did:key Is and Why It Matters

did:key is a decentralised identifier method that turns a public key into a DID without relying on a registry, resolver network, or external issuance workflow. That makes it attractive for simple deployments, but it also means the identifier is tightly bound to the key material that creates it.

Because the DID is derived directly from the key, the security posture of the identifier and the security posture of the key are effectively the same. If the key is exposed, copied, or reused inappropriately, the identifier’s trust boundary is compromised with it.

Key Binding, Trust, and Lifecycle Implications

did:key is best understood as a self-contained identity primitive, not a managed identity system. There is no separate registry state to update, which removes lookup dependency but also removes the usual operational leverage points for rotation, revocation, and recovery. The method works well when the key itself is intended to be the long-term anchor, but that design choice shifts more responsibility into key governance.

In practice, this makes the lifecycle of the underlying key the lifecycle of the DID. If an organisation wants a different trust relationship later, it usually has to create a new identifier rather than “fix” the existing one.

Exposure Checks and Deployment Fit

Teams evaluating did:key should first ask where the identifier will be used, how often the key must change, and whether the environment can tolerate an identifier that is hard to alter once published. It is a strong fit for low-friction cryptographic identity and offline or peer-to-peer use cases, but it is a poor fit when operational recovery depends on issuer-side correction or central administration.

The main exposure review is therefore not about a server-side attack surface, but about implementation discipline: where keys live, who can export them, how they are backed up, and whether the surrounding system assumes revocation or re-issuance will be easy. If that assumption is wrong, the deployment can become brittle quickly.

Identity Assurance and Interoperability Considerations

did:key can participate in broader verifiable credential ecosystems, but it does not by itself prove who controls the key, whether the key was generated safely, or whether the subject behind the DID has been vetted by a trusted process. For that reason, relying parties usually need additional policy, trust framework, or credential validation logic beyond the DID method itself.

Its simplicity is part of the appeal, yet that same simplicity means interoperability decisions matter. Organisations should be clear about whether they need a portable cryptographic identifier, a recoverable operational identity, or a governed trust anchor, because did:key only solves one of those problems directly.

Risk and Threat Considerations

did:key concentrates risk into a single secret or key pair, so compromise is often final for that identifier. The absence of a registry or revocation path reduces operational complexity, but it also limits containment options after theft, reuse, or accidental disclosure.

Failure mechanism: If the private key is copied, leaked, or reused across contexts, an attacker can impersonate the DID holder without needing to attack a directory or registration service.

Impact: Trust in the identifier can be permanently lost, and any credentials, sessions, or relationships anchored to that DID may need to be abandoned and re-established under a new identifier.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-57 Key Management did:key security depends on key generation, storage, rotation, and destruction.
Recommendation — Define cryptoperiods, protect private keys, and retire identifiers when key compromise or reuse is suspected.
OWASP Non-Human Identity Top 10 NHI-07 — Long-Lived Secrets did:key binds identity to enduring key material that can become hard to replace.
NHI-02 — Secret Leakage A leaked private key directly undermines the identifier derived from it.
Recommendation — Avoid relying on long-lived keys where recovery or rotation must remain feasible. Store DID private keys in hardened secret management and monitor for exposure.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management The private key functions as the authenticator whose lifecycle must be managed.
IA-9 — Service Identification and Authentication did:key is a cryptographic identifier used for machine or service trust relationships.
Recommendation — Enforce secure storage, rotation, and revocation procedures for the authenticator material. Use cryptographic trust bindings and verify the key material that represents the service identity.

Practitioner Guidance

Why practitioners should care: did:key is operationally simple, but that simplicity only holds if the organisation treats key generation, storage, and destruction as first-class controls. If those controls are weak, the identifier becomes fragile rather than lightweight.

What to watch for: Treat shared keys, uncontrolled exports, and long-lived reuse across environments as red flags. A did:key deployment should be designed so that compromise recovery is understood before the identifier is ever published.