From Verification to Reusable Identity: Preparing for the EUDI Wallet and What Comes After

Key Takeaways:

• As part of Europe’s move from one-time verification to reusable identity, the EUDI Wallet will let EU citizens, residents, and businesses store and present verified credentials, including core identification data and electronic attestations such as driver’s licenses, diplomas, professional qualifications, and bank details.
• Under eIDAS 2.0, all 27 Member States must offer a certified wallet by December 24, 2026, while regulated private sectors must accept it as a form of verification to access an online service by December 24, 2027.
• The EUDI Wallet depends on PKI, HSMs, certificates, cryptographic keys, trusted lists, device binding, and revocation. These components establish who issued a credential, whether its signature can be trusted, and whether the signing keys themselves remain protected.
• The recommended strategy is to: support wallet verification alongside certified document and biometric verification; separately scope relying-party and issuer roles; prepare for certificate lifecycle management – with automated issuance, renewal, revocation, and distribution; examine supplier dependencies; and design security for long-term algorithm and key-management changes.

In the next year or so, Europe will be front and center of one of the biggest shifts to how we store, present, and manage our identity. For decades, identity, payments, and authentication were built as three separate systems to answer three separate questions: Who is this person, can they pay, and is it really them right now?

Today those answers come from different suppliers, sit under different regulators, and rest on different trust models. But in Europe, that’s all about to change. The introduction of the European Digital Identity Wallet (EUDI Wallet) combines all three into one shared trust infrastructure.

The operational case for this change – faster onboarding, lower abandonment, better fraud prevention, and more control for the user – is well acknowledged and well established. The harder question becomes: What has to be true underneath this system for it to hold and develop over time?

EUDI Wallet: What’s Changing?

Let’s start at the beginning – what is the EUDI Wallet? The Wallet is a government-backed mobile app that lets every EU citizen, resident, and business store and present verified credentials. These include:

• Person Identification Data (PID): The Wallet's core credential, issued by a PID Provider that the Member State (ie. the national government of the 27 European Union countries) has notified to the Commission. Everything else in the Wallet sits on top of it.
• Electronic attestations of attributes (EAAs): Driver’s licenses, diplomas, professional qualifications, and bank details.
• Qualified electronic attestations of attributes (QEAAs): The same attribute data as an EAA but issued by a qualified trust service provider under supervision and carrying legal effect equivalent to its paper counterpart across all 27 Member States.

The supporting technical layer ensures the Wallet is privacy-preserving and interoperable by design. This means that 1) wallet users share only the information actually needed in a specific moment (e.g. "I can confirm I am over 18") rather than a full credential, and 2) the Wallet can be used across all 27 EU Member States.

Sitting beneath all of this is the Architecture and Reference Framework (ARF), the technical blueprint that ties the specifications together. It sets out how credentials are issued and presented (OpenID4VCI and OpenID4VP), and two mandatory formats: ISO/IEC 18013-5 mdoc (in-person) and SD-JWT VC (online). Both support selective disclosure.

Two things are worth noting here. First, these are not European inventions. The same protocols and data models underpin mDL programs in the UK, Australia, and the U.S., so aligning to them opens more than one market. Second, while the ARF is guidance, and not law, it’s the primary authoritative blueprint for building the EUDI Wallet and is frequently updated. Version 3.0.0 for example, published July 2026, introduced some material changes for anyone who had already scoped their compliance work. Treating the ARF as a live document rather than a finished specification is the practical difference between a build that ages well and one that needs reworking before it launches.

EUDI Wallet: Why Now?

So why is this happening now? Well, document-based verification asks how confident we are that this document is genuine and this face matches. AI-generated forgeries and injection attacks have compressed that confidence faster than controls have improved.

Deepfakes now account for 1 in 5 biometric fraud attempts. injection attacks, where synthetic video is fed straight into the verification pipeline bypassing the camera altogether, surged 40% year over year.

A cryptographically issued credential changes the terms. It doesn’t simply assess for authenticity – it either verifies against the issuer's signature or it doesn't. The trust moves from “is this document genuine and how sure can we be?” to “who signed this, can that signature be checked, and how strong was the issuance and verification process that issued the credential into the wallet in the first place?”

The shift to wallets then isn't just convenience driven. It's a response to a control model that stopped scaling.

The EUDI Wallet Regulation, and Two Others That Matter (Quite a Lot)

Crucially, regulation writes the EUDI Wallet into law, and in three different places that increasingly point to one another.

eIDAS 2.0 (Regulation (EU) 2024/1183) amends the original eIDAS Regulation and creates the European Digital Identity Framework, the Wallet itself, and an expanded set of qualified trust services including qualified electronic archiving and QEAAs. This means all 27 EU countries must offer at least one certified wallet by December 24, 2026. And by December 24, 2027, regulated private sectors (banking and payments, healthcare, telecoms onboarding, and any sector where identity verification is already mandated) must accept the Wallet as a form of verification to access an online service.

