What should teams do when a wallet or jurisdiction is not supported?

How to handle an unsupported wallet or jurisdiction

When a wallet or jurisdiction is not supported, the right response is to treat it as unavailable and move the user to the next accepted path rather than trying to stretch the policy. That keeps the assurance model consistent and avoids creating exceptions that are hard to defend later.

In practice, the fallback should already be defined in the onboarding or proofing flow. If the user cannot present a supported wallet, teams should offer an alternate proofing method that is already approved for that population and use case, rather than improvising a one-off approval.

Why unsupported should not become “lower assurance”

An unsupported wallet is not the same thing as a weaker version of a supported wallet. If teams reinterpret it that way, they can accidentally bypass the trust decision that the policy was designed to enforce. That creates inconsistent treatment across users and jurisdictions and can undermine auditability.

The safer pattern is to separate availability from assurance. Support is a policy and operations question, while assurance is the control decision. If a wallet is out of scope, the issue is not that the wallet is less trustworthy, but that it has not been accepted into the controlled path.

What the fallback path should include

The fallback needs to preserve the same decision quality, even if the method changes. For many programs that means document verification, remote identity proofing, or another credential type already accepted by policy. Where the workflow requires it, manual review can provide the exception handling layer, but it should be governed and recorded rather than ad hoc.

Teams should also make sure the alternative path is explicit about what evidence is required, what the expected turnaround is, and when escalation is needed. If the fallback is slower or more manual, that is acceptable so long as the decision remains consistent and the user knows what to do next.

Risk and Threat Considerations

Unsupported wallets become risky when teams treat them as a shortcut around proofing rules. That can lead to inconsistent identity acceptance, unsupported regional exceptions, and a weaker audit trail for who was allowed through and why.

Failure mechanism: The control fails when unsupported credentials are informally accepted, reclassified on the fly, or exempted without an approved alternate proofing decision.

Impact: Organisations can end up admitting users through a path they did not design, which increases identity fraud exposure, creates review gaps, and makes later challenge or revocation harder to justify.

Practitioner Guidance

What to verify: Confirm that every unsupported wallet or jurisdiction maps to a documented fallback path before the flow goes live. If the alternative depends on manual review, make sure reviewers know the approval criteria and the evidence they must retain.

Decision rule: If the supported path is unavailable, route to the next approved proofing option; do not downgrade the wallet and do not create a special-case acceptance rule in the moment.

Practitioner takeaway: The key judgement is to preserve policy integrity under exception handling, because unsupported must mean “use another approved path,” not “accept less control.”

Related resources from NHI Mgmt Group

• What happens when an mDL wallet is not supported by a verifier?
• What is the difference between federated trust and decentralized trust in wallet ecosystems?
• How should banks prepare for EUDI wallet acceptance in regulated journeys?
• What breaks if an EUDI wallet is treated like a generic login method?