eIDAS 2.0: digital identity wallets and remote qualified signatures by December 2026

Two dates sit inside eIDAS 2.0 and they are a year apart. By 24 December 2026 every member state has to provide at least one European Digital Identity Wallet. By 24 December 2027 a bank, lender or payment firm required to use strong user authentication for online identification has to accept one when a customer asks. The first is a delivery obligation on governments. The second opens with a registration that gates everything else, and both dates trace to article numbers a delivery team can plan against.

Where the December 2026 date comes from

Article 5a(1) of Regulation (EU) 2024/1183 gives member states 24 months from the entry into force of the implementing acts named in Article 5a(23) and Article 5c(6). Those acts are Commission Implementing Regulations (EU) 2024/2977, 2024/2979, 2024/2980, 2024/2981 and 2024/2982, adopted on 28 November 2024 and published in the Official Journal on 4 December 2024. Each entered into force on the twentieth day after publication, which is 24 December 2024. The wallet obligation therefore falls on 24 December 2026.

Acceptance runs on a different clock. Article 5f(2) gives private relying parties 36 months from the same starting point, so 24 December 2027. It bites where Union or national law, or a contract, requires strong user authentication for online identification, and it names banking and financial services alongside transport, energy, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. Micro and small enterprises are outside it, and acceptance is triggered only on the voluntary request of the user.

What the wallet hands a verifier

The wallet runs at assurance level high (Article 5a(11)), and issuance, use and revocation are free of charge to all natural persons (Article 5a(13)). It carries person identification data and electronic attestations of attributes, with selective disclosure under the sole control of the user (Article 5a(4)(a)). Article 5a(16) goes past a privacy statement: the technical framework must stop an attestation provider from obtaining data that tracks, links or correlates transactions, and must support unlinkability where the attestation does not require identification.

Formats are settled in the implementing acts. Annex II to Implementing Regulation (EU) 2024/2979 sets two, SD-JWT VC in clause 5 and ISO/IEC mdoc in clause 6, and person identification data in mdoc form uses the namespace eu.europa.ec.eudi.pid.1. Implementing Regulation (EU) 2026/1731 of 15 July 2026 rewrote Article 4(1) of Implementing Regulation (EU) 2024/2977 so that an attestation complies with at least one of those standards. An issuer picks one. A verifier serving several member states reads both.

Attribute attestations matter as much as the identity set. Annex VI lists what member states must make verifiable against an authentic source, and the entry a business onboarding team should read twice is powers and mandates to represent a natural or legal person. It stands in for the extract-and-read work behind every corporate account opening. Age, professional licences and, for legal persons, financial and company data sit on the same list.

One rule arrived in July 2026 and changes what a customer file may hold. The new Article 3a of Implementing Regulation (EU) 2024/2977 makes the wallet warn the user when a relying party asks for the portrait, requires explicit confirmation, and says the portrait shall not be retained unless that processing is necessary for identification and authentication under Union data protection law.

Registration comes before the integration

Article 5b(1) requires a relying party to register in the member state where it is established. The registration declares the intended use and indicates the data to be requested (Article 5b(2)(c)), and Article 5b(3) then forbids requesting anything else. The attribute request schema becomes a registered artefact, so a product change that adds one field is also a registration update under Article 5b(6).

Implementing Regulation (EU) 2025/848 of 6 May 2025 sets out the machinery. Each member state runs at least one national register with a published registration policy (Articles 3 and 4), verifies the applicant's identity and entitlements (Article 6), and authorises a certificate authority to issue wallet-relying party access certificates (Article 7). It may also authorise registration certificates, which carry what the party registered to request (Article 8). Your service authenticates to the wallet with that access certificate: no registration, no certificate, no test transaction.

Three clauses in Article 5b shape the flow itself. The relying party identifies itself to the user (5b(8)). It is responsible for authenticating and validating the data it receives, and may not refuse a pseudonym where the law does not require identification (5b(9)). An intermediary acting for a relying party is itself a relying party and may not store data about the content of the transaction (5b(10)). That last clause rules out routing identity traffic through a vendor that keeps its own copy.

Remote qualified signatures in a lending flow

A wallet signs. Article 5a(4)(e) lets the user sign with a qualified electronic signature, and Article 5a(5)(a)(xi) requires the protocols that create one. Article 5a(5)(g) says the wallet offers every natural person that ability by default and free of charge, with a carve-out: member states may take proportionate measures limiting free use to non-professional purposes. A consumer signing a loan agreement will probably sign for nothing; a director signing for a company falls outside the limit and somebody pays for the certificate.

