eIDAS 2 and the EUDI Wallet: What Product Teams Need to Know Now

The deadline is closer than your roadmap thinks

I have sat in enough digital transformation programmes to recognise a pattern: teams treat regulatory deadlines as someone else's problem until they are six months away and suddenly it is a crisis. eIDAS 2 is following exactly that pattern across Europe right now.

The revised eIDAS regulation was published in the Official Journal in April 2024. Member States have until 2026 to make the European Digital Identity Wallet available to citizens who want one. Large-scale pilots are already running. Wallet providers, identity schemes, and relying parties are making architectural decisions today that will be very expensive to undo later.

If your product touches authentication, identity verification, credential sharing, or any kind of onboarding for EU users, this is not a future concern. It is a present one. And unlike a lot of EU regulation, eIDAS 2 is not just a compliance checkbox — it fundamentally changes how identity works across the continent.

What eIDAS 2 actually changes

The original eIDAS regulation from 2014 created a framework for cross-border recognition of national electronic identity schemes. It worked, technically. But adoption was patchy, the user experience was often painful, and private-sector relying parties had almost no reason to participate. The wallet changes all of that.

The EUDI Wallet is a mobile application — issued or certified by each Member State — that allows citizens to store and selectively disclose verified attributes. Not just their identity, but also qualifications, driving licences, professional credentials, payment instruments, and eventually much more. The key architectural principle is selective disclosure: you prove what needs to be proved without revealing everything else.

This is a genuine shift from how most identity systems work today. When you verify a user's age on a platform right now, you typically get their full date of birth, often their name, sometimes their address. With a wallet and a well-designed credential, you get a cryptographic proof that the person is over 18. Nothing more. That is not just better privacy — it changes your data model, your consent flows, your GDPR exposure, and your liability.

A few things that product teams often miss when they first read the regulation:

• Relying parties have obligations too. If you are a service that accepts wallet credentials, you need to register, you need to meet technical requirements, and you cannot request more attributes than you actually need. The proportionality principle from GDPR is baked directly into the wallet architecture.
• The reference architecture is not optional. The Architecture and Reference Framework (ARF) published by the European Commission defines the protocols, data models, and trust infrastructure. You do not get to design your own. That is a feature, not a limitation — interoperability across 27 countries depends on it.
• PID is the foundation. The Person Identification Data credential is the core building block. Everything else — qualified electronic attestations of attributes, or QEAAs — sits on top of it. Understanding the trust chain from issuer to wallet to relying party is essential before you design anything.
• The pilots are producing real learnings. The four large-scale pilots (POTENTIAL, EWC, DC4EU, and NOBID) have been running since 2023 across dozens of countries and use cases. Their interim findings are public. Reading them is worth more than reading the regulation a second time.

Where the real complexity lives for product teams

The regulation is reasonably clear. The implementation is where it gets hard, and I want to be direct about the three areas that I think will cause the most pain.

Protocol and standards maturity

The ARF specifies OpenID for Verifiable Credentials (OID4VC) and OpenID for Verifiable Presentations (OID4VP) as the core protocols, with SD-JWT and mdoc as the primary credential formats. These standards are real and implementable, but they are still evolving. The ISO 18013-5 standard for mdoc (the mobile driving licence format) is stable. The OID4VC family is more recent and some of the tooling is immature.

If you start building now, you will almost certainly have to update your implementation as the ARF goes through further revisions and as the implementing acts fill in the gaps. That is not a reason to wait — it is a reason to build with abstraction layers and avoid coupling your business logic to specific protocol details. I learned this lesson building CVChatly with LLM APIs that changed behaviour between versions. The principle is identical: isolate the volatile parts.

Trust infrastructure and governance

The wallet system depends on a trust model: issuers are trusted because they appear in a Member State's trusted issuer list, which feeds into a European-level trust framework. Relying parties are registered. Wallet providers are certified. This is a public key infrastructure problem at continental scale, and it introduces operational dependencies that most product teams have never had to think about.

What happens if a trusted issuer's certificate is revoked? What happens if a user's wallet is lost or stolen and credentials need to be invalidated? What is your fallback if the trust infrastructure is temporarily unavailable? These are not hypothetical edge cases — they are design questions you need to answer before you go to production. The regulation gives you the framework. It does not give you the answers.

UX and accessibility

I will be honest: the wallet interaction flows described in the ARF are technically correct and user-experience challenging. Scanning a QR code, switching to a wallet app, approving a disclosure, switching back — that is four steps where today a user might type a password. For many users, especially those who are less digitally confident, that friction is a real barrier.

The regulation requires Member States to ensure the wallet is accessible. It does not tell you how to design a relying-party integration that does not make users give up halfway through. That is your problem to solve. Testing with real users early — not just with technically literate colleagues — is the only way to find where the flow breaks down.

What I would actually do if I were starting a new integration today

I am not going to tell you to wait for the specifications to stabilise. They will not be fully stable before the deadline, and waiting is itself a decision with consequences. Here is how I would approach it.

1. Map your identity touchpoints first. Before you look at any technical specification, list every place in your product where you collect, verify, or store identity-related data. Onboarding, age verification, professional credential checks, login, KYC flows — all of it. That list tells you where eIDAS 2 is relevant and where it is not.
2. Read the ARF, not just summaries of it. The Architecture and Reference Framework is long and technical, but it is the actual source of truth. Summaries, including this one, simplify. The ARF is where you find the details that matter for implementation decisions.
3. Follow one of the pilot programmes closely. The EWC pilot (European Wallet Consortium) has published technical outputs. The POTENTIAL pilot has use cases that are close to what many commercial products will need. Pick the one most relevant to your use case and track it.
4. Design for selective disclosure from day one. Even if you are not integrating a wallet yet, if you are building or rebuilding identity flows, design them around the principle of requesting only what you need. This will make your eventual wallet integration easier and your GDPR compliance stronger right now.
5. Talk to your legal and DPO teams before your engineering team. The questions about what attributes you are allowed to request, how you store them, and what your obligations are as a relying party are legal questions first and technical questions second. Getting the legal model wrong will cost you more than getting the protocol implementation wrong.

The practical takeaway

eIDAS 2 and the EUDI Wallet are not a distant regulatory horizon. The pilots are live, the ARF is published, and Member States are building. If your product serves EU users and involves any form of identity, the question is not whether this affects you — it is whether you are going to be ready when your users start showing up with a wallet expecting you to accept it.

The teams that will handle this well are the ones who start now with a clear-eyed understanding of what the regulation requires, a realistic assessment of where the standards are still maturing, and a product design philosophy that prioritises the minimum necessary data over convenience. That last part is not just good compliance practice. It is good product design.

Start with the map of your identity touchpoints. Everything else follows from there.