What should IAM teams do with decentralized identity and verifiable credentials?

Why This Matters for Security Teams

decentralized identity and verifiable credentials are often marketed as a portability upgrade, but IAM teams should treat them as a trust architecture decision. The question is not whether a wallet can present a claim. It is whether issuers are authorized, credential formats are consistent, revocation is dependable, and the relying party can validate the claim without creating a new trust gap. For governance-heavy environments, that matters more than the branding around self-sovereign identity.

This also changes how IAM thinks about assurance. Traditional identity programs assume a relatively stable identity provider and a controlled lifecycle. Verifiable credentials introduce more distributed issuance, which can improve portability but also expands the number of entities that can create, sign, and revoke assertions. Current guidance suggests mapping these flows to the same rigor used for secrets, certificates, and workload identity. The OWASP Non-Human Identity Top 10 is useful here because it frames trust failures as operational risks, not abstract design debates. NHIMG research also shows how brittle identity programs become when governance lags behind capability, including the Ultimate Guide to NHIs. In practice, many security teams discover revocation and issuer trust problems only after a credential has already been accepted in production.

How It Works in Practice

For IAM teams, the practical model is to treat decentralized identity as a set of verifiable trust relationships, not as a replacement for policy. A verifiable credential should answer four questions: who issued it, what exactly it asserts, how long it is valid, and how it can be revoked or suspended. That means governance has to cover issuer onboarding, cryptographic signing policy, wallet or holder controls, and relying party verification logic. The NIST SP 800-63 Digital Identity Guidelines remain relevant because they separate identity proofing, authentication, and federation assurance, which helps teams avoid collapsing all trust decisions into one token.

In practice, IAM teams should:

• Define approved issuers and document who may mint each credential type.
• Require policy for revocation status checks, including whether the verifier supports live lookup or cached trust.
• Standardise claim schemas so the relying party can interpret attributes consistently.
• Limit credential lifetime where possible and prefer selective disclosure for sensitive attributes.
• Log verification events so audits can trace which claims were accepted, by whom, and under what policy.

Where this becomes especially important is in hybrid environments that already struggle with fragmentation. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say non-human IAM practices lag human IAM, a sign that adding a second identity model without governance discipline can widen the gap rather than close it. These controls tend to break down when issuers are decentralized but verifier policy remains local, because each relying party begins inventing its own trust rules.

Common Variations and Edge Cases

Tighter credential governance often increases onboarding effort, requiring organisations to balance portability against operational control. That tradeoff is real, especially when teams want decentralization for external users, partners, or cross-domain access but still need consistent revocation and auditability. There is no universal standard for every credential format, so best practice is evolving rather than settled.

Edge cases usually appear where trust becomes transitive. For example, an organisation may accept a credential from a partner that itself relies on another issuer chain. At that point, IAM teams need explicit policy on issuer hierarchy, acceptable assurance levels, and whether delegated issuance is permitted at all. Another common failure mode is assuming a wallet presentation proves current authorisation. It does not. The verifier still needs a policy decision about whether the subject, issuer, and claim combination is acceptable for the requested action.

IAM teams should also be careful not to use verifiable credentials to paper over weak lifecycle controls in existing directories. If the underlying governance model cannot answer who can revoke, how quickly revocation propagates, and how exceptions are handled, portability simply moves the problem elsewhere. For broader identity governance context, the Top 10 NHI Issues highlights the same pattern: trust failures usually come from lifecycle gaps, not from the credential format itself.

Related resources from NHI Mgmt Group

• How should IAM teams respond when Office 365 identity sprawl spans human and non-human access?
• How should security teams reduce identity silos across IAM, ITDR, and NHI tooling?
• What do IAM teams get wrong about unified identity platforms?
• How should IAM teams handle systems that are outside their identity governance tools?