TL;DR: By the end of 2026, every EU member state has to give its citizens an EUDI wallet, a free app that holds a verified digital identity and other credentials and shares only what the user wants to share. By the end of 2027, companies in regulated sectors like banking and telecoms have to accept it. If you already run a customer identity platform (CIAM), don’t think of the wallet as a replacement. Think of it as the piece that finally tells you whether the data in your CIAM is true. At Yameveo we’re working out how to connect the two.
What is the EUDI wallet?
Today, when a bank wants to know who you are, you hold your ID card up to the webcam, take a selfie and hope the photo is sharp enough. With the wallet, the bank asks your phone instead, and gets back data your government has signed. That basic identity is called the PID (person identification data) and it’s your name, date and place of birth, and nationality. Other organisations can add their own credentials next to it, so a university could put your degree in there, or a professional body your licence to practise.
When a website or an app asks for data, the wallet shows you who’s asking and what they want, and you decide what to do. Regulation (EU) 2024/1183 is quite specific about selective disclosure, so you can share only what a site actually needs without handing over the rest of your personal data. Most importantly, the wallet keeps a record of who you’ve shared information with, so you can ask a company to erase your data or report it to your data protection authority.
Why the EUDI wallet matters now
Because under eIDAS 2.0, every member state must offer at least one wallet by the end of 2026, and by the end of 2027 companies in sectors like banking, telecommunications, transport, energy and health must accept it when a user chooses it, wherever the law or a contract requires strong user authentication. Micro and small enterprises are exempt.
Most retailers and consumer brands aren’t on that list. For them the wallet is a choice, and honestly, that’s the part I find most interesting. Nobody’s forcing them to adopt it, but the ones that do will probably see the difference in their costs: fewer fake and ghost accounts, faster and more secure account recovery, fewer incidents and less work for support. And all of that should end up as more purchases and less costs to make them happen.
What the wallet brings to a CIAM
A CIAM usually knows a lot about its users: emails, consents, preferences, login history. What it doesn’t know is whether any of that is actually true. The name is typed in, the birth date is self-declared, and the email only proves that someone can read that inbox.
The wallet adds proof without asking the CIAM to give anything up. The CIAM keeps the accounts, the sessions and the consent records, and the wallet answers one specific question: is the person behind this account really who they say they are?
At registration, you get an account that starts out verified, with fields filled from verified data instead of typed by hand. In account recovery, a user who has lost both their password and their phone can prove who they are instead of opening a support ticket. For step-up, you get a verified check before sensitive changes, like a new email address or payout account. And for attributes, you can confirm things like “over 18”, “licensed pharmacist” or “lives in this country” without ever collecting the documents behind them.
I wouldn’t use it for everyday login, though. Passkeys (or other solutions) are much lighter for that. The wallet is for the moments when you need to know the person, not just recognise them.
Retail and consumer brands
Consumer brands often run lots of sites across lots of markets on a single identity platform: brand sites, loyalty programmes, promotions, free samples, newsletters, each with its own consents. In the CIAM projects I’ve worked on, the same problems kept coming back.
Promotions and free samples attract fake and duplicate accounts, and an offer reserved for wallet-verified accounts is much harder to farm. Age-restricted products rely on a birth date the user typed in. With the wallet, the user simply proves they’re over the age limit, and the brand never has to store the birth date at all. Then there’s loyalty. Points are worth stealing, and account recovery is where attackers push hardest. Talking your way through a wallet-based recovery is a lot harder than talking your way past a support agent.
Pharma
In pharma, the wallet is useful for two groups: healthcare professionals and patients.
Verifying that someone really is a licensed doctor or pharmacist is quite complicated today. It takes several steps, many of them manual: checks against national registries, third-party services and manual reviews, different in every country and kept in sync across several systems that don’t always talk to each other well. Integrations break, and the delays have real consequences, like doctors who can’t access patient data when they need it. eIDAS 2.0 lists professional qualifications, titles and licences among the attributes that member states must make verifiable against authentic sources. Once professional bodies issue them as wallet attestations, all of that becomes a scan at registration, and the rest is an integration that can work flawlessly if it’s built correctly.
Patient support programmes and health apps handle special-category data under GDPR Article 9, so before anything is shared you want to be sure the person enrolling is who they say they are. A wallet-verified enrolment gives you that, and a consent form could even be signed with the wallet’s qualified electronic signature instead of a ticked box.
The integration problems we’re working on
At Yameveo we’re looking into the integration challenges between the wallet and existing CIAM products, the same platforms I’ve spent the last seven years working on. These are the issues that look most important so far.
First, there’s a protocol gap. The wallet uses OpenID for Verifiable Presentations (OpenID4VP), with credentials in SD-JWT VC or ISO mdoc format. Most likely, something will have to sit in the middle between the CIAM and the wallet.
Then there’s the PID, which carries no guaranteed stable identifier. Names and birth dates aren’t unique, and the optional personal administrative number depends on the member state. Linking a wallet to the right existing account is a design decision, and it’s heavily dictated by the domain and the workflows each company uses.
There’s also what to keep. The CIAM should record that a verification happened, when and how, rather than the identity data itself. If some data does need to be stored, the less the better (again, a design choice).
Every relying party has to register and declare which data it will request (Article 5b), and that’s something to plan well before anyone writes code.
Finally, there’s the flow on screen. Scanning a QR code from a laptop is the easiest flow to demo, but a QR code can easily be forwarded to a victim. Same-device flows and the browser’s Digital Credentials API point to a safer path.
If you run a CIAM and want to know what the wallet means for your registration, login and recovery flows, that’s exactly what our EUDI wallet readiness assessment is for.
And AI?
There’s one more thing worth mentioning. AI agents are starting to search, book and buy things on people’s behalf, and sooner or later they’ll show up at your login page. Judging by the products the major companies in the sector have released recently, that’s inevitable. A CIAM will need to know which person an agent is acting for and what it’s allowed to do. At the same time, AI is making fake ID photos and faces cheaper to produce, which puts real pressure on document-and-selfie onboarding. A credential signed by a member state can’t be generated by a model. Verified identity might turn out to be the anchor that AI-driven services need. More on that soon.