EUDI wallet pilots shift digital identity governance in Europe

At a glance

What this is: This is OneSpan’s analysis of how EUDI wallet pilots are testing regulated digital identity use cases and pushing European identity governance toward production readiness.

Why it matters: It matters because IAM teams must prepare for wallet-based assurance, acceptance, and authentication rules that affect customer onboarding, payments, and cross-border identity flows.

Context

The EUDI wallet pilots are about governance, not just technology. They test whether a digital identity wallet can be trusted as an accepted identity source in regulated journeys such as banking, payments, and cross-border transactions.

For IAM, the important shift is that identity assurance is being pushed into a wallet-mediated model with clear acceptance rules. That affects customer due diligence, strong customer authentication, and the controls organisations use to decide when wallet assertions are good enough for regulated use.

This is not a theoretical exercise. The pilots are intended to show whether the future acceptance model can be secure, interoperable, and user-friendly at European scale.

Key questions

Q: How should organisations decide when to accept an EUDI wallet claim?

A: Organisations should define acceptance criteria for each use case, including assurance level, attribute freshness, transaction context, and relying-party verification. A wallet claim is only useful when the receiving system knows exactly what it is willing to trust and what evidence still needs to be checked locally.

Q: Why do EUDI wallet pilots matter for customer due diligence?

A: They test whether verified identity data can be reused for onboarding without losing assurance or auditability. That matters because customer due diligence depends on trusted evidence, not just convenience, and regulated firms still need to prove how identity was established and accepted.

Q: What breaks if wallet-based strong customer authentication is not tightly governed?

A: If wallet-based SCA is loosely defined, organisations can end up accepting a possession factor without confirming the transaction context, relying party, or evidence trail. That weakens both security and compliance, especially where payment authorisation must be demonstrably tied to the right session and user action.

Q: What is the difference between wallet acceptance and identity proofing?

A: Identity proofing establishes who the subject is and how that identity was verified, while wallet acceptance determines whether a relying party will trust the wallet’s assertion for a specific use case. They are related but not interchangeable, and confusing them leads to over-trusting portable credentials.

Technical breakdown

How EUDI wallet trust is being tested in real-world identity flows

The EUDI wallet model shifts identity proofing and authentication into a portable credential layer that can be reused across services. In practical terms, the wallet becomes a presentation mechanism for verified attributes and assurance signals, rather than a simple login token. The pilots are important because they test whether relying parties can verify those signals consistently across banking, payments, travel, and cross-border journeys. That makes interoperability, assurance mapping, and acceptance logic central to the architecture. The identity question is not whether the wallet exists, but whether downstream systems can trust what it asserts under different regulatory and business conditions.

Practical implication: Practitioners should map where wallet assertions replace existing proofing or login steps and identify which trust checks still need to remain local.

What EUDI wallets change for customer due diligence and SCA

OneSpan’s article ties the wallet to customer due diligence and strong customer authentication. That matters because CDD depends on verified identity data being accepted with enough confidence to reduce manual onboarding friction, while SCA depends on the wallet acting as a possession factor in a regulated authentication flow. The technical challenge is not only credential presentation, but binding wallet use to the correct transaction and relying party, then proving the wallet interaction meets the relevant regulatory threshold. In other words, the wallet has to be both usable and defensible inside compliance workflows.

Practical implication: Identity teams should test wallet acceptance against onboarding and login flows separately, because CDD and SCA place different demands on assurance and auditability.

Why interoperability and acceptance rules matter more than pilot branding

Large-scale pilots are useful only if they clarify which identity attributes, assurance levels, and transaction contexts are acceptable across participants. Without that, each relying party will create its own interpretation layer, which fragments the promise of a unified identity framework. The pilots therefore function as a policy and integration exercise as much as a technology one. For IAM and governance teams, the technical issue is whether acceptance logic can be standardised enough to support regulated adoption without forcing every service provider to reinvent its own wallet verification process.

Practical implication: Security architects should define acceptance criteria now, before wallet usage expands into production services and ad hoc trust decisions proliferate.

