EUDI wallet pilots shift digital identity governance in Europe

At a glance

What this is: OneSpan’s post says EUDI wallet large-scale pilots are now testing how digital identity will work in banking and other regulated journeys under eIDAS 2.0.

Why it matters: This matters because IAM, IGA, and PAM teams will need to align customer identity, authentication, and assurance policies to a wallet-based model that changes how trust is asserted and accepted.

By the numbers:

• By the end of 2027, regulated industries like banking must be ready to accept the EUDI wallet.

👉 Read OneSpan's analysis of EUDI wallet pilots and regulated identity acceptance

Context

EUDI wallet pilots are a testing ground for a new identity acceptance model, not just a new user experience. The core governance issue is how regulated organisations will validate possession, assurance, and attribute sharing when identity evidence is carried in a wallet rather than assembled across separate onboarding and authentication steps.

For IAM teams, the shift matters because customer due diligence and strong customer authentication start to converge into a single wallet-mediated flow. That affects policy design, fraud controls, auditability, and consent handling across banking and adjacent regulated services.

OneSpan’s role is best read as participation in a standards-and-interoperability exercise, not as the subject of the post. The broader question is whether the EUDI wallet can satisfy regulated acceptance requirements without creating fragmented exceptions across countries and sectors.

Key questions

Q: How should banks prepare for EUDI wallet acceptance in regulated journeys?

A: Banks should classify which journeys can rely on wallet-presented evidence and which still require additional verification. The key is to tie wallet acceptance to transaction risk, assurance level, and audit requirements before production use. That avoids treating the wallet as a universal replacement for identity controls and keeps compliance decisions explicit.

Q: What breaks if an EUDI wallet is treated like a generic login method?

A: What breaks is the distinction between authentication, identity proofing, and transaction authorisation. A wallet can carry all three signals, but regulated environments still need to know which signal is being trusted at each decision point. Without that separation, organisations risk over-accepting low-assurance presentations in high-risk workflows.

Q: When should organisations require step-up verification instead of wallet-only trust?

A: Organisations should require step-up verification when the transaction has high fraud impact, higher regulatory scrutiny, or a weak assurance chain from issuer to relying party. Wallet-only trust is strongest when the attribute, the device, and the presentation context are all validated. If any of those are unclear, step-up is the safer control.

Q: Who is accountable when wallet-based customer due diligence fails?

A: Accountability usually sits with the relying party that accepted the wallet evidence, but it is shared with the issuer, the wallet ecosystem, and the control owner who defined acceptance policy. Teams should pre-assign responsibility for assurance, revocation, logging, and exception handling so incidents do not become governance gaps after the fact.

Technical breakdown

EUDI wallet trust model in regulated identity journeys

The EUDI wallet is intended to let a person present verified identity attributes and authentication evidence from a controlled digital container. In practice, that changes the trust chain: relying parties must trust the wallet issuer, the credential provenance, and the assurance level of the presentation flow. For banking, this is not just a login problem. It affects onboarding, customer due diligence, and payment authorisation because the same wallet can carry identity claims into multiple decision points. The architectural question is whether the wallet becomes the primary proof source or only one element in a broader federation and risk-based decision model.

Practical implication: Map which transactions can accept wallet-presented evidence as primary proof and which still need step-up verification.

Strong customer authentication and possession factors

The article ties the pilots to strong customer authentication, which means the wallet is being evaluated as a possession factor in regulated transactions. That matters because possession alone does not equal trust unless device binding, credential protection, and replay resistance are strong enough for the use case. In payment and banking contexts, the control challenge is to preserve assurance while reducing friction. The wallet therefore sits at the intersection of authentication, transaction signing, and liability allocation, where even small design choices can alter compliance outcomes.

Practical implication: Validate whether the wallet satisfies possession-factor expectations for the exact transaction class, not just for generic sign-in.

Cross-border interoperability and attribute sharing

Large-scale pilots exist because wallet success depends on interoperability across public and private relying parties. The technical problem is not merely exchanging data, but preserving semantics, trust, and consent across borders, sectors, and identity providers. Different relying parties may need different attributes, confidence levels, and disclosure rules, so the wallet architecture must support selective sharing without creating brittle one-off integrations. If that layer fails, the programme becomes a collection of local exceptions rather than a scalable identity fabric.

