Every EU member state owes citizens a wallet by December 2026

Regulation (EU) 2024/1183 entered into force on 20 May 2024. It requires every member state to make at least one European Digital Identity Wallet available, free of charge, within 24 months of the implementing acts for the wallet's core rules taking effect. The first implementing regulations were published on 4 December 2024 and entered into force on 24 December 2024, which anchors national availability to 24 December 2026.

That is under four months away. Most coverage frames it as a public sector delivery deadline, which it is. It also starts the clock for a large category of private companies, which must accept the wallet by 24 December 2027 and mostly have not scoped the work.

What the regulation actually requires

The wallet holds a Person Identification Dataset issued by the member state, plus electronic attestations of attributes: driving licences, diplomas, professional qualifications, bank account details. It must work cross-border, which is why the implementing acts specify common protocols and interfaces rather than leaving each state to build its own thing. Technically that means OpenID4VP and OpenID4VCI for presentation and issuance, SD-JWT and mdoc credential formats, and selective disclosure so a holder can prove they are over 18 without revealing a birth date.

This is the largest deployment of decentralized identity infrastructure that has ever been attempted, and it is happening on a legal deadline rather than a product roadmap. The Architecture and Reference Framework is the specification that ties it together.

Member state readiness is uneven. Germany adopted a cabinet draft of its Digital Identity Act on 20 May 2026. Others are further behind. Expect several states to ship a minimum-viable wallet in December and iterate through 2027.

The part that catches private companies

Two obligations reach beyond government.

Acceptance. Where law or contract requires strong user authentication for an online service, private relying parties must accept the wallet when a user chooses to present it, no later than 36 months after the implementing acts entered into force: 24 December 2027 (Article 5f). The regulation names transport, energy, banking and financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications, so banking and payments under PSD2 strong customer authentication are squarely in scope. Micro and small enterprises are exempt. If you operate a regulated online service in the EU and your login stack has no wallet path, that is a gap with a date on it.

Registration. A relying party that wants to request attributes from a wallet has to register with a member state and declare which attributes it intends to request. This is the sleeper provision. It converts "what data do we collect at signup" from a product decision into a filed declaration, and it makes over-collection visible to a regulator rather than buried in a privacy policy.

Very large online platforms designated under the Digital Services Act must also accept the wallet where they require users to authenticate, at the user's request and for the minimum data the service needs.

What this changes about identity architecture

The wallet model inverts the assumption most CIAM stacks are built on. Today the relying party asks an identity provider about a user, and the IdP answers, which means the IdP sees every relying party the user visits. In the wallet model the holder presents a credential the issuer signed earlier, and the issuer is not in the loop at presentation time. That is the issuer, holder, verifier triangle, and it removes the phone-home.

For a verifier, three things change concretely:

• You validate a signature and a revocation status, not a session. There is no redirect to an IdP, no OIDC authorization code, and no federation agreement with the issuer. You need the issuer's trust anchor and a way to check a revocation registry.
• You get less data, deliberately. Selective disclosure means asking for an over-18 proof gets you a boolean. Systems that assumed a full profile at authentication time need rework.
• You still need an account. A wallet presentation proves an attribute at a moment. It is not a session, not a customer record, and not a substitute for your own account lifecycle. Teams that expect the wallet to replace CIAM will be disappointed; it replaces the identity verification step at the front of it.

What to do in the next four months

If you operate a regulated service in the EU:

1. Determine whether your sector's national law triggers the acceptance obligation. This is a legal question, not an engineering one, and it varies by member state.
2. Start the relying-party registration conversation with your primary member state now. Registration requires declaring intended attributes, which requires knowing them.
3. Prototype an OpenID4VP verifier against a reference wallet. The protocol is stable enough to build against, and the integration surface is small compared to the process work.
4. Audit what you collect at onboarding against what you could request as a selective disclosure. Most signup flows collect a full identity document to check one attribute.

If you do not operate in the EU, this still matters, because the ARF is becoming the de facto reference for national wallet programs elsewhere. Our digital IDs directory tracks 86 schemes across 51 countries, and the credential formats are converging.

Related reading

• eIDAS 2.0 and the EU Digital Identity Wallet
• Verifiable credentials
• Identity regulations by country
• Reusable identity and KYC with verifiable credentials