Who Must Accept the EUDI Wallet by December 2027?

Avatar
Author

The EUDI Wallet acceptance obligation names eleven sectors in Article 5f(2) of the eIDAS Regulation as amended: transport, [...]

But sitting in one of those sectors is not enough on its own. Two conditions must apply at the same time before the EUDI Wallet acceptance obligation reaches you: you must already be under a legal or contractual obligation to use strong user authentication for online identification, and you must not be a micro or small enterprise. So two companies in the same sector can reach opposite conclusions.

Both dates come from a single event. On 28 November 2024 the European Commission adopted the first five implementing acts under Regulation (EU) 2024/1183, and they entered into force on 24 December 2024 following publication in the Official Journal. The regulation counts its deadlines from that moment.

24 Dec 2024
The first five implementing acts enter into force
24 Dec 2026
Member states must make at least one wallet available. Public sector acceptance begins
24 Dec 2027
Private-sector acceptance obligation under Article 5f(2)
After that
Commission assesses demand, availability and usability within 24 months of deployment
December 2026 is when wallets exist. It is not when your organisation has to accept them.

Which sectors does the EUDI Wallet acceptance obligation name?

Eleven. The sector list is the easy part of the analysis and the part most coverage stops at. Where the obligation lands in practice differs by sector: account opening and payment authorisation in banking, onboarding and investor identification in financial services, ticketing in transport, customer accounts and supplier switching in energy, benefit access in social security, patient portals and prescription services in health, customer accounts in drinking water, registered delivery in postal services, administrative access in digital infrastructure, enrolment and credential issuance in education, and SIM registration and account recovery in telecommunications.

That mapping is our reading of where the requirement lands, not text from the regulation. The regulation names the sectors and the trigger, and leaves the mapping to your own processes.

Which two conditions trigger the EUDI Wallet acceptance obligation?

Condition one
You already use strong user authentication because you are required to
The obligation attaches to relying parties under a legal or contractual obligation to use strong user authentication for online identification. Not to everyone with a login screen. The word contractual is doing real work: an obligation you accepted in a contract with a client, a scheme or a regulator can bring you into scope where no statute names you directly.
Condition two
You are not a micro or small enterprise
Micro and small enterprises are excluded. Under the EU definition, a small enterprise employs fewer than 50 people and has an annual turnover or balance sheet total not exceeding 10 million euros. Both the headcount and one of the financial thresholds have to be satisfied to stay under the ceiling.
And the condition most people skip: acceptance is required upon the voluntary request of the user. The wallet is not being imposed on citizens, and you are not being asked to replace your existing authentication. That distinction changes the shape of the project considerably. It is an additional route into your identity flow, not a migration.

Does being exempt mean being unaffected?

No, and this is the most useful part of the article for the majority of readers, because most organisations reading it are not in scope.

Your customers are in scope. If you supply software to banks, telecoms or health providers, your product becomes part of their compliance position. The same dynamic already applies under DORA, which we covered in what QA teams at banks have to prove to supervisors. Expect wallet support to appear in RFPs and renewal negotiations well before December 2027.
Your users will have one. Once citizens carry a wallet and use it at their bank, they will expect it elsewhere. Not accepting it becomes a friction cost rather than a compliance failure, which is a different problem with the same solution.
Voluntary acceptance is explicitly encouraged. The regulation provides for codes of conduct to encourage service providers outside the mandatory scope to accept wallets, and for the Commission to assess demand and usability within 24 months of deployment.

Which is worth stating plainly: exemption is a reason to plan on your own timetable, not a reason to plan nothing.

Not sure which side of the line your organisation sits on?
Talk to our team

What applies to public bodies and very large online platforms?

Three obligations, three dates
Public sector
Where eID is required to access an online public service, wallets must also be accepted. From 24 December 2026
Very large online platforms
Platforms designated under Regulation (EU) 2022/2065 are covered by the Article 5f acceptance obligation. From 24 December 2027
Private relying parties
The eleven named sectors, where both conditions apply, upon the user’s voluntary request. From 24 December 2027
The public sector date matters even to private companies. From December 2026 there will be live production services accepting wallets in every member state, which is the first point at which you can test against something real rather than a reference implementation.