Practical implication: Test attribute release, consent logging, and relying-party interoperability before building production onboarding or authentication dependencies.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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 programmes are a governance test for regulated identity acceptance, not a branding exercise. The significance is that banks and other regulated institutions are being asked to accept a new presentation model for customer identity evidence while preserving assurance, auditability, and fraud resistance. That forces IAM leaders to decide which controls move from pre-authentication into the wallet trust layer and which remain in the relying party. The practical conclusion is that acceptance policy must be designed before production rollout, not after.

Wallet-based identity shifts the boundary between authentication and evidence sharing. In a traditional IAM model, customer identity proofing, authentication, and transaction approval are separated across systems and checkpoints. A wallet compresses those steps, which can reduce friction but also concentrates risk if a single presentation flow is over-trusted. That makes federation policy, transaction context, and step-up logic the real control surface. Practitioners should treat wallet integration as an identity architecture decision, not just a front-end change.

Cross-border wallet interoperability will expose the weakest local policy, not the strongest pilot design. Large-scale pilots often look coherent in controlled conditions, but production acceptance depends on how many exceptions institutions are willing to carry across markets. If attribute semantics, assurance levels, or consent records do not align, the burden shifts back to the relying party. That is where governance maturity shows. The practical conclusion is that teams need a clear exception model before they depend on wallet claims at scale.

Payment and banking use cases make the wallet a regulated access control issue, not only a digital identity convenience. When the same wallet can support onboarding, SCA, and transaction approval, it begins to influence entitlement decisions as well as authentication events. That brings the wallet into the governance scope normally reserved for IAM, fraud, and compliance teams together. The practical conclusion is that identity architecture, risk teams, and audit stakeholders should evaluate wallet acceptance as one control family, not three separate projects.

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 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap is why teams should also review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs before they depend on new acceptance flows.

What this signals

EUDI wallet adoption will not reduce governance work, it will relocate it. IAM teams should expect more control decisions to move into acceptance policy, assurance mapping, and exception handling rather than disappear. In regulated environments, that makes the wallet a policy boundary as much as a presentation layer.

Wallet-mediated identity will expose programme maturity through consent, audit, and fallback design. If teams cannot explain when a wallet claim is enough, when it is not, and how exceptions are logged, they are not ready for scaled adoption. The most useful preparation is to define those decisions now, before partners and regulators force them into production.

Customer identity wallets also sharpen the lifecycle question for non-human identities. As relying parties extend wallet-based trust into backend services, API flows, and delegated transactions, the boundary between human authentication and machine access becomes easier to blur. For that reason, teams should revisit the Ultimate Guide to NHIs alongside any wallet pilot so the same governance model is not applied inconsistently across identity types.

For practitioners

• Define wallet acceptance policy by transaction type Separate low-risk identity presentation from high-risk regulated actions such as payment authorisation and customer due diligence. Document where wallet evidence is sufficient, where step-up is required, and where manual review still applies.
• Align assurance levels to relying-party decisions Map wallet attribute claims to the exact decisions they will drive, then verify that assurance, provenance, and revocation handling match the decision’s risk level.
• Build exception handling for cross-border differences Create a fallback process for markets, products, or partners that do not yet support the same attribute semantics or consent model. Avoid embedding one-off exceptions directly in authentication code.
• Coordinate IAM, fraud, and compliance early Treat EUDI wallet adoption as a shared governance change, with clear ownership for authentication policy, customer due diligence, and audit evidence retention.

Key takeaways

• EUDI wallet pilots are testing whether regulated identity evidence can move into a wallet without weakening assurance or auditability.
• The main governance challenge is not the wallet itself, but the acceptance policy that decides when wallet-based trust is sufficient.
• IAM teams should treat wallet adoption as a cross-functional control design problem spanning authentication, due diligence, and exception handling.

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: Strong customer authentication is a regulated authentication approach that requires at least two independent factors from different categories. In wallet-based identity flows, the wallet may serve as the possession factor, but the institution still has to prove the overall assurance of the transaction.
• 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.
• Relying Party: A relying party is the organisation that accepts identity evidence from another source and makes an access or business decision on that basis. In wallet ecosystems, the relying party must define acceptance rules, assurance thresholds, and fallback paths for incomplete or low-confidence presentations.

Deepen your knowledge

EUDI wallet acceptance and assurance mapping are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are preparing regulated identity journeys for wallet-based trust, it is worth exploring.

This post draws on content published by OneSpan: OneSpan joins digital identity wallet pilots with WE BUILD and Aptitude Authentication. Read the original.