EUDI Wallet regulation is reshaping European bank authentication

At a glance

What this is: This is an analysis of how EU digital identity and payments regulation is forcing banks toward EUDI Wallet support for onboarding and authentication, with unresolved questions around outsourcing, liability, and assurance.

Why it matters: It matters because IAM and security teams now have to align human identity journeys, delegated wallet trust, and regulatory accountability inside one authentication programme rather than treating them as separate controls.

By the numbers:

• 24 December 2027: The above-mentioned relying parties need to support EUDI Wallets for strong user authentication.
• Article 5f(2) requires large and medium-sized relying parties in 10 sectors to accept EUDI Wallets for strong user authentication, upon the voluntary request of the user.
• The draft PSR is expected around May 2026.

👉 Read OneSpan's analysis of EUDI Wallet requirements for European banks

Context

EUDI Wallet adoption is no longer a distant policy concept. In European banking, eIDAS 2.0, the AML package, and the draft PSR/PSD3 direction are converging on a single operational question: how do banks accept and verify a user-held digital credential without weakening authentication assurance or creating new outsourcing ambiguity?

For IAM teams, this is not just a compliance update. It is a human identity and transaction-authentication change that affects onboarding, strong customer authentication, credential assurance, and accountability when the wallet itself sits outside the bank's direct control.

Key questions

Q: How should banks prepare for EUDI Wallet support in onboarding and authentication?

A: Banks should map EUDI Wallet use cases to specific journeys, then separate assurance, legal, and operational controls by use case. Strong customer authentication, customer due diligence, and attribute verification do not carry the same evidence requirements. The practical goal is to avoid building a single wallet integration that fails audit, fraud, or liability review later.

Q: Who is accountable when wallet-mediated authentication fails?

A: Accountability depends on whether the bank is acting as the relying party, the issuer, or the verifier of the credential elements involved. If the wallet relies on external trust services, banks need a clear control map that shows which party owns validation, incident response, and evidence retention. Without that map, liability becomes ambiguous during disputes or fraud investigations.

Q: What do banks get wrong about EUDI Wallets and strong authentication?

A: The common mistake is treating wallet support as a simple interface change. In practice, it reshapes the trust chain, the outsourcing model, and the evidence needed to prove assurance. If those changes are not reflected in architecture and governance, the bank may meet the technical requirement but still fail the regulatory intent.

Q: What is the difference between customer due diligence and strong customer authentication here?

A: Customer due diligence proves who the customer is and what attributes they possess, while strong customer authentication proves the user is present and authorised for the transaction. EUDI Wallets may support both, but the controls, evidence, and liability questions are different. Teams should not assume one control automatically satisfies the other.

Technical breakdown

How EUDI Wallets change strong customer authentication

The EUDI Wallet model shifts banking authentication from bank-issued credentials toward user-held, regulator-backed identity assertions. Under eIDAS 2.0 and the draft PSR direction, the bank may still make the authentication decision, but the credential evidence can originate from a wallet and a Qualified Trust Service Provider. That creates a different trust chain from password plus OTP or app-based MFA. The key technical question is not whether the bank authenticates the user, but how it validates assurance, binding, and transaction context when the evidence is externalised.

Practical implication: map wallet acceptance to existing authentication assurance requirements and define where bank control begins and ends.

Why outsourcing ambiguity matters in wallet-mediated identity

The article highlights a tension in draft PSR Article 87. If a technical provider verifies elements of strong customer authentication, banks may need outsourcing agreements. DG Connect argues that wallet support does not equal authentication delegation because the bank retains the decision. That distinction matters technically because it determines whether the wallet is treated as an external assurance source or a managed authentication dependency. Ambiguity here affects control ownership, audit evidence, and liability boundaries.

Practical implication: classify each wallet integration by control dependency before legal and procurement teams finalise contractual terms.

Qualified electronic attestations and verification assurance

Qualified Electronic Attestations of Attributes, or QEAAs, are the bridge between digital identity and customer due diligence. They are designed to carry verified attributes from a Qualified Trust Service Provider with a legal assurance profile that regulators can treat as equivalent to traditional documents. Technically, that changes onboarding from document capture and selfie verification to attribute trust and attestation validation. The operational benefit is lower fraud exposure, but only if the bank can validate issuer trust, attribute freshness, and acceptance criteria consistently across the lifecycle.

Practical implication: build attribute-validation rules and issuer trust controls before turning wallet acceptance into a production onboarding path.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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 becoming a human identity governance problem, not just a payments issue. Banks are being asked to accept a user-held credential inside regulated onboarding and authentication journeys, which means identity assurance, legal obligation, and transaction context now intersect. The control model is broader than MFA replacement, because the programme must govern how third-party assurance is accepted, verified, and audited across customer journeys. Practitioners should treat this as an identity architecture change with regulatory consequences.

