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.
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?
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.
Which is worth stating plainly: exemption is a reason to plan on your own timetable, not a reason to plan nothing.
What applies to public bodies and very large online platforms?
What does the EUDI Wallet acceptance obligation require you to do?
Four things, and only one of them is what most teams picture.
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.