The Anti-Money Laundering Regulation, or AMLR (Regulation (EU) 2024/1624) makes the Wallet a recognized way to verify identity. Applying from July 10, 2027, AMLR creates a single, directly applicable AML rulebook across all 27 Member States, replacing the patchwork of national frameworks under the AML Directives. Under Article 22, obliged entities may verify customer identity using electronic identification means meeting eIDAS requirements, alongside relevant qualified trust services.

The EBA's technical standards will specify how this works in practice for remote onboarding.

Finally, with the shift from PSD2 to PSD3, authentication stops being a separate system. PSD2 made Strong Customer Authentication (SCA) mandatory and cut card fraud, but standard authentication methods such as SMS one-time passcodes proved highly phishable through SIM-swap and social engineering. The regulatory shift will introduce PSD3, a directive covering authorization, supervision, and prudential requirements, and the Payment Services Regulation (PSR), a directly applicable rulebook fixing conduct rules across all 27 Member States. Both cleared the European Parliament's ECON committee in May 2026, with a 21-month application clock running from publication in the Official Journal, putting the effective date in 2028.

The sequencing matters. AMLR in July 2027, Wallet acceptance lands in December 2027, and the PSR regime follows shortly after. Taken together, these regulations change the landscape of identity across Europe. For 20+ years identity was an event verified at onboarding, then reassembled at every later moment in the lifecycle. The EUDI Wallet turns it into reusable identity. The same Wallet Unit that presents a PID at onboarding can later hold a bank-issued payment authentication attestation (an “SUA attestation”) that approves the payment, under the same trust framework, with the same cryptographic assurance. For organizations who need to verify and authenticate customers, this means they’ll stop rebuilding trust from scratch and start reusing what is already there.

The Trust Layer Underneath Everything

The EUDI Wallet isn’t several things bundled into one app. It's one trust framework (that used to require separate suppliers) serving multiple purposes:

• Proving who someone is: Via digital credentials issued and signed by a PID Provider, device-bound to the Wallet Unit's secure hardware (WSCD), with user binding confirming the presenter is the rightful user
• Letting them pay: Strong Customer Authentication performed directly from the Wallet, online and in store, across card and account-to-account
• Authenticating them again... and again: Via the credential, the trusted device, and the person combined, not via a passcode or SMS

All three depend on the same foundations: cryptographic keys, digital certificates, trust anchors published in Trusted Lists and Lists of Trusted Entities (LoTEs), device binding, and the regulation that gives each of them legal weight.

Public key infrastructure (PKIs) answers whose signature is this, and can I trust it? A relying party (aka, any natural or legal person, public service, or private organization that will use the EUDI Wallet to authenticate users, verify identity attributes, or request electronic attestations) doesn't check a credential against a database. Instead, it checks the signature against the issuer's certificate and verifies it against the issuer's trust anchor in the relevant Trusted List or LoTE, then checks revocation via a status list.

Hardware security modules (HSMs) answer the question underneath that one: Can anyone steal the key that made the signature? Private keys are generated inside certified hardware and never leave it, so signing happens in the device rather than on a server someone can reach.

Neither is new technology. But they are crucial to ensuring and maintaining the trust framework and everything that surrounds the EUDI Wallet ecosystem.

How the Trust Framework Actually Works

Getting the credential onto the phone in the first place
A PID has to come from an official source (a provider designated, authorized, or recognized by the Member State) in a standard format, protected by keys that cannot be copied. The eIDAS 2.0 implementing acts set out how this happens, using the protocols and formats described earlier. Once issued, the credential is bound cryptographically to that specific wallet and that specific holder, and the issuer carries responsibility for revoking it.

Proving it's that person, on that phone
The Wallet Secure Cryptographic Device holds private keys in certified hardware so they cannot be extracted or copied. Wallet Unit Attestation and Wallet Trust Evidence let a relying party confirm that the wallet presenting a credential is genuine, certified, and uncompromised rather than a clone. Holder binding ties the whole chain back to the individual.

Proving that the business asking for credentials is allowed to ask
This is the obligation some private-sector organizations might not have scoped yet. Before a wallet will release anything, a relying party must be registered in the national registry of every Member State where it's established.

The Relying Party Access Certificate (RPAC) authenticates the relying party during the transaction itself. It's bound to a specific relying party and a specific service. The Relying Party Registration Certificate (RPRC) does something different: It specifies which attributes a relying party is actually entitled to request. One registration certificate per service and intended use, plus an access certificate per system per service.

RPRCs are why the workload multiplies. A bank established in both France and Spain, running retail banking and wealth management, with two intended uses in each, is already at eight registration certificates, before adding a market, a product line, or a use case.

With acceptance obligations landing in December 2027 and many Member States yet to finalize their registration process, this is the likely bottleneck.

