European EUDI wallet mandates are reshaping banking identity

At a glance

What this is: This analysis explains how EU EUDI wallet requirements are changing banking onboarding and strong customer authentication, with the key finding that banks must prepare for wallet acceptance while core accountability questions remain unresolved.

Why it matters: It matters because EUDI wallet support will touch customer IAM, fraud controls, compliance workflows and third-party assurance models, forcing identity teams to align human authentication and digital identity governance with new EU rules.

By the numbers:

• 24 December 2027: the date by which large and medium-sized relying parties in banking and other sectors must support EUDI wallets for strong user authentication.
• At least 27 EUDI wallets will exist, and probably many more, which makes outsourcing and assurance governance materially harder for banks.
• The final PSR text is expected around May 2026, leaving banks with a short planning window before implementation clarity arrives.

👉 Read OneSpan's analysis of EUDI wallet requirements for banking identity

Context

European banking identity is entering a transition from document-based onboarding and app-centric login flows toward wallet-mediated strong customer authentication. The primary keyword here is EUDI wallets, and the governance problem is that banks must prepare for a new trust model before the final operational details are fully settled.

The article argues that eIDAS 2.0, AMLR and the emerging PSR/PSD3 framework are converging on wallet support for onboarding and authentication, but leave open questions about outsourcing, liability and how banks satisfy security requirements when they do not control the wallet itself. For identity teams, this is a human authentication programme change with platform and third-party governance consequences, not just a compliance update.

The article’s starting position is typical for regulated financial services: the institution already has a strong authentication obligation, but the mechanism is changing under regulatory pressure rather than business choice.

Key questions

Q: How should banks prepare for EUDI wallet support in customer authentication?

A: Banks should start by mapping every login and onboarding flow that may need to accept an EUDI wallet, then identify the assurance evidence each step requires. They should align IAM, fraud, legal and operations teams on ownership now, because the regulatory deadline arrives before all implementation details are fully settled.

Q: Why do EUDI wallets create governance complexity for banking identity teams?

A: EUDI wallets split the authentication experience across the bank, the wallet issuer and the trust framework behind the credential. That makes assurance, liability and outsourcing analysis harder than in a bank-controlled MFA flow, because the institution may keep decision authority while depending on external identity evidence.

Q: What should organisations get wrong about using digital wallets for onboarding?

A: The common mistake is treating wallet acceptance as a front-end user experience change. In regulated banking, it changes evidence quality, attribute provenance, fraud investigation and auditability, so the onboarding model has to be redesigned around verifiable identity data rather than document images alone.

Q: Who is accountable when wallet-based authentication fails in a regulated bank?

A: Accountability should sit with the bank for the authentication decision, but the wallet ecosystem may own parts of the evidence chain and user credential handling. Until the final payment rules clarify liability, banks need explicit internal ownership for incident triage, customer remediation and vendor escalation.

Technical breakdown

EUDI wallet acceptance and strong customer authentication

EUDI wallets are being positioned as a trusted credential container for user authentication across EU services, including banking. In practice, the bank still performs the authentication decision, but the credential presentation and some assurance evidence may come from an external wallet ecosystem. That makes this different from a simple password or app-based MFA flow, because the bank has to validate both the user journey and the assurance properties of the wallet issuer. The article also highlights the wording gap between user authentication and customer authentication in existing payment terminology.

Practical implication: map EUDI wallet login to your existing authentication assurance controls and identify where the bank, wallet issuer and trust service provider each own evidence.

EUDI wallets in AML onboarding and KYC workflows

The AML angle is less about login and more about digital identity evidence. The article describes qualified electronic attestations of attributes, or QEAA, as high-assurance digital statements that can replace or supplement scanned IDs and selfies during customer due diligence. That changes the onboarding architecture from document capture to attribute verification. It also shifts control design toward attribute provenance, trust service validation and auditability, because the bank must be able to prove that the asserted identity data came from a qualified and acceptable source.

Practical implication: update onboarding design so attribute verification, not document upload, becomes the primary control point for regulated customer due diligence.

Outsourcing boundaries and authentication accountability

The article surfaces a major governance ambiguity: if a bank accepts many different EUDI wallets, does it need a contractual outsourcing relationship with each technical provider? DG Connect’s view is that it does not, because the bank still controls the authentication decision and does not truly delegate the function. That distinction matters because outsourcing controls are usually triggered by delegated operational dependence, and here the regulatory model is still being clarified. Until PSR or its technical standards settle the point, banks face an unresolved line between assurance dependency and formal outsourcing.

Practical implication: classify wallet integration as an assurance dependency first, then test whether any part of the flow crosses your outsourcing threshold under the final payment rules.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

EUDI wallet support is a human identity governance change, not just a payments update. The article is about regulated customer authentication, so the core programme impact sits in human IAM, not NHI or autonomous identity. Banks will need to reconcile wallet-mediated assurance with existing authentication policy, customer enrolment and fraud controls. The practitioner conclusion is that wallet readiness belongs in identity architecture planning now, not after the final payment text lands.