Outsourcing ambiguity is the real control gap, not wallet technology. The article exposes a governance assumption that authentication is always bank-owned end to end. That assumption fails when a bank accepts a wallet-backed credential whose issuance and verification depend on external trust services, because accountability can no longer be inferred from direct control of the credential flow. The implication is that banks must re-evaluate where authentication responsibility actually sits in the chain.

Qualified Electronic Attestations create a new trust boundary for onboarding. QEAAs move customer due diligence away from document imaging and toward attribute assurance. That changes the failure mode from document fraud to issuer trust, attribute validity, and acceptance logic. For IAM leaders, the issue is not whether digital credentials are modern enough, but whether their assurance model can withstand regulator scrutiny when the evidence source is outside the bank.

Regulatory timelines are compressing identity programme decisions. The convergence of eIDAS 2.0, AMLR, and the draft PSR means banks cannot wait for perfect clarity before planning wallet acceptance. Ambiguity in the final text will likely remain, but programme design choices made now will shape auditability, liability mapping, and integration depth later. The practical conclusion is that identity roadmaps must be built for policy change, not fixed assumptions.

Wallet-mediated authentication will blur the boundary between customer identity and federated identity governance. That matters because human IAM teams often treat onboarding, authentication, and fraud controls as separate domains. In this model they become one operational chain, and the bank must govern them as such. The discipline shift is from isolated login controls to end-to-end identity assurance management.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why identity governance breaks when control ownership is unclear.
• That visibility gap makes the Ultimate Guide to NHIs , Regulatory and Audit Perspectives a useful next step for teams mapping audit evidence and accountability.

What this signals

EUDI Wallet support will force banks to unify identity assurance and payment authentication governance. The programme signal is clear: separate IAM, fraud, AML, and payments workstreams will not stay separate for long. Banks that model wallet acceptance as a control boundary exercise, rather than a feature rollout, will be better positioned to explain assurance and liability to auditors.

Wallet-mediated trust needs a named concept: assurance delegation drift. That is the point at which a bank treats externally issued identity evidence as if it were internally controlled, without formally defining the boundary. Once that drift exists, audit, incident response, and legal accountability all inherit the same ambiguity.

For practitioners, the near-term watch item is contractual and architectural readiness rather than wallet UX. Banks should expect more scrutiny on who verifies what, which trust service is accepted, and how evidence is retained across onboarding and transaction flows, especially as regulatory text settles.

For practitioners

• Map wallet acceptance to regulated assurance levels Document which EUDI Wallet flows satisfy strong customer authentication, which satisfy customer due diligence, and where evidence must be supplemented with additional checks.
• Classify outsourcing boundaries before implementation Decide whether wallet verification is an external dependency, a delegated control, or a bank-owned decision path so legal, risk, and architecture teams use the same model.
• Define issuer trust criteria for QEAAs Create rules for accepted issuers, attribute freshness, revocation handling, and evidence retention so onboarding teams do not improvise trust decisions at runtime.
• Align IAM, AML, and payments teams on one control map Build a shared matrix that links onboarding, strong authentication, and due diligence requirements to the same journey stages and audit evidence.
• Prepare for the 2027 support deadline now Sequence architecture, vendor, and compliance work so that wallet support, exception handling, and liability review are ready before the December 2027 requirement lands.

Key takeaways

• EUDI Wallet adoption turns banking authentication into a regulated identity governance problem, not just a user experience update.
• The main risk is not the wallet itself but the ambiguity around assurance, outsourcing, and accountability when external trust services enter the chain.
• Banks that align IAM, AML, and payments governance now will be better prepared for the 2027 support requirement and the audit trail it implies.

Key terms

• EUDI Wallet: An EUDI Wallet is a user-controlled digital identity wallet intended to store and present verified identity credentials within the European Union. In banking, it changes the trust model by allowing customer identity evidence to be supplied through regulated wallet ecosystems rather than only bank-issued authentication methods.
• Qualified Electronic Attestation Of Attributes: A Qualified Electronic Attestation of Attributes is a digitally signed statement that confirms specific identity attributes, such as age or account-related data, from a trusted issuer. It is used to replace manual document checks with verifiable electronic evidence that can support onboarding and authentication decisions.
• Strong Customer Authentication: Strong customer authentication is a regulated authentication requirement that asks for robust proof that the customer is genuinely present and authorised. In practice, it usually combines multiple factors or equivalent assurance methods, and under the EUDI Wallet model it may be satisfied through wallet-backed identity evidence.
• Outsourcing Boundary: An outsourcing boundary is the line between what a bank controls directly and what a third party helps provide or verify. For identity programmes, that boundary determines who owns assurance evidence, incident response duties, auditability, and liability when authentication depends on external services.

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 you are designing identity governance for regulated customer journeys, it is worth exploring.

This post draws on content published by OneSpan: Why European banks must act now on EUDI Wallets. Read the original.