Handling change over time
Credentials expire, and so do certificates. People replace phones, lose them, and cross borders. The registration matrix isn't a one-time process – it's something that needs ongoing operations, with renewals falling across every service, intended use, and market.

Manual handling might be workable at two certificates but will be unmanageable at 20. Assume automated issuance, renewal, revocation, and distribution from the outset, because retrofitting it once the matrix has grown is considerably harder.

Where Fragmentation Shows Up

A bank that verified a customer through one vendor at onboarding, authenticates them through a second at login, and takes payment through a third will be left stitching together the individual components, where the EUDI Wallet is intended to do the opposite.

Splitting the chain means:

• No single answer to "who vouched for this person?"
• Evidence stitched together by hand every time a regulator asks
• A compromised credential that can't be revoked everywhere at once
• A rollout whose pace is set by your slowest supplier

Where Entrust Sits

Most vendors operate in one layer of this ecosystem: verification, trust services, wallet infrastructure, authentication, or payments. Entrust operates across several, from identity verification and credential issuance through to certificates, key protection and digital signing.

Payment and identity credentials run on the same machinery – and we support both: Banks already push cards into wallets and tokenize them at scale. Provisioning an identity credential works the same way: same binding, same lifecycle, same revocation problem, different payload.

A first-party root of trust: When your trust chain is assembled across multiple dependencies, who owns the root? Audits will question: Who controls the signing keys, how is access to them governed, and who can evidence that? These are hardware and access-governance questions, answered with certification levels, key ceremony records, and access logs. Accountability gets harder to demonstrate the more hands the root passes through.

HSMs and PKIs are part of Entrust's core business. The root of trust and the credential lifecycle above it sit with the same provider, which means one answer to the key-control question and one audit trail supporting it.

Both sides of the wallet: A bank is both a relying party at onboarding and an issuer of credentials into the wallet. Being credibly on both sides means being able to say what the dual role actually costs.

What to do in the Next 12 Months

1. Work out which side of the wallet you're on (it's probably both): Most regulated institutions will both accept credentials and issue their own. A bank is a relying party at onboarding and an issuer of attestations afterwards. The two roles have different obligations, different certificates, and different costs. Scope them separately, then check whether one supplier can serve both.
2. Plan for registration certificate lifecycle, not certificate issuance: You must register in every Member State where you're established, register each service, map every intended use to a service, and hold a separate registration certificate for each combination. One bank operating retail banking and wealth management across two markets is already looking at eight certificates. Look for partners who are building a scalable process that can adapt and help you manage RPRC management over time, not just on day one.
3. Count how many suppliers sit between your customer and your evidence: This matters most in the cryptographic layer. Key protection and PKI are what a regulator will eventually ask about. Accountability is easier to demonstrate the fewer hands it passes through.
4. Design for uneven wallet rollouts: Wallet availability is likely to be uneven and staggered. Today, Denmark, France, and Germany have the most developed sandbox and early-access environments. France Identité has over 4.5 million users but is not yet a certified Wallet Solution. Italy's IT-Wallet has been live with citizens since December 2024 and has passed 12 million activations, though certification and EUDI interoperability work continues. And Germany has signaled a January 2027 launch. And while regulated businesses must legally accept them, end-users aren’t required to. The next few years will determine what adoption looks like. As a result, businesses should plan to build certified document and biometric verification and wallet-based verification as parallel routes into the same flow to continue converting users without an EUDI Wallet.
5. Decide now how you'll keep security current: Anything issued in 2027 you'll still be answering for in the 2030s. Key management, algorithm agility, and revocation architecture all have to be designed in at the start – they're difficult and expensive to patch later.

Looking Ahead: Where Could This Go Next?

Europe first, but not necessarily Europe only. The EU has history as a first mover whose rules become the default well beyond its borders. GDPR, for example, reshaped privacy practice globally long before other regions legislated. Digital identity looks likely to follow the same pattern. The underlying standards are already international: the UK, Australia, and the U.S. are running mDL programs on the same data models and protocols. Organizations building for the EUDI Wallet today are, in practice, building for whatever the UK, APAC, and North America land on next.

Software will need identity, too? If AI agents start booking, paying, and signing on someone's behalf, they need issued, revocable credentials that state what they are permitted to do and on whose authority. The same infrastructure that binds a credential to a person could also bind a credential to an agent.

Anything issued now is a decade-long promise. Individual credentials are short-lived and reissued – the long-dated promise sits in the signing keys, trust anchors, and certificate chains behind them. Rotating keys, migrating algorithms, and reissuing down a certificate chain are all operations at the PKI and HSM layer. Factor this in at the start, as it is difficult and expensive to patch later.

See How Entrust Can Help

As the EUDI Wallet ecosystem takes shape, organizations need more than a moment-in-time point solution. Whether you're preparing for identity verification, digital signing, PKI, HSMs, or the broader trust framework behind reusable identity, Entrust can help you build a secure, scalable foundation for what's next.