Legal weight comes from Article 25(2) of Regulation (EU) No 910/2014: a qualified electronic signature has the equivalent legal effect of a handwritten signature. The engineering condition sits in Article 26(c): the signature creation data has to be usable, with a high level of confidence, under the sole control of the signatory. Regulation (EU) 2024/1183 defines a remote qualified electronic signature creation device as one managed by a qualified trust service provider under Article 29a on behalf of the signatory, and Article 29a(1) permits duplication of the signature creation data for backup only.

The reference standard now has a name and a date. Implementing Regulation (EU) 2025/1567 of 29 July 2025 sets ETSI TS 119 431-1 V1.3.1 for managing remote qualified signature and seal creation devices as a qualified trust service, and it applies from 19 August 2027. A signing service bought before then will be measured against that standard afterwards, so conformance belongs in the contract you are negotiating now.

1. The lender renders the agreement and computes the hash.
2. The customer authenticates to the qualified trust service, with the wallet as one accepted means.
3. The provider activates the signing key in the remote device under the signatory's sole control.
4. The provider returns the signature, and the lender assembles and validates the document.
5. The validation result and the trusted-list evidence go into the case file.

Two neighbouring regimes decide how much of this a bank can reuse. Recital 62 of Regulation (EU) 2024/1183 says secure electronic identification and attestation of attributes should support customer due diligence and strong customer authentication for account login and transaction initiation. Read that as direction. Under Delegated Regulation (EU) 2018/389 an authentication code still comes from two elements out of knowledge, possession and inherence (Article 4), and a remote payment still needs it dynamically linked to the amount and the payee (Article 5). A wallet presentation proves who the customer is and carries no amount and no payee, a familiar gap for open banking teams and their step-up flows.

On the anti-money-laundering side, Article 22(6)(b) of Regulation (EU) 2024/1624 lets an obliged entity verify identity with electronic identification means at eIDAS assurance level substantial or high, together with relevant qualified trust services. The wallet is at level high by construction. That regulation applies from 10 July 2027, about five months before the acceptance duty starts, so both land inside one planning year for anyone rebuilding digital onboarding once.

What breaks first in a wallet integration

We build this layer for banks and lenders. The parsing is rarely what fails. Three other things do, in a predictable order.

Trust anchors go first. A verifier has to decide whether the wallet in front of it is genuine, and that answer comes from trust lists rather than from the credential. Version 3.0.0 of the Architecture and Reference Framework, published on 23 July 2026, requires wallets, relying parties and issuers to support both trusted lists under ETSI TS 119 612 and lists of trusted entities under ETSI TS 119 602. Those lists change. A service that caches them and never refreshes passes staging, then rejects genuine wallets months later with an error nobody can reproduce. Build the refresh and the staleness alarm before the happy path.

Certificates expire on their own schedule. The access certificate under Article 7 of Implementing Regulation (EU) 2025/848 authenticates you to the wallet, and a registration certificate under Article 8 carries what you may ask for. Two lifecycles, two renewal owners, two ways for a Friday release to stop working. Put both on the rotation calendar that already holds your payment certificates, with the same alerting.

The identity model inside the bank is third, and usually the oldest. Article 5b(9) forbids refusing a pseudonym where the law does not require identification, and Article 5a(4)(b) has the wallet generate pseudonyms and store them locally. A customer table keyed on a national identifier will not hold that shape. Find out early whether the core can carry a customer whose stable key is a pseudonym for one service and a full identity set for another. That answer decides whether this is an integration or a migration.

Then order the work. Registration first, because it gates the certificates and moves at the speed of a legal review. One verifier service second, with both credential formats behind a single internal interface, so the application layer never asks whether it received an SD-JWT VC or an mdoc. The wallet handover last, because the deep link and the browser redirect are where session binding goes subtly wrong. The Commission publishes a reference implementation and a conformance suite alongside the framework; test against those rather than against whichever national pilot you can reach. We ordered it that way on a regulated consumer credit platform, where two KYC providers had to be integrated and the integration layer absorbed the difference.

Where Poland stands

Poland is a useful check on how the deadline behaves. The Ministry of Digital Affairs said on 4 March 2026 that the wallet will reach users through the mObywatel application, as a pilot at the end of 2026, unlocked by a one-off strong authentication with the electronic layer of the national identity card. The implementing bill, UC122, amends the Act on trust services and electronic identification; it went out for consultation on 19 February 2026, with adoption by the Council of Ministers listed for the third quarter of 2026. A pilot arriving on the deadline is the realistic picture across much of the bloc, so plan for a thin wallet population through 2027 and treat the fallback path as a first-class flow.