The organisation gains wallet acceptance but loses customers who need a different channel to complete onboarding. That creates a compliance win for some journeys and a conversion problem for others. The result is an incomplete identity stack that performs well only for a narrow part of the market.
When EUDI Wallet support is added without fallback verification paths
Adding wallet support without an alternate verification route creates a one-channel onboarding design. That can satisfy a regulated digital identity journey, but it also excludes people whose wallet is unavailable, unsupported, or simply not the channel they can use at that moment. The design problem is usually not the wallet itself, but the lack of a parallel path for assurance.
Why the onboarding journey becomes fragile
An eudi wallet flow is only useful if it fits the whole customer journey, not just the strongest segment of it. When it is made mandatory too early, the organisation turns a verification method into a gatekeeper. That is fine for some high-assurance journeys, but it becomes a conversion risk when customers need an alternative method to prove identity, recover access, or complete onboarding under a different device or channel.
In practice, the failure is architectural. A single verification path creates a hard dependency on wallet availability, wallet readiness, and wallet acceptance. If any of those conditions fail, the journey stops instead of degrading gracefully. That is why wallet support should be treated as one assurance route inside a broader identity design, not as the whole identity design.
For the policy and interoperability context behind the wallet model, see Digital Identity, eID and Identity Wallets Guide and the legal basis in eIDAS 2.0, the EU Digital Identity Framework.
What the missing fallback changes operationally
Without fallback verification, the organisation has fewer ways to handle edge cases that occur routinely in real onboarding: a user cannot access the wallet, the relying party cannot validate the presented credential, the wallet does not support the needed attribute set, or the customer is onboarded from a device or context that cannot complete the wallet step. Each of those conditions becomes a drop-off point instead of a recoverable exception.
This also changes the assurance profile of the programme. A wallet-first flow can improve standardisation and reduce manual handling, but if there is no fallback, the organisation may trade flexibility for unusable certainty. The result is often a narrow compliance success with a broader business failure, especially where different customer segments, devices, countries, or onboarding contexts must all be served.
Practitioners should also separate wallet acceptance from identity proofing depth. If the wallet path is the only path, the team may accidentally assume that a successful wallet presentation solves every onboarding use case. It does not. Some journeys still need a backup route for exception handling, recovery, and customers who are legitimate but temporarily unable to use the preferred channel.
When you need the underlying proofing mechanics and exception patterns, Identity Proofing and KYC Guide is the more relevant internal reference for understanding how verification failures and onboarding fraud controls fit into the broader flow.
How to design the journey so wallet support does not become a dead end
A resilient implementation keeps the wallet path as the preferred route when it works, but retains a clearly governed alternative for cases where it does not. That alternative does not need to be equal in every respect, but it must be explicit, supportable, and acceptable to the business and compliance teams. The key decision is not whether to offer fallback, but which cases it covers and what assurance threshold it must meet.
The external control lens is useful here. OWASP ASVS is helpful when you are translating the journey into application requirements for authentication, session handling, and access decisions, while NIST Cybersecurity Framework 2.0 helps teams keep the identity journey aligned to govern, protect, detect, respond, and recover expectations.
If the implementation also depends on APIs to request or validate wallet-backed attributes, then OWASP API Security Top 10 becomes relevant to the integrity of the supporting workflow, especially around authentication and authorization failures in the verification service itself.
Risk and Threat Considerations
When a wallet-only model is deployed too aggressively, the main risk is not just rejected users, it is uneven trust. Some customers can complete onboarding cleanly, while others are forced out of the journey or routed into manual exceptions that were never designed for scale. That creates both business exposure and governance exposure because the identity process no longer behaves consistently across the user base.
Failure mechanism: the organisation assumes the wallet is universally available and usable, so it removes alternate verification paths before the wallet journey has proven coverage across devices, populations, and recovery scenarios. Legitimate users then fail at the point of verification rather than being rerouted into a controlled alternative.
Impact: conversion drops, support demand rises, and the onboarding stack becomes brittle. In regulated environments, the organisation may still improve one compliance objective while quietly undermining access, customer completion, and operational resilience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, OWASP ASVS and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Wallet-backed onboarding depends on strong authentication and recovery design. |
| Recommendation — Define alternative authentication paths for users who cannot complete the wallet flow. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The topic is about access to onboarding through a controlled identity path. |
| Recommendation — Maintain a fallback identity path when the primary verification channel is unavailable. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Wallet verification often relies on backend APIs that must authenticate requests correctly. |
| Recommendation — Harden wallet validation APIs so failures do not block legitimate onboarding. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The journey needs governed access decisions across primary and fallback verification routes. |
| Recommendation — Document and enforce which users can use wallet-only versus fallback verification. | ||
Practitioner Guidance
What to verify: Test the onboarding flow against real exception cases, not just the happy path. If the wallet cannot be used, the process should still have a governed decision point, not an implicit dead end.
Decision rule: If wallet verification is mandatory for all users, require a documented fallback path for unavailable wallets, unsupported attributes, and recovery scenarios before go-live.
What good looks like: The wallet is the preferred route, but the organisation can still complete onboarding without forcing customers into an unsupported or manual-only exception process.
Practitioner takeaway: Treat EUDI Wallet support as a stronger verification option, not as a single point of failure in the identity journey.
Related resources from NHI Mgmt Group
- How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
- How should regulated businesses prepare for EUDI Wallet adoption without rebuilding their entire verification stack?
- What happens when regulated businesses rely on wallet-based identity without protecting for new fraud paths?
- What happens when identity verification is added without careful tuning of the user flow?