NHI Mgmt Group analysis

EUDI wallet governance will be decided by acceptance rules, not by wallet availability. The practical challenge is whether relying parties can decide when a wallet assertion is sufficient for onboarding, authentication, or transaction approval. That decision layer becomes the new control surface for digital trust in Europe. IAM teams should treat acceptance logic as a governance asset, not a user experience detail.

Customer due diligence changes when verified data moves into a portable wallet. The wallet does not remove the need for assurance, but it changes where proof is established and how it is reused. That moves pressure onto the organisation's identity proofing and attribute-trust decisions, especially where regulated onboarding depends on external assertions. Practitioners should reassess which checks remain mandatory at the point of use.

Strong customer authentication becomes a transaction design problem, not just an authentication problem. If the EUDI wallet is accepted as a possession factor, teams must ensure it is bound to the right session, transaction, and relying party context. That makes wallet-based SCA part of broader access governance, fraud resistance, and auditability. The implication is that authentication policy and payment policy will need to converge.

Digital identity convergence is the real signal behind these pilots. The same wallet model now touches onboarding, login, payments, and cross-border identity use, which means previously separate IAM, fraud, and compliance decisions are becoming linked. That convergence is likely to reshape enterprise identity architecture as much as citizen identity policy. Practitioners should plan for shared governance across those control domains.

EUDI wallets will expose whether current IAM programmes can govern external identity trust at scale. The pilots are effectively a stress test for how much of identity assurance can be shifted outside the organisation while still remaining auditable and controllable. That is a useful lesson for any team building identity convergence programmes. The next step is to decide which trust decisions can be delegated and which must remain internal.

What this signals

EUDI wallet pilots are a governance rehearsal for identity convergence. The immediate lesson for practitioners is that wallet adoption will blur the boundary between identity proofing, authentication, and transaction approval. Teams that still manage those as separate conversations will struggle when regulated acceptance rules start spanning all three.

The new control question is who gets to accept an external identity assertion. That question matters as much in enterprise IAM as it does in citizen identity frameworks, because acceptance policy is where trust becomes operational. Security and identity teams should move that decision out of ad hoc implementation work and into formal governance.

Wallet programmes will only scale if the organisation can define a stable trust boundary around assurance, context, and relying-party checks. Without that, every pilot becomes a one-off integration and the promised interoperability turns into local exception handling.

For practitioners

• Map wallet acceptance points Identify every onboarding, login, and payment flow where an EUDI wallet could replace or supplement current identity checks, then assign an explicit acceptance rule for each one.
• Separate CDD from SCA testing Validate customer due diligence and strong customer authentication as distinct control paths, because each relies on different assurance expectations, evidence, and failure modes.
• Define relying-party trust criteria Document what identity data, assurance level, and transaction context are required before the organisation will accept a wallet assertion in production.
• Align identity, fraud, and compliance governance Create a shared decision model for onboarding, authentication, and transaction approval so that wallet adoption does not produce inconsistent trust rules across teams.

Key takeaways

• EUDI wallet pilots are testing whether digital identity can be accepted as a governed trust source across banking, payments, and cross-border use cases.
• The practical challenge is not wallet existence, but consistent acceptance, assurance, and auditability at the point of use.
• IAM teams should treat wallet governance as part of identity convergence, where proofing, authentication, and transaction approval begin to overlap.

Key terms

• Eudi Wallet: A digital identity wallet is a user-controlled container for identity credentials, attributes, and presentation proofs. In regulated environments, it becomes part of the trust chain because relying parties may accept its claims for authentication, onboarding, or transaction approval.
• Customer Due Diligence: Customer due diligence is the process of verifying a customer’s identity and understanding the risk attached to that relationship. Wallet-based presentations can streamline it, but the institution remains accountable for deciding which attributes are trusted and how exceptions are handled.
• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Identity Acceptance Rule: An identity acceptance rule defines when an organisation will trust an external identity assertion for a specific purpose. It is the control that turns portability into governed use, because the same credential can be acceptable in one flow and unacceptable in another depending on assurance, context, and risk.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.