By December 2026, every EU Member State must offer at least one certified EU Digital Identity Wallet (EUDI Wallet) to its citizens and businesses. By December 2027, regulated relying parties — banks, insurers, telecoms, large online platforms, and public services — must accept it. That is not a distant horizon. It is eighteen months away, and the technical groundwork starts now.
If your web application serves EU users, handles identity verification, or sits in a regulated sector, the EUDI Wallet will touch your authentication stack, your user onboarding flow, and quite possibly your data architecture. Here is what development teams need to understand — and what to start building.
TL;DR
- The EU Digital Identity Wallet (EUDI) launches across all 27 Member States by late 2026, with mandatory acceptance for regulated sectors by December 2027
- eIDAS 2.0 requires web applications in banking, insurance, telecoms, and large platforms to accept EUDI Wallet credentials for identity verification
- Integration uses OpenID4VP (OpenID for Verifiable Presentations) and ISO/IEC 18013-5 — development teams should start prototyping against the open-source reference implementation now
- Relying party registration requires competent authority approval, which takes time — begin the process early
- This is not just a compliance checkbox; it is an opportunity to simplify onboarding, reduce KYC friction, and build trust with privacy-conscious European users
What Is the EUDI Wallet, and Why Should You Care?
The EUDI Wallet is a government-issued mobile application that lets EU citizens and businesses store, manage, and selectively share verified identity credentials. Think of it as a digital passport, driving licence, professional certification, and proof-of-age card — all in one app, all cryptographically verifiable, and all under the user’s control.
It is built on the revised eIDAS 2.0 regulation, which entered into force in May 2024. The regulation does not just create the wallet; it creates an entire trust framework. Issuers (governments, universities, employers) issue credentials. Holders (citizens) store them. Relying parties (your web application) request and verify them. Every participant is bound by common technical specifications and legal obligations.
This matters because it is not optional for regulated industries. If you are a bank running online onboarding, an insurer processing claims, a telecom activating SIM cards, or a large platform verifying age — you will need to accept the EUDI Wallet. And even if you are not in a regulated sector, voluntary adoption gives you access to verified identity data without the cost and friction of traditional KYC providers.
The Technical Architecture: What Development Teams Need to Know
The EUDI Wallet ecosystem rests on three pillars that your development team needs to understand:
1. Verifiable Credentials and Presentations
The wallet stores credentials as W3C Verifiable Credentials or in ISO/IEC 18013-5 format (the same standard behind mobile driving licences). When a user presents their identity to your application, they create a Verifiable Presentation — a cryptographically signed package that proves the credential is genuine, was issued to this holder, and has not been tampered with.
Crucially, the wallet supports selective disclosure. A user can prove they are over 18 without revealing their date of birth. They can prove they hold a valid professional certification without sharing their home address. This is a fundamental shift from the all-or-nothing approach of traditional identity verification, and your UX flows need to respect it.
2. OpenID4VP — The Integration Protocol
The primary protocol for requesting and receiving credentials from the EUDI Wallet is OpenID for Verifiable Presentations (OpenID4VP). If your team has worked with OpenID Connect, the mental model is similar — but instead of receiving an ID token from an identity provider, you receive a Verifiable Presentation directly from the user’s wallet.
The flow works like this: your application creates an authorisation request specifying which credentials it needs (for example, proof of identity plus proof of address). The wallet displays this request to the user, who approves or denies it. On approval, the wallet returns the Verifiable Presentation to your backend, where you validate the cryptographic proofs and extract the verified attributes.
The EU’s Architecture and Reference Framework (ARF) specifies exactly how this works, and the reference implementation is open source on GitHub. Your team should be reading it now.
3. Trust Registries and Relying Party Registration
You cannot simply start requesting credentials. To become a relying party, your organisation must register with a competent authority in your Member State. This registration process validates that you have a legitimate reason to request specific credential types, that you handle data in compliance with GDPR, and that your technical implementation meets the required standards.
This is not a rubber-stamp process. It takes time, requires documentation, and may involve technical audits. If you know your application will need to accept EUDI credentials, start the registration process as early as possible. Waiting until Q3 2027 and hoping to make the December deadline is a recipe for failure.
What Your Application Actually Needs to Change
Let us get practical. Here is what a typical web application integration looks like:
Authentication and Onboarding
Your login page needs a new option: “Sign in with EUDI Wallet.” This is conceptually similar to adding a “Sign in with Google” button, but the trust model is fundamentally different. Instead of trusting an identity provider, you are verifying cryptographic proofs issued by government-certified authorities.
For onboarding flows, this is where the real value appears. Instead of asking users to upload a photo of their passport, wait for manual review, and hope the OCR works — you request a verified Person Identification Data (PID) credential from their wallet. The verification is instant, the data is structured, and the trust chain is cryptographically provable. For businesses that currently spend significant sums on third-party KYC providers, this is a potential cost revolution.
Data Minimisation by Design
The EUDI Wallet enforces a principle that GDPR has always required but that many applications have ignored: you should only request the data you actually need. The wallet’s selective disclosure means users can see exactly what you are asking for and refuse anything they consider excessive.
This means your development team needs to think carefully about which attributes to request for each use case. Age verification? Request proof-of-age, not the full PID. Professional service access? Request the relevant certification, not the user’s entire identity. Getting this right is not just good privacy practice — it directly affects conversion rates. Users are far more likely to approve a request for one attribute than a request for everything.
Backend Credential Verification
Your backend needs a credential verification layer. This involves validating the cryptographic signatures on Verifiable Presentations, checking credential revocation status against issuer revocation lists, verifying the trust chain back to a recognised issuer in the EU trust registry, and extracting and mapping verified attributes to your user model.
This is not trivial, but it is well-defined. Libraries and SDKs are emerging across major languages, and the reference implementation provides a solid starting point. The key architectural decision is whether to build this verification in-house or use a managed identity verification service that supports EUDI — both approaches are valid depending on your team’s capacity and the sensitivity of your use case.
The Timeline That Matters
Here is the realistic timeline your team should be working to:
Now to Q3 2026: Study the Architecture and Reference Framework. Run the reference implementation locally. Prototype a basic credential request and verification flow in a development environment. Begin relying party pre-registration if your Member State’s competent authority is accepting applications.
Q4 2026: Member States begin issuing wallets. Real credentials become available for testing. Integrate OpenID4VP into your staging environment. Test with actual wallet applications from your target markets.
Q1–Q3 2027: Production hardening. Load testing. UX refinement based on real user feedback. Security audits of your verification pipeline. Accessibility compliance for wallet-based authentication flows.
December 2027: Mandatory acceptance deadline for regulated relying parties. Your integration must be live, tested, and compliant.
The Opportunity Beyond Compliance
It is easy to frame the EUDI Wallet as a compliance burden. That misses the point. For web applications that handle identity — and that is most applications of any sophistication — the wallet offers something genuinely valuable: verified, structured, user-controlled identity data with zero manual processing.
Consider the onboarding funnel. Every step where a user has to upload a document, wait for verification, or re-enter information they have already provided is a step where you lose conversions. The EUDI Wallet compresses that entire process into a single approval tap. For fintech applications, e-commerce platforms requiring age verification, professional services platforms, and government-facing services, the conversion impact could be significant.
There is also a trust advantage. In an era of deepfakes, synthetic identities, and increasingly sophisticated fraud, being able to verify that a user’s credentials were issued by a government authority and are cryptographically intact is a powerful signal. Early adopters who build clean, privacy-respecting EUDI integrations will have a genuine competitive edge.
Where to Start
If this feels overwhelming, start small. Clone the EU Digital Identity Wallet reference implementation and run it locally. Read the Architecture and Reference Framework documentation. Build a proof-of-concept that requests a single credential and verifies it. That alone will give your team the mental model they need to plan a production integration.
If your application is in a regulated sector, loop in your compliance team now. Relying party registration is a cross-functional effort, and the technical and legal workstreams need to run in parallel.
At REPTILEHAUS, we are already helping clients architect their EUDI Wallet integration strategies — from authentication flow design to backend credential verification pipelines. If your team is looking at this deadline and wondering where to start, get in touch. This is the kind of infrastructure work that pays dividends well beyond the compliance deadline.
📷 Photo by Dan Nelson on Unsplash