What does the EUDI Wallet acceptance obligation require you to do?

Four things, and only one of them is what most teams picture.

Register as a relying party. A formal step with the national authority, not a configuration change, and it involves declaring what you intend to request. Registration is a prerequisite for requesting attributes, so it belongs at the start of a project plan rather than the end.
Request only what you need. The framework is built around selective disclosure, so you can ask whether someone is over eighteen instead of receiving a date of birth. Asking for the full identity dataset because it is technically available runs against both the design of the system and data minimisation.
Validate what arrives. A presented attestation has to be checked against the applicable trust list, which is a different verification model from checking a document or a national eID certificate, or from reading a Citizen Card directly.
Keep a path for everyone else. Wallet use is voluntary for citizens, so your existing identification route has to keep working alongside it for the foreseeable future.

The last point is the one that changes budgets. This is an addition to your identity stack, not a replacement, which means maintaining two paths and reconciling what each one produces. The technical side is covered in our relying party integration guide, the credential format decision in SD-JWT VC or ISO mdoc, and the wider obligation landscape in our eIDAS 2.0 implementation guide.

What should you settle before the end of 2026?

Four questions, in order. None of them is a development task, and all of them block one. Are you in scope, established in writing by whoever owns legal. Which of your flows are affected, remembering that onboarding is rarely the only one and that account recovery, contract changes, in-person identification and back-office verification are all identification flows. What you will actually request, decided per flow before anyone designs a screen. And who registers, and when, treating relying party registration as a lead-time dependency on an external body.

If you are in scope and none of the four has an owner, that is the finding, and December 2027 is closer than it reads.

Related reading

EUDI Wallet relying party integration guide Once you know you are in scope, this is the engineering side: registration, protocols and the data model.
SD-JWT VC or ISO mdoc: which do you build first? The framework requires both formats. Which one to sequence first, and what decides it.
eIDAS 2.0 implementation guide The wider set of obligations arriving before December 2026.
What LisbonID 2026 told us about digital identity in Europe Where policy ambition and operational reality still diverge, from two days of conversations.
eID Box Identity middleware for organisations that have to accept credentials rather than issue them.

Frequently asked questions

Scope of the EUDI Wallet acceptance obligation

Which sectors must accept the EUDI Wallet?
Article 5f(2) of the eIDAS Regulation as amended names transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. Providers of very large online platforms under the Digital Services Act are also covered. The obligation applies from 24 December 2027.
Is my company exempt from the EUDI Wallet obligation?
You are outside the mandatory scope if you are not in one of the eleven named sectors, if you are not under a legal or contractual obligation to use strong user authentication for online identification, or if you are a micro or small enterprise. A small enterprise employs fewer than 50 people with turnover or balance sheet total not exceeding 10 million euros.

The two dates

Why do people quote both December 2026 and December 2027?
Because both are real and they measure different things. The first five implementing acts entered into force on 24 December 2024. Member states must make a wallet available 24 months later, on 24 December 2026. The private-sector acceptance obligation follows 12 months after that, on 24 December 2027.
Does accepting the wallet mean replacing our current login?
No. Acceptance is required upon the voluntary request of the user, and wallet use is voluntary for citizens. Your existing identification routes have to keep working alongside the wallet, which makes this an addition to your identity stack rather than a migration.

What it means in practice

Do we need to register before accepting wallets?
Yes. Relying parties must register with the relevant national authority and declare their intended use before requesting attributes from a wallet. Because registration depends on an external body, it is a lead-time item and belongs early in a project plan.
What happens if we are exempt but our clients are not?
Their obligation becomes your requirement commercially. If you supply software or services to organisations in the eleven named sectors, wallet support is likely to appear in their procurement and renewal processes ahead of December 2027, regardless of whether the regulation names you.
Caixa Mágica Software
Caixa Mágica Team
Caixa Mágica Software is a Portuguese software company with 20+ years of experience delivering custom software, AI solutions and nearshore development teams for European businesses. We have worked on Portuguese national eID middleware for over a decade.
eID Box · Caixa Mágica Software
Find out which of your flows are in scope
Send us your sector and the flows where you verify identity today. We will tell you which are likely in scope, what the registration path looks like, and where the acceptance obligation reaches beyond onboarding.