eIDAS 2.0 and the EUDI Wallet: What Relying Parties Must Prepare by the End of 2026
EU member states must provide the EUDI Wallet by December 2026. A sober overview of the technical and legal groundwork companies should lay now as relying parties.
In about six months a deadline expires that many companies still treat as distant regulation: by 24 December 2026, all 27 EU member states must provide their citizens and residents with at least one European Digital Identity Wallet (EUDI Wallet). The legal basis is Regulation (EU) 2024/1183 (“eIDAS 2.0”), in force since 20 May 2024.
For most companies the more pressing question is not when the wallet arrives, but when they will have to accept it. And that deadline follows immediately.
Where the rollout stands in June 2026
The regulatory foundation is well advanced. The Architecture and Reference Framework (ARF) is at version 2.8, and 31 implementing acts have already been published, referring to dozens of technical standards. On 8 April 2026 the European Commission added the implementing regulation on wallet enrollment, a central building block, because it governs how users get their identity securely into the wallet.
Member-state progress, however, is uneven. France is considered furthest along with “France Identité”, already running a production service and expanding it into the official EUDI Wallet; Italy and Poland follow closely. Germany has announced that it will launch its state-driven version on 2 January 2027, that is, shortly after the EU deadline.
Relying party: the role that affects almost everyone
A relying party is any entity that wants to rely on wallet attestations for identification or authentication, from onboarding through age verification to strong customer authentication.
The timing logic of the regulation is clear: once the wallets are available, regulated sectors and very large online platforms must accept the EUDI Wallet for authentication roughly one year later. The provisioning deadline at the end of 2026 thus becomes an acceptance obligation from around the end of 2027 for many. Banks, insurers, telecommunications and energy providers, healthcare and large platforms are in the front row; everyone else may accept the wallet voluntarily and is well advised not to start the integration at the last minute.
What a relying party should clarify now
Registration. Relying parties must register with a national registrar before first use, declaring which attributes they request and for what purpose. This registration is not a formality but the legal basis for being allowed to request data at all.
Data minimisation. The wallet is built for selective disclosure: users should share exactly the attributes a service genuinely needs, for instance “over 18” rather than a full date of birth. Requesting more than the purpose justifies clashes with both the eIDAS logic and the GDPR. Defining the minimal attribute set per use case is therefore the first substantive task, not the last.
Technical integration. Presenting attestations relies on established open protocols and formats, including OpenID for Verifiable Presentations and the attestation formats ISO/IEC 18013-5 (mdoc) and SD-JWT VC. Added to these are trust lists, through which a service verifies that a presented wallet and its issuers are genuine and authorised. Betting on standards rather than proprietary adapters keeps the wallets of different member states within reach.
Use cases and governance. Onboarding and KYC, age verification, strong customer authentication and qualified electronic signatures via the wallet are the obvious fields. Each of these cases needs clean consent and logging logic: who requested and received which attribute, when, and for what purpose.
In our Datargo ID module, this relying-party role is exactly the through-line: a single sign-on as the bracket, prepared for the EUDI path. The point itself, though, is independent of any tool: every accepting party sets the course for registration, attribute minimisation and standards-based integration for itself.
The sober timeline
Wallets are provisioned by the end of 2026, national solutions appear from early 2027 (Germany on 2 January 2027), and roughly a year after availability the acceptance obligation takes effect for regulated sectors. That sounds like 2027 and 2028, but it begins as a preparation task today: determine the attribute requirement, clarify the registration path, pilot a standards-based integration. The deadline is set; what remains voluntary is only the timing of preparation, not whether to prepare.