TL;DR: European banks are being pushed by eIDAS 2.0, AMLR, and draft PSR/PSD3 toward EUDI Wallet support for customer onboarding and strong authentication, with 24 December 2027 emerging as the key operational deadline, according to OneSpan. The real issue is not wallet availability but how banks govern assurance, liability, and third-party dependence when authentication becomes wallet-mediated.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: EUDI Wallets are changing European bank onboarding and authentication, and banks must prepare for wallet support under multiple overlapping EU rules.
Why it matters: It matters because IAM and security teams must align authentication, onboarding, third-party governance, and fraud controls to a wallet-mediated model that changes assurance and liability assumptions.
Context
European bank authentication is moving from a purely bank-controlled model to one shaped by regulated digital identity wallets. The practical question is no longer whether wallets can work, but how onboarding, strong customer authentication, and liability are governed when the credential sits partly outside the bank’s direct control.
The article ties that change to eIDAS 2.0, AMLR, and draft PSR/PSD3, which together create a compliance path toward EUDI Wallet support. For IAM and fraud teams, the governance gap is in the handoff between identity assurance, authentication decisions, and outsourced technical dependencies.
The primary operational pressure point is the 24 December 2027 deadline cited in the article for relying parties that must support EUDI Wallets for strong user authentication. That makes this a programme-planning issue, not a future-state discussion.
Key questions
Q: What breaks when banks add EUDI Wallets without revising authentication governance?
A: Banks can end up with a control model that assumes they own the entire authentication chain when they do not. That creates gaps in assurance evidence, incident accountability, and third-party dependency management, especially when wallet behaviour affects fraud outcomes or strong customer authentication decisions.
Q: Why do EUDI Wallets create liability questions for banks?
A: Because the bank may be responsible for accepting the authentication result while another party contributes the wallet assurance. If responsibility, verification, and issuance are split, the bank needs a clear liability model for failures, fraud, and service disruption.
Q: How should security teams govern wallet-based strong customer authentication?
A: Treat wallet-based authentication as a governed trust relationship, not a user convenience layer. Define which controls the bank owns, which controls the wallet issuer owns, and which obligations must be proven to auditors or regulators before the wallet path goes live.
Q: What should banks prioritise first for EUDI Wallet readiness?
A: Banks should first map regulatory obligations to actual authentication flows, then identify where onboarding, strong customer authentication, and outsourcing assumptions overlap. That sequence exposes the legal and operational gaps that matter before implementation work begins.
Technical breakdown
EUDI Wallets as a regulated authentication rail
EUDI Wallets are not just another login method. In this context they are a regulated digital identity mechanism that can carry strong user authentication and verified identity attributes into banking journeys. The article frames them as the bridge between identity proofing, customer due diligence, and authentication, which means the wallet becomes part of the trust chain rather than a simple front-end convenience layer. That changes how banks think about assurance levels, credential acceptance, and the control boundary between issuer, wallet holder, and relying party.
Practical implication: treat wallet-mediated authentication as an identity architecture decision, not a channel feature.
Why outsourcing language becomes contentious
The draft PSR language on outsourcing matters because wallet support raises a governance question about who is actually providing and verifying the authentication elements. The article highlights the argument that banks may still retain control over the decision even if the wallet itself is external, which weakens a simple outsourcing interpretation. That ambiguity is material because outsourcing triggers different contractual, oversight, and accountability expectations than native authentication management.
Practical implication: map the authentication flow to determine where control ends and where third-party dependence truly begins.
Assurance, liability, and the bank’s control boundary
The most important technical issue is not wallet interoperability but assurance ownership. The article notes that banks do not fully control all wallets, yet they remain responsible for strong customer authentication and fraud outcomes. That creates a control boundary problem: banks must rely on external wallet assurances while still needing to satisfy internal security, fraud, and regulatory obligations. Until liability rules are clearer, the trust model remains partly unresolved.
Practical implication: document the control boundary for wallet-based authentication and expose any unresolved liability assumptions to risk owners.
NHI Mgmt Group analysis
Wallet-mediated authentication creates an assurance dependency problem, not just an integration problem. Once authentication evidence moves into an externally governed wallet, the bank no longer controls the full lifecycle of the credential it must trust. That shifts the real governance question from how to connect to wallets to how to evidence assurance when the proving event is outside the bank. Practitioners should treat this as a trust-boundary redesign, not a user-experience upgrade.
Authorship of the authentication decision remains the unresolved control point. The article’s outsourcing discussion shows that regulatory language can lag the operational model. If a bank still makes the final authentication decision, the wallet is not a delegated authenticator in the usual sense, yet the bank still inherits the risk of wallet weakness, fraud, and service failure. The implication is that control ownership and technical dependence are no longer aligned cleanly.
Regulatory convergence is forcing identity teams to collapse onboarding, AML, and access governance into one programme. EUDI Wallet support is being driven by digital identity, AML, and payments rules at the same time, which means identity teams cannot treat onboarding and authentication as separate policy tracks. The practical consequence is that banks need one governance model for evidence, assurance, and user authentication across multiple regulatory obligations.
Control provenance for wallet-based authentication: banks must be able to show which part of the authentication chain they own, which part they verify, and which part they merely rely on. That distinction is becoming central to auditability, dispute handling, and third-party risk management. Teams that cannot separate those roles will struggle to prove compliance when wallet-mediated fraud or assurance disputes arise.
The 24 December 2027 deadline is a programme trigger, not a policy footnote. Deadlines create operational sequencing pressure, and here the sequencing spans product, risk, legal, and vendor management teams. The organisations that wait for final clarifications will have less time to reconcile authentication design with liability, outsourcing, and customer journey changes. Practitioners should use the deadline to force cross-functional decisions now.
What this signals
EUDI Wallet support is becoming a cross-domain governance problem. Banks will have to align identity proofing, customer authentication, fraud management, and outsourcing oversight in one operating model. That is a programme design issue, not a narrow channel integration task.
Assurance ownership is the concept to watch. When a credential is issued and held outside the bank, the institution still has to prove why its authentication decision is trustworthy. That pushes teams toward clearer control provenance, stronger vendor contracts, and tighter risk acceptance.
The deadline pressure is likely to expose differences between banks that treat digital identity as a compliance checklist and banks that treat it as an architecture decision. The latter will be better placed to absorb wallet-mediated authentication without creating new audit or liability blind spots.
For practitioners
- Map the wallet trust boundary Document where the bank makes the authentication decision, where the wallet issuer contributes assurance, and where a third party is merely relied upon. Use that map to separate native control from external dependence.
- Align onboarding and authentication governance Unify KYC, strong customer authentication, and fraud-risk governance so the same programme owns evidence, assurance levels, and customer journey design across wallet and non-wallet paths.
- Review outsourcing assumptions Test whether wallet support truly creates an outsourcing relationship under your interpretation of the PSR draft, or whether the bank retains the authentication decision and only consumes externally issued assurance.
- Prepare liability positions now Define who is accountable if wallet-mediated authentication fails, including contract wording, operational escalation, and incident response roles before the final PSR text settles.
Key takeaways
- EUDI Wallets are changing European banking authentication by shifting part of the trust model outside the bank’s direct control.
- The article points to a 24 December 2027 support deadline, which makes governance, legal interpretation, and programme sequencing immediate priorities.
- Banks that do not clarify assurance ownership and liability before rollout risk creating an authentication model they cannot confidently audit or defend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | Wallet acceptance depends on federated identity trust and relying-party assurance. |
| Recommendation — Use federation controls to define how wallet assertions are trusted and verified by the relying party. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Banks must govern who can authenticate and under what assurance conditions. |
| Recommendation — Align wallet acceptance rules to entitlement and authorization policy for customer authentication. | ||
| GDPR | Art.32 — Security of processing | Wallet-mediated onboarding and authentication process personal data under a regulated security model. |
| Recommendation — Apply security of processing controls to the personal data carried through wallet-based authentication. | ||
| PCI DSS v4.0 | Strong authentication and account access control | Payment authentication obligations make this relevant where banks process cardholder environments. |
| Recommendation — Map wallet-based authentication to payment authentication and account-access requirements in card environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Wallet support changes how authenticators are issued, validated, and governed. |
| Recommendation — Review authenticator management controls to account for externally held wallet credentials. | ||
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.
- 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.
- 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.
- Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org