The EU Digital Identity Wallet Lands in December 2026: How to Prepare

By 24 December 2026, every EU Member State has to make at least one European Digital Identity Wallet available to its citizens and residents. That is a legal obligation with a date, not a roadmap item.

A year later, in December 2027, a long list of organisations become legally obliged to accept it. Banks, transport operators, energy suppliers, health services, telecoms, postal services, education providers and digital infrastructure operators all sit on that list, along with anyone else already required to use strong user authentication.

For everyone else, acceptance is optional. It is still worth understanding, because the wallet solves several problems that companies currently spend real money on badly.

What the Wallet Actually Is

The European Digital Identity Wallet comes from the revised eIDAS Regulation, usually called eIDAS 2. It is a mobile application that holds verified identity attributes and credentials, issued by trusted parties, that a user can present selectively to whoever asks.

Three properties make it different from the identity systems most sites use today.

It is government-backed. The identity in the wallet is derived from a national electronic identity scheme. It is not a self-asserted profile.

It supports selective disclosure. A user can prove they are over eighteen without revealing their date of birth, or prove residence in a Member State without revealing their address. This is the part with the most practical consequence for product design.

It works across borders. A wallet issued in Slovenia has to be accepted by relying parties in Germany. That is the entire point of the regulation, and it is what national identity schemes have consistently failed to deliver.

Alongside citizen wallets, the Commission has proposed a European Business Wallet for legal persons, aimed at company representation, mandates and official document exchange between businesses and public authorities. That proposal came with the Digital Omnibus package in November 2025 and is moving through Parliament, with the rapporteur's draft report published in March 2026. It is further out, but if your product involves company identity, mandates or B2B document exchange, it is the file to watch.

Where Implementation Actually Stands

Readiness varies enormously by Member State, and it is worth being realistic about that.

Several countries have shipped national implementations ahead of the deadline. France has France Identité, Austria has eAusweise, Italy has IT-Wallet. Others are further behind, and some will meet the December 2026 deadline with a limited first version rather than the full feature set.

Member States can satisfy the obligation in three ways: build and issue a wallet themselves, mandate a third party to do it, or recognise a wallet built by the private sector. That means the ecosystem you integrate with will not be uniform, which is precisely why the interoperability specifications matter.

The Relying Party Role

If you want to accept wallet credentials, you become a relying party, and that is a registered role rather than an informal one.

The process, in outline:

1. Register with your national registrar. You declare which attributes you intend to request and for what purpose. This is a real check, not a form. You cannot register to request a citizen's full identity dataset because it might be useful someday.
2. Obtain relying party access certificates. These authenticate you to wallets and let users see who is asking.
3. Implement the presentation protocols. Request credentials, receive a presentation, verify it.
4. Verify cryptographically. Signature validation, trust chain validation against the EU trust list, revocation checking.
5. Request the minimum. Data minimisation is enforced structurally here. If you registered to check age, you can ask for an age assertion, not a birth date.

That last point deserves emphasis because it inverts the usual identity integration. In most systems you receive a payload and decide what to keep. Here you declare in advance what you may ask for, and the architecture stops you from over-collecting. It is a genuinely better model, and it means your data protection impact assessment for identity verification gets considerably shorter.

The Standards You Will Meet

The technical stack draws on several specifications, and if you are scoping work, these are the acronyms that will appear:

• ISO/IEC 18013-5, the mobile driving licence standard, which supplies the proximity presentation model and much of the credential format thinking.
• W3C Verifiable Credentials, for the credential data model.
• OpenID for Verifiable Presentations and OpenID for Verifiable Credential Issuance, for the request and issuance flows over the web.
• SD-JWT, for selective disclosure of individual claims.
• The EUDI Architecture and Reference Framework, published by the Commission, which is the document that ties all of it together and which you should read before estimating anything.

None of this is exotic if your team has worked with OpenID Connect. It is meaningfully different from a SAML or OIDC login integration though, because you are verifying credentials cryptographically rather than trusting an identity provider's session assertion.

Where the Wallet Solves a Real Problem

Compliance aside, there are several places where this is straightforwardly better than what exists today.

Age verification

This is the most immediate use case, and it is being pushed hard. The European Commission has been urging Member States to have age verification solutions in place by 31 December 2026, and has published an open-source age verification application as a bridge until wallets are widely available. The design goal is that a platform receives only an age token, a yes or no, without a date of birth or any other attribute.

If you operate anything with an age restriction, alcohol, gambling, adult content, certain financial products, or a platform subject to the Digital Services Act's minor protection expectations, this is the mechanism that lets you check age without building a database of scanned identity documents. That database is a liability you currently carry for no good reason.

Onboarding and KYC

Regulated onboarding today means document upload, liveness checks, manual review and a queue. A wallet presentation replaces that with a cryptographic verification that completes in seconds, with higher assurance and no document images to store.

For banks, insurers, crypto services and anyone else running KYC, the cost difference is significant. It also removes the single most sensitive dataset most companies hold.

Cross-border services

If you serve customers in several Member States, you currently maintain integrations with a patchwork of national identity schemes, or you give up and use document scanning everywhere. One wallet integration covers all of them.

Reduced form friction

Verified name, address and contact details presented in one action instead of typed into a form. That is a conversion improvement as well as a data quality improvement.

What to Do Now

The honest answer for most companies is: not much yet, but a few things are cheap and worth doing.

If you are an obliged relying party, with a December 2027 deadline, start now. Registration processes are new and slow, national implementations vary, and you will want to run a pilot in one market before committing. Twelve months is not generous for a regulated integration.

If you are not obliged but do age verification, look at this seriously in the next few quarters. Storing identity documents to check whether someone is eighteen is a poor trade, and there is now an alternative.

If you run KYC or identity verification, model the cost saving. Our experience is that the business case usually stands on its own, without any compliance argument.

If none of the above applies, do one thing: make sure your identity layer is abstracted. If your application code calls an authentication service rather than a specific vendor's SDK, adding wallet support later is a new adapter. If your login logic is scattered across controllers, it is a rewrite.

The Things That Will Go Wrong

Based on how these rollouts usually go, expect the following.

Uneven availability. Some Member States will launch with limited functionality. Build for the case where a user in one country has a fully featured wallet and a user in another does not, and keep your existing fallback path.

Slow user adoption. Availability is not usage. Even in countries with mature national eID schemes, penetration took years. Do not remove alternative flows.

Registration friction. National registrar processes are new. Allow more time than the documentation suggests.

Specification drift. The Architecture and Reference Framework has been revised repeatedly and will be revised again. Isolate protocol handling behind an interface so a specification update does not touch your business logic.

Where This Fits

The wallet is one of the more constructive pieces of the current EU digital agenda. Most of the rest imposes obligations. This one, once it works, removes a category of expensive and risky infrastructure that companies build today because they have no alternative.

Our 2026 EU digital compliance guide maps how it sits alongside the other deadlines, and the GDPR engineering guide covers the data protection layer that any identity work has to satisfy.

We build authentication and identity systems for companies operating in the EU, and we are working with relying party integrations now. If you want help scoping what wallet acceptance would take in your stack, or you have a December 2027 obligation and no plan, write to office@c9group.dev. There is more about our European work on the market entry page.