The outsourcing question exposes a governance boundary problem, not a technology problem. The article shows that banks may rely on external wallet ecosystems while still retaining authentication decision authority. That means the control question is whether the dependency is operationally outsourced or merely assured through trust frameworks and standards. The practitioner conclusion is to treat dependency mapping and accountability assignment as part of the authentication model itself.

Attribute-based onboarding will become the more important control surface than document collection. QEAA shifts the centre of gravity from scanned IDs and self-attested forms to qualified attribute proof. That matters because fraud resistance and user experience now depend on the integrity of the attribute issuer chain, not just the bank’s front-end checks. The practitioner conclusion is to redesign onboarding around verified attributes and evidence provenance.

Identity teams should expect regulatory ambiguity to persist until implementation standards catch up. The article makes clear that eIDAS 2.0, AMLR and PSR/PSD3 are converging faster than the technical rules that will operationalise them. That creates a short-term governance gap in which banks must plan for multiple wallet providers, uncertain outsourcing treatment and uneven liability allocation. The practitioner conclusion is to build flexible policy decisions that can survive the final standards text.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The state of non-human identity security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly trust boundaries become opaque when identity is delegated across systems.
• The banking lesson is forward-looking: use Ultimate Guide to NHIs , Key Challenges and Risks to pressure-test any wallet integration that depends on external assurance chains.

What this signals

EUDI wallets will force banks to harden identity governance at the assurance boundary. The programme shift is from controlling the password or app token to governing the trust evidence behind an externally issued wallet. That means customer IAM, fraud and compliance teams need shared policy language for what counts as acceptable assurance before deployment starts.

Wallet diversity will increase operational ambiguity unless banks define their own acceptance rules. If every wallet provider is treated differently in practice, onboarding quality and supportability will fragment. Banks should standardise what evidence is mandatory, what can vary by issuer, and where manual review still applies.

The broader signal is that digital identity regulation is moving identity teams toward federated evidence, not federated convenience. That aligns with the same control challenge seen in other delegated identity patterns: once the assurance chain extends outside the institution, governance must follow the trust path, not just the user interface.

For practitioners

• Map wallet-driven authentication dependencies Inventory every customer authentication and onboarding flow that could be touched by EUDI wallets, then document which steps rely on bank control, wallet issuer control or qualified trust service control. Use that map to find policy gaps before the final PSR wording is fixed.
• Redesign onboarding around verified attributes Replace document capture as the primary design assumption with attribute verification flows that can accept QEAA or equivalent high-assurance evidence. Make sure audit, fraud and operations teams can trace where the attribute came from and how it was validated.
• Test outsourcing thresholds against wallet integration Review whether any wallet-related integration creates a contractual outsourcing obligation under your internal policy or the final payment framework. Pay special attention to operational dependence, incident handling, and the evidence you would need if regulators challenge the boundary.
• Align fraud ownership before liability is clarified Draft interim ownership for wallet-related fraud events so the bank can triage disputes, customer remediation and evidence preservation even if the final rulebook stays ambiguous. Make accountability explicit across authentication, onboarding and dispute resolution teams.

Key takeaways

• EUDI wallet adoption changes banking identity governance because authentication, onboarding and assurance now span multiple trust domains.
• The evidence points to a narrow implementation window, with 24 December 2027 acting as the key operational deadline for bank readiness.
• Banks that define assurance ownership, onboarding evidence and liability now will be better positioned when the final PSR and related technical standards are published.

Key terms

• EUDI Wallet: A European Digital Identity wallet is a user-held digital credential container intended to support trusted authentication and attribute sharing across public and private services. In banking, it changes the trust model by moving part of the assurance evidence outside the institution while leaving the bank responsible for the access decision.
• Qualified Electronic Attestation Of Attributes: A QEAA is a digitally issued, high-assurance statement about a person’s attributes, such as identity-related facts needed for onboarding or verification. It matters because it can replace lower-trust document scanning with verifiable evidence from a qualified trust service, provided the bank can audit the provenance and validation path.
• Strong Customer Authentication: Strong customer authentication is a regulated authentication requirement that uses more than one factor or evidence type to confirm a customer’s identity. In this context, the important point is not the number of factors alone, but who issues the evidence, who validates it, and who remains accountable when the flow spans multiple providers.
• Outsourcing Boundary: An outsourcing boundary is the line where a bank’s internal control responsibility may become a formally contracted third-party service relationship. For EUDI wallets, the ambiguity is whether reliance on an external wallet ecosystem is merely an assurance dependency or crosses into regulated outsourcing that changes oversight and contractual duties.

Deepen your knowledge

EUDI wallet onboarding and strong customer authentication are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your identity programme must bridge regulated human authentication and external trust evidence, it is worth exploring.

This post draws on content published by OneSpan: Pourquoi les banques européennes doivent agir dès maintenant concernant les portefeuilles EUDI. Read the original.