How should identity teams design for interoperability across changing digital identity standards?

Why interoperability is a governance problem before it is a protocol problem

Interoperability across changing digital identity standards is easiest when teams separate the durable policy layer from the changeable technical layer. The durable layer defines who can trust whom, under what assurance rules, and with what evidence. The technical layer then maps those rules to whichever credential format, wallet profile, or protocol the market adopts next.

This approach prevents every standards update from forcing a redesign of the identity model itself. It also makes migration cleaner, because the organisation can swap transport or presentation mechanisms without rewriting core trust decisions, subject definitions, or approval workflows.

That separation matters most when identity spans multiple jurisdictions or relying parties. A eIDAS 2.0 — EU Digital Identity Framework is a good example of a regime that can change deployment expectations while still leaving organisations to preserve stable governance, assurance, and acceptance rules.

What should stay stable when standards change?

The stable part is the trust model: assurance requirements, issuance authority, trust anchors, attribute acceptance rules, evidence retention, revocation handling, and decision ownership. These are the controls that let identity teams answer the same business question consistently even when the credential format changes from one ecosystem to another.

The unstable part is the implementation surface: protocols, wallet profiles, verifiable credential profiles, presentation mechanisms, cryptographic bindings, and registry-specific metadata. If those are treated as interchangeable, the programme can support several standards at once without creating separate identity silos for each one.

That design also reduces lock-in to a single vendor or jurisdictional stack. When the team defines the governance rule first, it can attach new standards to an existing policy model instead of creating a new operating model for every technical release. The practical goal is not one universal format, but one consistent decision framework that can absorb new formats.

A useful way to test the design is to ask whether a new standard would require changes to your user, issuer, verifier, and policy decision flows. If the answer is yes, the architecture is probably too tightly coupled to the protocol. If the answer is no, the standard can usually be introduced as another supported translation layer.

How do teams avoid breaking interoperability during migration?

Interoperability fails when implementation teams encode standards too deeply into business logic. The safer pattern is to use a canonical internal identity model, then map each external standard into and out of that model. That preserves local consistency while still allowing multiple external representations to coexist during transition.

Versioning is critical. Teams should expect several standards to run in parallel, especially where wallets, cross-border identity, and sector-specific trust frameworks evolve at different speeds. The operating model should therefore support profile selection, deprecation windows, and explicit compatibility decisions rather than assuming one clean cutover.

Governance should also cover exception handling. Some relying parties will only accept older profiles, some jurisdictions will mandate a specific wallet profile, and some ecosystems will require different assurance evidence. The right response is not to hard-code exceptions into core identity logic, but to document them as policy variants with clear ownership and review dates.

For programme structure, NHIMG’s Identity Security Programme Guide is a useful reference for building the operating model, while the Digital Identity, eID and Identity Wallets Guide helps anchor wallet and verifiable credential concepts in the wider interoperability picture.

Risk and Threat Considerations

Interoperability creates risk when organisations confuse format compatibility with trust compatibility. A system can technically accept a credential or wallet presentation and still make the wrong trust decision if assurance, issuer trust, revocation status, or attribute provenance are not governed consistently.

Failure mechanism: Teams hard-wire one standard into application logic, then discover they cannot safely accept a new profile, deprecate an old one, or distinguish trusted issuance from merely syntactically valid input. That creates brittle integrations, inconsistent acceptance rules, and a larger attack surface during migration.

Impact: The organisation can end up with fragmented identity policy, duplicated integrations, slower jurisdictional rollout, and higher fraud or account-abuse risk if relying parties accept the wrong evidence model or bypass intended assurance checks.

Practitioner Guidance

What to prioritise: Define the trust policy, assurance thresholds, and acceptance rules first, then map each supported standard to those rules. If the policy cannot survive a protocol swap, the architecture is too coupled.

What to verify: Confirm that core workflows, policy decisions, and audit evidence are independent of any single wallet profile or credential syntax. A new standard should change the adapter, not the governance model.

Common mistake: Treating “supports standard X” as the same thing as “interoperable.” Real interoperability means you can add, retire, or dual-run standards without changing how trust is decided.

Practitioner takeaway: The most resilient identity architectures define one stable trust model and let standards come and go at the edges, because that is what keeps interoperability manageable as ecosystems evolve.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who should own digital health access design across security and clinical teams?
• How should security teams govern digital identity verification across web and mobile channels?
• What do security teams get wrong about digital identity interoperability?