What breaks when digital identity systems treat interoperability as the main goal?

What interoperability actually does, and what it cannot decide

Interoperability is a transport and translation problem first. It helps systems exchange identity assertions, credentials, and delegation data in a standardised way, but it does not by itself define the trust policy behind those objects. A credential can be syntactically valid, portable, and machine-readable while still being the wrong credential for the decision being made.

That is why interoperability should be treated as a prerequisite for federation, not as a substitute for governance. The hard question is whether the ecosystem can answer who is trusted, under what authority, and with what scope. Where that answer is missing, cross-system compatibility can make a weak trust decision easier to propagate, not safer.

For wallet and credential ecosystems, the practical distinction is that interoperability lets a verifier understand the format while governance determines whether the issuer, relying party, or delegate is acceptable for a given transaction. NHIMG’s Digital Identity, eID and Identity Wallets Guide is useful here because it frames how reusable identity is supposed to work when trust frameworks, assurance, and verification rules are all part of the design.

Which trust decisions break when format compatibility is overvalued

The first failure is issuer trust. A system may successfully parse a verifiable credential or federation token and still lack the policy needed to reject an untrusted issuer. That means interoperability can create a false sense of assurance if validation is reduced to schema checks, signature checks, or protocol compliance.

The second failure is delegated authority. A digital identity stack can move a credential or assertion correctly while allowing a delegate to act beyond the authority actually granted. In practice, the system may not distinguish between “can present this artifact” and “is authorised to bind, revoke, or rely on it.”

The third failure is revocation and liability. If the architecture can exchange assertions but cannot answer who may revoke them, what triggers revocation, and who is accountable when an accepted assertion later proves invalid, the operational model is incomplete. Interoperability does not close that gap; policy and legal governance do.

NHIMG’s Ultimate Guide to NHIs, Standards helps on the technical side by showing how zero trust, identity standards, and workload identity controls fit together, which is relevant whenever interoperable systems must still make a defensible trust decision.

NHIMG’s Identity Proofing and KYC Guide is also relevant because interoperability often exposes a deeper issue: whether the original identity proofing and assurance level were strong enough to justify downstream reliance.

Why governance has to sit above the protocol layer

Interoperability works best when it is constrained by a governance layer that defines issuer eligibility, assurance thresholds, delegation rules, and liability boundaries. Without that layer, every participant can technically interoperate while still operating under incompatible trust assumptions.

This is where policy needs to be explicit about acceptance criteria, not implied by the format. A verifier should know which issuers are recognised, which credentials are acceptable for which use case, whether delegation is allowed, and what evidence is required before a transaction is accepted or revoked. That policy cannot be inferred from the wire format alone.

Operationally, the safest model is to separate “can be processed” from “can be trusted.” Many failures begin when an organisation treats successful parsing as approval, or treats cross-platform portability as proof that the authority behind the credential is sufficient for the decision at hand.

NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful for the governance angle because interoperability issues often surface as auditability problems, missing ownership, and weak accountability over issued or delegated credentials.

Risk and Threat Considerations

When interoperability is treated as the goal instead of the mechanism, the main risk is trust collapse by acceptance. Systems can end up accepting credentials, assertions, or delegated actions from parties that are technically compatible but not operationally or legally trusted, which creates avoidable exposure across onboarding, access, and revocation paths.

Failure mechanism: The protocol succeeds while the trust decision fails, because validation checks the message format or signature but not issuer eligibility, delegation scope, or revocation authority.

Impact: Organisations can grant access, honour actions, or retain trust in credentials that should have been rejected, and later struggle to assign responsibility when misuse or failure occurs.

Practitioner Guidance

What to verify: Before you rely on an interoperable identity flow, verify that the verifier has a policy for issuer trust, delegation scope, revocation handling, and liability assignment. If those rules are not documented, the system may be interoperable but not governable.

Decision rule: If the control only proves that a credential can be read, treat it as compatibility evidence, not trust evidence. If the control also binds issuer authority, delegation limits, and revocation semantics, it is suitable for operational reliance.

What practitioners underestimate: The hardest failures are often not cryptographic. They come from assuming that a standard format implies a trusted relationship, when the real problem is who is allowed to assert, revoke, or delegate in the first place.

Practitioner takeaway: Interoperability should be the plumbing, not the policy. The architecture is only trustworthy when the organisation can still answer who issued the identity, who may act on it, and who is accountable when that trust breaks.

Related resources from NHI Mgmt Group

• What breaks when digital identity is fragmented across siloed systems?
• What breaks when digital identity systems rely on passwords instead of stronger proofing methods?
• What breaks when organizations treat internal collaboration systems as trusted by default in identity and access control?
• What are the main failure points when digital voucher systems are used without strong identity checks?