eIDAS 2.0 — Regulation (EU) 2024/1183 — obliges every member state to provide its citizens with an EU Digital Identity Wallet, and the deadline lands at the end of this year. The large-scale pilots have run their course, the Architecture and Reference Framework has gone through repeated iterations, and national wallet programs are moving from prototypes to certification. For most engineering teams this still feels like government-project background noise. It should not: the regulation also creates acceptance obligations for the private sector, and the integration work is concrete, protocol-level, and better started before it is compulsory.
The short version: within the next couple of years, a meaningful share of your EU users will be able to prove who they are — and specific attributes about themselves — from a state-backed wallet on their phone, with selective disclosure built in. Sectors subject to strong customer authentication or legal identification duties, and very large online platforms offering login, will be required to accept it.
What the wallet actually holds
Three things matter. Person identification data (PID) is the state-issued core identity. Qualified electronic attestations of attributes (QEAAs) carry facts like professional licenses, diplomas, or company mandates, issued by qualified trust service providers, with non-qualified attestations (EAAs) alongside for lower-stakes claims. And wallet users get qualified electronic signatures free of charge for non-professional use, which quietly disrupts the paid e-signature market. Trust flows from national trusted lists and mandatory wallet certification, not from bilateral agreements between companies.
The protocol stack is settling
The ARF anchors the wallet ecosystem on standards your team can prototype against today:
- ▸OpenID4VCI: the issuance flow, by which issuers deliver credentials into wallets.
- ▸OpenID4VP: the presentation flow, by which your service — the relying party — requests and receives proofs.
- ▸SD-JWT VC and ISO/IEC 18013-5 mdoc: the credential formats, both supporting selective disclosure so a user can reveal an over-18 claim without revealing a birthdate.
- ▸Remote and proximity flows: QR codes and deep links for web, NFC and BLE for in-person verification.
Expect version churn — the ARF is a living document — but the direction is stable enough that a verifier built against the EUDI reference implementation today will not be wasted work.
Who must accept it, and who should anyway
The regulation names the sectors: banking and financial services, telecoms, transport, energy, health, and other areas where strong user identification is legally required, plus very large online platforms for user authentication. But the voluntary case is often stronger than the legal one. Wallet-based verification collapses KYC onboarding costs, enables age verification without hoarding birthdates, and removes signup friction for exactly the flows where drop-off hurts most. Fintechs and marketplaces that treat wallet acceptance as a conversion feature will move earlier than their compliance departments would have forced them to.
Data minimization stops being a slogan
Selective disclosure changes the engineering default. Relying parties register in each member state and declare what data they intend to request; over-asking becomes visible, logged, and sanctionable rather than merely impolite. That pushes a real design shift: build authorization around attributes — over-18, resident-of, licensed-as — instead of around a full identity record you then have to protect under GDPR. Less data ingested means less data breached, and the wallet model finally aligns the incentive with the principle.
A readiness roadmap that fits the remainder of 2026:
1. Map every flow that today demands an ID document upload, a video-identification session, or a password — these are your candidate integrations. 2. Stand up an OpenID4VP verifier in staging against the EUDI reference wallet implementation. 3. Define the minimal attribute set per flow and design authorization around attributes, not identity dumps. 4. Plan for trusted-list validation and relying-party registration in each member state you serve. 5. Keep fallback paths alive — wallet adoption will be uneven across countries and demographics for years.
The forward-looking calculus favors early movers. Wallet acceptance arrives as a compliance obligation for some and a competitive edge for everyone: faster onboarding, cheaper KYC, smaller breach surface, and a GDPR story that writes itself. Teams that integrate while the ecosystem is young will shape their flows around it deliberately; teams that wait for enforcement will retrofit under deadline pressure, and retrofit identity is never the good kind.
