Europe's Wallet

51.0 What this chapter gives you#

1. You will be able to explain what the European Union has legislated, naming the regulation, its date, and the single obligation it places on every member state.
2. You will be able to say what the first eIDAS regulation of 2014 achieved, and quote the Commission’s own figures for where it failed to gain adoption.
3. You will be able to list what a wallet must do, article by article, and say which of those things are free and which are voluntary.
4. You will be able to name the Architecture and Reference Framework, give its current version and date, and explain what kind of document it is.
5. You will be able to distinguish person identification data, an electronic attestation of attributes, a qualified one, and an attestation from a public body responsible for an authentic source.
6. You will be able to explain selective disclosure, state the unlinkability requirement in the regulation’s exact words, and say why cryptographers deny that the current design meets it.
7. You will be able to describe relying party registration, registration certificates, and the mechanism meant to stop a service asking for more than it declared.
8. You will be able to state both sides of the Article 45 argument about website certificates without caricaturing either, and quote the final text that settled it.
9. You will be able to write out the implementation timeline with the real dates, and say which have passed and which have not.
10. You will be able to judge, from evidence rather than press release, how far the rollout has actually got as of August 2026.

Most identity systems grow. Somebody builds a login, others connect to it, and years later a country notices it has an identity infrastructure it never designed. The European Union is attempting the opposite. It has written a law saying that every one of its twenty-seven member states shall provide its people with a digital identity wallet, that the wallet shall be free, that it shall work in every other member state, and that whole sectors of the economy shall accept it. Then it set a date.

That is a rare thing, and it is worth being precise about what it is. The European Union is not building an app and is not running a database of Europeans. It has passed a regulation, which in European law is legislation applying directly in every member state without being copied into national law, and that regulation obliges each country to produce a wallet of its own conforming to common technical rules. There will be at least twenty-seven wallets, built by different governments and contractors, and the project rests on the bet that they will interoperate because the specifications are tight enough.

The population figure people quote is around 450 million, roughly the number of people living in the European Union, and it is what makes this the largest coordinated identity programme in the democratic world. India built the largest biometric identity system ever attempted, and chapter 50 covers it. The United Kingdom abandoned a national card and built a certified market instead, and chapter 52 handles that. Europe’s answer is different from both: a legislated, decentralized, standards-driven wallet, with deadlines attached.

This chapter sets out that machinery honestly. We start with the plain idea of a wallet full of official papers, say exactly where that picture misleads, and then go through the law and the specifications with the real numbers. We carry one traveller through one transaction from beginning to end, and we spend proper time on the two live arguments: whether the privacy promises are technically deliverable, and whether one clause about website certificates threatened the security of the web. Both have serious people on both sides.

The plain version#

The folder of official papers#

Think of the drawer in your home where the important papers live. A passport or an identity card. A driving licence. A birth certificate, a degree certificate, perhaps a residence permit, a card from the health service, a letter proving your address. Each was made by a different office, and each says something official about you that a stranger will believe.

The papers work because of who made them. When a hotel clerk looks at your passport, the clerk is not trusting you but the government that printed it, and is checking that the thing in front of them really came from that government and really refers to the person standing there. The whole of identity, on paper, is that one trick repeated: a trusted office writes something down in a way that is hard to fake, and later somebody else reads it.

The European wallet is that drawer, moved onto a phone. Each official statement becomes a small signed electronic file. Instead of stamping a booklet, the passport office signs a file with a key that only it has, so anybody can check the signature and know the file is genuine and unaltered. Instead of a drawer at home, an app on your phone holds the files and hands them out when you choose.

That is the entire idea. Everything else is detail about how to do it without creating something worse than the drawer.

Why a law, and not just an app#

Here is the awkward part that makes this a legal problem rather than a software problem.

Suppose Denmark builds a beautiful identity app and Danish citizens love it. Now a Dane goes to rent a flat in Portugal. The letting agent has never heard of the app, cannot check whether it is genuine, has no software that understands its file formats, and no legal reason to accept it even if all that worked. So the Dane produces paper, and the app has achieved nothing outside Denmark.

Multiply that by twenty-seven countries and you have Europe as it was. Each country had, or was building, its own scheme, and the schemes did not talk to each other in any way ordinary people could use. No individual country could fix it, because the problem was not inside any one country. The only body that could was the one able to impose the same rule on all of them at once.

So Europe wrote the rule. Every member state must provide at least one wallet. Every member state must accept the wallets of the others where its own public services require a login. The wallet must be free for individuals. And there is a date by which this must be true.

What is in the wallet#

Two different sorts of thing go into the wallet, and keeping them apart makes everything else easier to follow.

The first is the identity core: the small set of facts saying which person you are, namely your surname, given names, date of birth, place of birth and nationality. It comes from the state, because only the state maintains the registers those facts live in, and it is issued once when you set the wallet up.

The second is everything else. Your driving entitlement, your university degree, your professional registration, your entitlement to a reduced fare, your right to work. Each is a separate signed statement from a separate issuer, and the wallet can hold as many as you collect. The wallet does not vouch for them; the issuers do.

The identity core answers “who is this”, and everything else answers “what is true about them”. A shop that wants to sell you wine does not need to know who you are. It needs one fact to be true about you.

Showing one line and not the whole page#

Which brings us to the part that is genuinely new, and which paper cannot do.

When you show a barman your driving licence to prove you are old enough to drink, he sees your date of birth, your full name, your address, your photograph, your licence number and the vehicle categories you may drive. He needed one fact and got about a dozen. Paper cannot be partially shown, so paper over-shares by its nature, every single time.

An electronic statement can be built so that parts of it are revealed separately. The issuer signs the whole thing in a way that lets you later hand over three fields and hold back the other nine, and the person receiving them can still check the issuer’s signature on just those three. This is called selective disclosure, and it is the single strongest argument for the whole project: in principle the barman gets one answer, “this person is over eighteen”, signed by a government, and nothing else.

The regulation requires the wallet to make this possible. It also requires something harder: where a piece of information does not need to identify you, the technology should stop different places you show it from working out that they saw the same person. That second requirement is where the serious technical argument lives.

The shop must say in advance what it will ask for#

There is a second protection in the law, and it is not cryptographic at all. It is bureaucratic, and it is arguably more important.

Before any shop, website or government office may ask your wallet for anything, it must first go to a public register in its own country and write down three things: who it is, what service it is running, and exactly which pieces of information that service will ask for. That register is public, and when a request arrives the wallet can check it against what was registered.

So a bicycle-hire company that registered “we will ask for name and proof of age over eighteen” cannot then ask for your home address and nationality, because your wallet can see that was not on the list, and so can you. The law states it flatly: a relying party shall not request data other than what it declared.

This is the anti-over-asking rule, and it exists because everyone involved knew what would otherwise happen. Handed a machine that dispenses government-verified personal data on request, ordinary commercial organizations will ask for everything, because data is cheap to keep and might be useful later. The register is the brake.

One traveller, one counter#

Let us make this concrete and keep the same person for the rest of the chapter.

Sofia Ivanova is a Bulgarian citizen, born on 17 April 1992, living in Sofia. In March 2027 she flies to Porto and walks up to a car hire desk. The company needs three things: that she is who she says she is, that she holds a valid driving licence, and that she is at least twenty-one, its minimum hiring age. On paper this is a passport and a licence handed across a counter, photocopied, and filed in Portugal along with her address, her passport number, her nationality and her exact date of birth, none of which the company needed.

With the wallet it goes differently. The company registered in Portugal as a relying party, declared a service called “rental counter” and listed the fields it would ask for. Sofia’s phone receives a request, checks it against that declaration, and shows her the company’s name, a trust mark and exactly what is being asked. She approves, and her wallet sends the answer. The company gets what it declared and nothing else, and her wallet keeps a record on a dashboard where she can later see every organization she has dealt with.

That is the promise. Now we have to be honest about which parts of it are already true, which are true only if certain choices are made, and which are not true at all.

Where the plain version stops being true#

There is no such thing as “the” wallet#

The plain version says Europe built a wallet. Europe did not build a wallet. Europe wrote a specification and told twenty-seven governments to each produce something that conforms to it. Denmark’s wallet, Germany’s wallet, Italy’s wallet and Poland’s wallet are separate pieces of software, procured separately, funded separately, with separate release schedules, separate user interfaces and separate bugs.

The honest version: this is a federation, not a system. What makes it one thing is a shared set of file formats, protocols and trust lists, plus a certification regime meant to stop any one country shipping something substandard. Interoperability is an outcome to be engineered, not a property of the design. If you are building software that must accept these wallets, plan for the differences between them, not for a single target.

“The shop only learns the answer” is a design goal, not a guarantee#

The plain version says the barman learns only that you are over eighteen. That is what the technology permits. It is not what the technology forces.

Whether you hand over one field or twelve is decided by what the relying party asks for and what the issuer put into the attestation. If a car hire company registers that it needs your name, your photograph, your licence categories and proof that you are over twenty-one, that is what it gets, and selective disclosure has saved you your address and your exact birth date and nothing more.

The honest version: selective disclosure is a capability of the format and a choice of the requester. The regulation requires the capability. It does not, and cannot, require every relying party to want less. The register of declared purposes is the mechanism meant to hold requesters honest, and it works exactly as well as the national registrars who supervise it.

The anti-over-asking rule catches the careless, not the determined#

The register stops a relying party asking for something it never declared. It does nothing about a relying party that declares a great deal and then insists on all of it.

Nothing prevents a company from registering “we require name, date of birth, address, nationality and portrait” for a service where two of those five would do. The check is against the declaration, not against necessity. Necessity is governed by data protection law, principally the requirement that personal data be adequate, relevant and limited to what is necessary, and that is enforced after the fact, slowly, and only when somebody complains.

The honest version: the wallet makes over-asking visible, and visibility is worth a great deal. The user can see the mismatch, and the wallet has a built-in route to report a suspicious request to the national data protection authority. But the enforcement is human and the incentive to ask for more is permanent.

“Voluntary” is doing heavy lifting#

The regulation says using the wallet is voluntary, and says that access to services, to the labour market and to the freedom to conduct a business must not be restricted or made disadvantageous for people who do not use one. That is a real and deliberately strong protection, and it was fought for.

But consider what happens when a bank, an airline, a hospital and a landlord all support the wallet and the alternative is a form, a phone call and a three-week wait. Nobody has been forced; everybody has been steered. The history of every optional identity credential is that optional in law and optional in practice diverge within a decade.

The honest version: the legal protection is genuine and constrains the obvious abuses, such as refusing service outright. It does not constrain queues, fees, waiting times and default paths, which is where compulsion actually lives. Whether “voluntary” survives implementation is an open empirical question, and the answer will differ by country.

The state does not watch your transactions, but somebody might#

A common fear is that the wallet reports your activity to the government. The regulation forbids this in several places, and the architecture is genuinely built to avoid it: the wallet holds your credentials locally, the presentation goes directly from your phone to the relying party, and the law explicitly says the wallet must not give attestation providers information about how their attestations are used.

That is not the same as saying nobody can work out anything. Two separate places you visit may be able to tell they saw the same person, if the credential you showed contained the same unique values both times. An issuer may infer how often you use a credential from how often you come back for a fresh one.

The honest version: the surveillance risk here is not a central log of everything. It is correlation at the edges, and the regulation’s own answer to it is a requirement for unlinkability that current mainstream technology does not fully satisfy. That is not a rumour; it is the subject of a signed letter from sixteen well-known cryptographers, which we set out below.

One clause about website certificates became a fight about the whole web#

The plain version has not mentioned website certificates at all, and a reader might reasonably wonder why they appear in a chapter about wallets. They appear because the same regulation that created the wallet also rewrote the rules for a different thing entirely: the certificates that prove a website is who it claims to be.

In 2023 that clause, Article 45, produced one of the loudest public disputes in internet security policy: an open letter signed by more than five hundred researchers, a joint statement from Mozilla, Cloudflare, the Linux Foundation and others, and a campaign arguing that Europe was about to roll back the security of the web. Supporters argued, with equal sincerity, that a handful of American browser vendors had appointed themselves the sole judges of who may be trusted on the internet, and that a democratic legislature was entitled to say otherwise.

The honest version: both descriptions contain truth, the final text is a compromise neither side won outright, and we give it a full section below with both cases stated in the terms their advocates would recognize.

The technical version#

eIDAS 1: what it built, and the numbers on where it stalled#

The law being amended is Regulation (EU) No 910/2014 of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market, published in the Official Journal L 257 of 28 August 2014. Everyone calls it eIDAS. It repealed Directive 1999/93/EC of 13 December 1999 on a Community framework for electronic signatures, which had largely failed because a directive must be transposed into national laws and duly was, differently in each country. eIDAS did two separate jobs. One succeeded and one did not.

The first was trust services. eIDAS created a legal category called a qualified trust service provider, supervised, audited and listed on national trusted lists that any software can fetch and check, and it defined qualified electronic signatures, seals, time stamps, registered delivery and certificates for website authentication with legal effects across the union. Article 25(2) is the famous one: a qualified electronic signature shall have the equivalent legal effect of a handwritten signature. This part worked.

The second job was electronic identification, and this is the part that stalled. If a member state notified a national electronic identity scheme to the Commission and the scheme met the assurance requirements, every other member state had to accept it for access to its own online public services. Notification was voluntary; recognition, once notified, was compulsory. The regulation applied from 1 July 2016, and the mutual recognition obligation became binding on 29 September 2018. The first scheme published in the Official Journal was Germany’s, on 26 September 2017.

The Commission’s own evaluation, published with its 2021 proposal to replace this part of the law, is the honest scorecard, and it is the reason the wallet exists.

Read those last two rows together. Even where a citizen had a notified scheme, only fourteen per cent of the providers of seven key public services across all member states allowed cross-border authentication with it. The Commission staff working document put it bluntly: cross-border use of notified electronic identities by the private sector was practically non-existent, because of liability questions, the absence of a viable commercial model, the difficulty of connecting to the eIDAS nodes, and the limited person dataset. Only seven notified schemes were fully mobile, at a time when the rest of consumer identity had moved onto phones. And eIDAS was aimed principally at citizens of working age living in another member state, a group the Commission put at around three per cent of the population, too small a base to generate network effects.

The picture is better now. The Commission’s overview of pre-notified and notified schemes, last updated on 2 February 2026, lists thirty-two notified schemes across twenty-six countries, including Norway and Liechtenstein, which are members of the European Economic Area rather than the union. Finland’s citizen certificate scheme was notified on 25 April 2025 and Romania’s ROeID on 9 September 2024. Coverage is no longer the binding constraint. Usability and private-sector acceptance still are, and that is what the new law goes after.

Regulation (EU) 2024/1183: the European Digital Identity Framework#

The Commission proposed the replacement on 3 June 2021, as COM(2021) 281 final. Negotiation ran for nearly three years, and the Council adopted the final text on 26 March 2024, the Parliament having approved it earlier that year.

The result is Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. It was published in the Official Journal on 30 April 2024 and, under its Article 2, entered into force on the twentieth day following publication, which was 20 May 2024.

Note what kind of instrument it is. It is an amending regulation: it edits the 2014 text rather than standing alone. When practitioners cite Article 5a or Article 45 or Annex VI they are citing the amended Regulation 910/2014, which is why you see both numbers used interchangeably. The amendments are extensive: a new Section 1 of Chapter II containing Articles 5a to 5f on the wallet, a rewritten Article 45 and a new Article 45a on website certificates, a new Section 9 containing Articles 45b to 45h on electronic attestation of attributes, new Sections 10 and 11 on archiving and electronic ledgers, and new Annexes V, VI and VII.

Four things matter most. Notification of an electronic identity scheme is no longer optional, because every state must now provide a wallet. The private sector is drawn in, because named regulated sectors and the very large online platforms must accept wallets. A new class of trust service is created for attributes. And the whole is given a hard technical floor through implementing acts, so conformance is a matter of law rather than goodwill.

Reading Article 5a: what the wallet must be#

Article 5a is the centre of the regulation and repays reading closely. The operative obligation is paragraph 1: each member state shall provide at least one European Digital Identity Wallet within 24 months of the date of entry into force of the implementing acts referred to in paragraph 23 of this Article and in Article 5c(6). Everything about the deadline follows from that clause, and we return to the arithmetic below.

Paragraph 2 allows three provisioning models: directly by a member state, under a mandate from a member state, or independently of a member state but recognized by it. That third option lets a country adopt a private scheme it already has rather than build from nothing.

Paragraph 3 requires the source code of the application software components to be open-source licensed, with a carve-out letting a state, for duly justified reasons, withhold the code of specific components other than those installed on user devices. The parts running on your own phone are meant to be inspectable.

Paragraph 4 is the functional list. The wallet must let the user request, obtain, select, combine, store, delete, share and present person identification data and attestations under the sole control of the user, while ensuring selective disclosure is possible. It must generate pseudonyms and store them encrypted and locally, authenticate another person’s wallet and exchange data between two wallets, and provide a common dashboard logging all transactions, listing the relying parties dealt with and the data exchanged, with routes to demand erasure under Article 17 of the General Data Protection Regulation and to report a relying party to the national data protection authority. It must also create qualified electronic signatures and seals and support data download and portability.

Paragraph 5 adds interface obligations and three things worth naming. Point (b): the wallet shall not tell trust service providers of electronic attestations of attributes anything about the use of those attestations. Point (d): Article 8 assurance level high, the top of the three-level scale of low, substantial and high. Point (g): every natural person must be offered qualified electronic signing by default and free of charge, with states permitted to limit free use to non-professional purposes.

The remaining paragraphs carry the political commitments. Paragraph 13: issuance, use and revocation shall be free of charge to all natural persons. Paragraph 14: users shall have full control, the provider shall not collect usage information beyond what is necessary, shall not combine wallet data with data from any other service it offers unless the user expressly asks, and must keep wallet data logically separate. Paragraph 15 is the voluntariness clause, paragraph 16 the privacy technical framework quoted in full below, and paragraph 21 requires accessibility under Directive (EU) 2019/882, the European Accessibility Act.

Article 5c governs certification: conformity with Article 5a(4), (5) and (8), and the logical separation requirement of 5a(14), must be certified by conformity assessment bodies designated by member states, with cybersecurity-relevant parts going through schemes under Regulation (EU) 2019/881, the Cybersecurity Act. Certification lasts up to five years provided a vulnerability assessment runs every two, and an unremedied vulnerability cancels it.

Article 5e is the breach rule and it has teeth. If a wallet, its validation mechanisms or its scheme is breached or partly compromised in a way affecting reliability, the member state shall without undue delay suspend provision and use, and if the compromise is not remedied within three months it shall withdraw the wallets and revoke their validity. There is no discretion in that second duty.

The roles, the lists and the certificates#

The ecosystem has a fixed cast, and the vocabulary is worth learning because the specifications use nothing else.

A Wallet Provider is the body mandated or recognized by a member state that makes a certified Wallet Solution available. A user’s installation of it is a Wallet Unit, comprising a Wallet Instance, the app itself, and secure cryptographic components called the Wallet Secure Cryptographic Application and Device, which in practice means the phone’s secure element. A PID Provider issues person identification data, having verified the user at assurance level high. An Attestation Provider issues everything else, in three flavours: a qualified trust service provider issuing qualified electronic attestations of attributes, a public sector body responsible for an authentic source issuing what the framework abbreviates as PuB-EAA, and a non-qualified provider issuing plain electronic attestations.

A Relying Party is a service provider requesting attributes from a Wallet Unit subject to the user’s approval, and the software it uses is a Relying Party Instance. A Registrar, one per member state, registers providers and relying parties and assigns identifiers, and an Access Certificate Authority issues the certificates that let them authenticate to a wallet. Trust flows through published lists: qualified providers appear on Trusted Lists in the format of ETSI TS 119 612, non-qualified participants on Lists of Trusted Entities in the format of ETSI TS 119 602, and the requirement that wallets, relying parties and issuers support both was a substantive change in the July 2026 framework version.

  Member State                    Trust infrastructure
  +--------------------+          +--------------------+
  | PID Provider       |          | Trusted Lists      |
  | (identity core)    |          | ETSI TS 119 612    |
  +---------+----------+          +---------+----------+
            | issues PID                    | trust
            v                               v anchors
  +--------------------+          +--------------------+
  |   Wallet Unit      | presents |  Relying Party     |
  |  (on the phone)    |--------->|  Instance          |
  |                    |<---------|                    |
  +---------+----------+ requests +---------+----------+
            ^                               ^
            | issues (Q)EAA                 | registers
  +---------+----------+          +---------+----------+
  | Attestation        |          | Registrar and      |
  | Provider / QTSP    |          | Access Cert. CA    |
  +--------------------+          +--------------------+

The line missing from this diagram is deliberately absent: there is no path from the Relying Party back to the PID Provider, and no central hub through which presentations pass. The presentation is a direct exchange between the phone and the relying party’s software, which is why the design can honestly claim that no authority sees your transactions.

The Architecture and Reference Framework#

The regulation says what must be true. The Architecture and Reference Framework, universally the ARF, says how. It is developed in the open on GitHub by the Commission with the eIDAS Expert Group and member state contributors, and engineers build from it.

Be exact about its status. It is not law: where it conflicts with an implementing act, the implementing act wins, and its own release notes describe it as aligning with the implementing regulations rather than the reverse. It is, however, the only place the requirements are stated at the level of detail a developer needs, and it carries requirement identifiers such as ISSU_35, VCR_17 or RPA_10a that are cited in national programmes and conformance test suites. As of August 2026 the current version is v3.0.0, released on 23 July 2026, and the roughly quarterly release cadence tells you how unsettled the design still is this close to the deadline.

Version 3.0.0 aligned the framework with the amending implementing regulations of 2026, introduced Relying Party Services, changed the rules for wallet-to-wallet interactions, added trust-anchor retrieval requirements covering both list formats, and added a Functional Conformance Assessment Framework in a new section 7.5: a shared, reusable set of test cases for the functional requirements a wallet solution must support.

The technical choices are these. Two credential formats: the mobile document format of ISO/IEC 18013-5, written originally for mobile driving licences, and SD-JWT VC, the selectively disclosable JSON Web Token credential format from the IETF. Two protocol families: OpenID for Verifiable Credential Issuance for getting credentials in and OpenID for Verifiable Presentations for getting them out, profiled through the OpenID4VC High Assurance Interoperability Profile. Proximity presentation, holding your phone near a reader, follows ISO/IEC 18013-5. The general machinery of verifiable credentials, and the difference between the ISO and W3C worlds, is the subject of chapter 53.

Person identification data and the three tiers of attestation#

The regulation’s definitions matter because they carry different legal effects.

Person identification data, defined in Article 3(3) as amended, is a set of data issued in accordance with union or national law that enables the establishment of the identity of a natural or legal person. It is the identity core. Commission Implementing Regulation (EU) 2024/2977 of 28 November 2024 fixes its contents. For a natural person, five attributes are mandatory.

A longer optional list includes resident_address and its components, personal_administrative_number, portrait, family_name_birth, given_name_birth, sex, email_address and mobile_phone_number. For a legal person the mandatory items are the current legal name and a unique member state identifier for cross-border identification.

The portrait caused the most political trouble. It sits in the optional list, but whether a member state may compel its inclusion was contested through 2026, and the compromise reached in the eIDAS Expert Group in June 2026 leaves the choice to each state: a state may make the portrait optional for its users, but is not obliged to. Commission Implementing Regulation (EU) 2026/1731 of 15 July 2026 added an Article 3a requiring the wallet to warn the user when portrait data is requested and to obtain explicit confirmation before disclosure. Digital rights organizations including epicenter.works and European Digital Rights argued that a facial image presented routinely to employers and authorities creates a pressure to consent that the word voluntary does not describe.

An electronic attestation of attributes is an attestation in electronic form that allows attributes to be authenticated. Three tiers sit around that definition, with different legal weight.

A plain electronic attestation of attributes, an EAA, comes from a non-qualified provider, and Article 45b(1) gives it the modest protection that it shall not be denied legal effect or admissibility as evidence solely because it is electronic or not qualified.

A qualified electronic attestation of attributes, a QEAA, comes from a qualified trust service provider and must meet Annex V: an indication that it is qualified, data unambiguously representing the issuing provider and its member state, data unambiguously representing the subject, the attested attributes, validity dates, a unique attestation identity code, the provider’s qualified signature or seal, the free location of the supporting certificate, and validity status information. Article 45b(2) gives it the same legal effect as a lawfully issued paper attestation, and Article 45d(4) adds a sharp rule: once revoked, a QEAA loses validity from that moment and its status shall not in any circumstances be reverted.

An attestation issued by or on behalf of a public sector body responsible for an authentic source, a PuB-EAA, is the third tier and in some ways the strongest. It must meet Annex VII, and its supporting certificate must indicate that the issuer is established under union or national law as responsible for the authentic source, identify that source, and identify the law. Article 45b(3) requires such an attestation issued in one member state to be recognized as such in all. A statement from the office that actually holds the register carries a cross-border recognition a commercial attestation does not.

Article 45e then does something quietly enormous. Within 24 months of the entry into force of the core implementing acts, member states must ensure that, at least for the attributes listed in Annex VI, wherever those attributes rely on public sector authentic sources, qualified providers can verify them electronically at the user’s request. Annex VI lists eleven categories: address; age; gender; civil status; family composition; nationality or citizenship; educational qualifications, titles and licences; professional qualifications, titles and licences; powers and mandates to represent natural or legal persons; public permits and licences; and, for legal persons, financial and company data. That is an obligation on every member state to make its public registers electronically queryable, on the citizen’s instruction, in eleven domains. It is a larger integration programme than the wallet itself, runs to the same clock, and is the part most likely to be late.

Article 45h adds separation duties for attestation providers: no combining attestation data with data from their other services or their commercial partners’, logical separation of what they hold, and functional separation of the qualified service from the rest of the business.

Selective disclosure, and the unlinkability requirement in its own words#

Two distinct properties are at stake, and the debate is unreadable unless they are kept apart.

Selective disclosure means revealing some fields of a signed credential while withholding others, with the remaining fields still verifiable. Both selected formats support it. In SD-JWT the issuer signs a set of salted digests, one per disclosable claim, and the holder later sends only the disclosures they wish to reveal along with the signed token; the verifier recomputes the digests and checks the signature. The mobile document format uses an equivalent construction with per-element digests inside a signed mobile security object. This is settled technology and it works.

Unlinkability is different and much harder. It asks that two parties who each received a presentation cannot tell they saw the same person, and that the issuer cannot tell where its credential was used.

Article 5a(16) states it, and the wording deserves quoting because everything else is measured against it. The technical framework shall, at point (a), not allow providers of electronic attestations of attributes or any other party, after issuance, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of them to be otherwise obtained, unless explicitly authorized by the user. And at point (b), it shall enable privacy preserving techniques which ensure unlikeability, where the attestation of attributes does not require the identification of the user.

That last word is not a typographical error in this book. The published Official Journal text of Regulation (EU) 2024/1183 reads “unlikeability” where it plainly means “unlinkability”. The typo has been noted in the academic literature and has survived into every consolidated version. It is a fair illustration of how a requirement of considerable technical difficulty entered European law: one clause, with a spelling mistake, whose consequences the people voting on it were not in a position to evaluate.

Unlinkability is hard because the natural way to build a selectively disclosable credential leaves fingerprints. In the salted-digest constructions used by both selected formats, the credential contains fixed values: the issuer’s signature, the salts, the digests, the holder’s public key. Present the same credential to two shops and both see the same signature over the same digests. Comparing notes, they can tell it was the same credential and therefore the same person, whatever fields were disclosed. Selective disclosure limits what each party learns; it does nothing about whether they can join their records.

The unlinkability argument, both sides#

In June 2024 a group of sixteen cryptographers published a document titled “Cryptographers’ Feedback on the EU Digital Identity’s ARF”. The signatories included Jan Camenisch and Anna Lysyanskaya, who between them invented much of the anonymous-credential literature, along with Bart Preneel, Carmela Troncoso, Anja Lehmann, Jaap-Henk Hoepman, Daniel Slamanig and Stefano Tessaro; the full list is in the chapter sources.

Their argument runs as follows. The regulation mandates three kinds of unlinkability: between relying parties, between the issuer and relying parties, and against wholesale correlation. Article 5a(16)(a) and (b) together require all three, and the salted-hash approach cannot deliver them. In their words, it cannot ensure unlinkability or untraceability with respect to colluding issuers and relying parties, nor did they see a viable solution even for unlinkability with respect to relying parties alone that also provides non-transferability, the property that you cannot lend your credential to somebody else. Their conclusion was that the way forward is anonymous credentials, preferably of the BBS type, and that there is no quick fix.

They also addressed the framework’s proposed workaround, batch issuance: give the user many copies of the credential, each with different salts and a different key, and use each once. If the user must create a fresh key pair for every unlinkable credential, they must store and manage a large number of keys on the device, and to re-authenticate under a previously established pseudonym they must remember which key was used towards which relying party. That, they judged, sacrifices both security and usability while still not preventing credential sharing.

The other side is not a straw man, and it has three parts. First, hardware: a credential bound to a key in a phone’s secure element resists cloning and lending in a way a purely mathematical construction does not, and the secure elements in shipping phones implement ECDSA over the standard curves, not BBS. A design requiring BBS signing inside the secure element cannot be deployed at population scale on the handsets people already own, on this decade’s timetable. That is a supply constraint, not a preference. Second, maturity: ECDSA, SD-JWT and the mobile document format are specified, profiled, tested and implemented by multiple vendors, while BBS has far less deployment history in high-assurance settings, and a regulator with a statutory deadline will usually take the well-understood construction with a known weakness. Third, the framework does not ignore the problem. Its discussion of privacy risks identifies four: relying parties linking transactions by comparing unique values such as salts and digests; an attestation provider recognizing values it issued and learning where the credential was used; revocation checking leaking which credentials are in use; and coordinated wholesale surveillance. Against these it sets out four methods of limiting how often a single attestation instance is presented.

The framework is candid about the costs. Method A fully mitigates relying party linkability but leaks usage information to the attestation provider, because frequent use means frequent reissuance, and it places an unpredictable load on issuers. Methods B and C avoid revealing usage frequency because issuance follows a fixed schedule, at the price of not eliminating linkability. Further concrete mitigations sit in the requirements: VCR_17 obliges providers using attestation status lists to assign each index randomly so the index does not become a correlator; VCR_18 requires enough entries on each list to ensure what the document calls herd privacy; OIA_16 obliges relying parties to discard unique elements as soon as they are no longer needed and not pass them on; and WUA_28a requires that a revocation reference in a key attestation cannot link a wallet’s interactions across different providers.

Where does that leave an honest reader? With a genuine expert disagreement. Nobody disputes that the deployed construction is linkable if the same instance is presented twice. The cryptographers say the regulation requires a property the construction cannot provide and that operational workarounds are no substitute for a cryptographic guarantee. The implementers say the workarounds reduce exposure to a level acceptable in practice, and that the alternative is not a better wallet in 2026 but no wallet in 2026. The law says unlinkability, the mainstream deployment does not deliver it in the strong sense, and that gap is a live compliance question rather than a settled one.

Relying party registration and the anti-over-asking machinery#

Article 5b most directly shapes what it will feel like to use one of these wallets.

Paragraph 1: where a relying party intends to rely on wallets for the provision of public or private services by means of digital interaction, it shall register in the member state where it is established. Paragraph 2 says the process shall be cost-effective and proportionate to risk, and that the relying party shall provide at least its member state of establishment, its name and where applicable its official registration number, its contact details, and the intended use of wallets including an indication of the data to be requested from users.

Paragraph 3 is the whole point, in one sentence: relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, point (c).

Paragraph 5 requires member states to publish that information online in electronically signed or sealed form suitable for automated processing, which is what makes machine checking possible. Paragraph 7 requires a common mechanism for identifying and authenticating relying parties, paragraph 8 requires them to identify themselves to the user, and paragraph 9 says they shall not refuse pseudonyms where identification is not required by law. Paragraph 10 closes an obvious hole: intermediaries acting for relying parties are themselves deemed relying parties and shall not store transaction content. Commission Implementing Regulation (EU) 2025/848 of 6 May 2025 lays down the registration rules including the certificate formats, and amending Implementing Regulation (EU) 2026/1730 revised it in 2026 to make registration faster and more automated.

Two certificates do two different jobs. An access certificate, issued by an Access Certificate Authority, lets the relying party’s software authenticate itself to a wallet: it answers “is this really who it says it is”. A registration certificate carries the relying party identifier, the service identifier and exactly one intended use with its attributes: it answers “is this request within what was declared”.

Version 3.0.0 refined this with Relying Party Services. The reasoning, in section 3.11.2, is that a relying party may be a large organization offering several services with different intended uses and therefore different attribute sets. So registration happens per service, each with a unique service identifier, and each registration certificate carries precisely one intended use. A bank’s mortgage service and its branch counter are separate registrations with separate declared attribute lists, and the wallet can tell which is asking.

Here is what that looks like for Sofia’s car hire company, as the wallet sees it.

Registered service (Portuguese registrar)
  relying_party_id : PT-RP-0041299
  service_id       : PT-RP-0041299/counter-rental
  legal_name       : Alugar Porto Lda
  intended_use     : identity, entitlement and age
  attributes       : family_name, given_name, portrait,
                     driving_privileges, age_over_21

Presentation request arriving at the wallet
  requested        : family_name, given_name, portrait,
                     driving_privileges, age_over_21
  within scope     : yes, 5 of 5 declared
  trust mark       : displayed
  user approval    : all of them, or none

Two honest caveats belong here. The first is requirement RPA_10a, under which the wallet should ensure the user approves either all attributes requested or none. There is a real argument for it: partial approval tells the relying party which fields the user refused, which is itself information, and produces a service that half-works in ways nobody designed. But it makes the user’s control a binary at the moment of the transaction, and the place where fine-grained control lives is a registration made months earlier in a public register the user has never read.

The second is timing. Implementing Regulation (EU) 2026/1731 of 15 July 2026, amending the protocols and interfaces act, sets a delayed application date of 11 August 2028 for validation of wallet-relying party registration certificates. That is the enforcement point of the entire anti-over-asking design, and it does not bite until nearly two years after wallets are supposed to exist. Wallets shipping at the end of 2026 will show you who is asking; whether they reliably check the ask against the declaration is, on the face of the implementing act, a 2028 question.

Article 45 and the qualified website certificate controversy#

Now the argument that made the front pages.

The background is a piece of eIDAS 1 that never took off. Since 2016 European law has recognized a qualified certificate for website authentication, a QWAC: a certificate binding a website to a legally verified organization, issued by a supervised qualified trust service provider under Annex IV. The idea was that when you visit a bank’s website you should be able to see, verifiably, which legal entity is behind it. Browsers did not adopt them, having already concluded from extended validation certificates, introduced by the CA/Browser Forum in 2007, that showing organization names in the address bar did not change user behaviour. Google removed the extended validation name from Chrome’s address bar in Chrome 77 in September 2019, and Mozilla did the same in Firefox 70 in October 2019.

The 2021 proposal therefore contained a clause requiring browsers to recognize QWACs. Through 2023 the drafts circulating in trilogue went further, and the security community reacted with force.

On 2 November 2023 an open letter was published, signed by 504 scientists and researchers from 39 countries together with a number of non-governmental organizations. Their case, in their words, was that the text enabled each member state, and recognized third countries, to designate cryptographic keys for which trust is mandatory; that the owner of a root certificate can intercept a user’s web traffic by replacing a website’s keys with substitutes it controls; and that the proposal radically expanded the ability of governments to surveil citizens and residents across the union while undermining the oversight mechanisms they rely on. A second objection was structural: a draft clause banned browsers from applying security checks to European web certificates unless expressly permitted, which the signatories argued converted a floor into a ceiling, freezing browser security at the level of the day the law passed.

The same day an industry joint statement was published by organizations including Mozilla, Cloudflare and the Linux Foundation, co-signed by the Open Source Security Foundation. The Electronic Frontier Foundation published a piece titled “Article 45 Will Roll Back Web Security by 12 Years”, and Steven Murdoch of University College London was among the academics who spoke publicly.

The case on the other side received far less coverage and has three serious parts. The first is legitimacy: the set of certificate authorities browsers trust is decided by a small number of private companies, most of them American, through root programmes run at their own discretion, and those programmes have removed European certificate authorities before. A European legislator can reasonably ask why a supervised, audited, legally accountable European trust service provider should be excluded from the web’s trust store by the unappealable decision of a foreign vendor, and can call that a sovereignty problem rather than a security one. The second is that identity on the web genuinely was lost: domain-validated certificates prove control of a domain name and nothing else, so a user has no verifiable way to tell whether the bank site they are on belongs to the bank. The third is that the security objection proves too much, because browsers already trust many government-linked certificate authorities; the concern is about removing the ability to distrust, not about trust itself.

The final text is a compromise and it is worth reading precisely. Article 45(1a) provides that qualified certificates for website authentication shall be recognized by providers of web browsers, that browsers shall ensure the identity data attested in the certificate and additional attested attributes are displayed in a user-friendly manner, and that they shall ensure support and interoperability, with an exception for microenterprises and small enterprises during their first five years as browser providers. Article 45(1b) provides that such certificates shall not be subject to any mandatory requirements other than those in paragraph 1.

Then the new Article 45a, headed cybersecurity precautionary measures, carries the concession the researchers won. Browsers shall not take measures contrary to their Article 45 obligations, but by way of derogation, and only in the event of substantiated concerns related to security breaches or loss of integrity of an identified certificate or set of certificates, they may take precautionary measures against that certificate or set. They must then notify their concerns in writing without undue delay, with a description of the mitigating measures, to the Commission, the competent supervisory body, the certificate holder and the issuing provider, and the supervisory body must acknowledge receipt. That body shall investigate, and where the investigation does not result in withdrawal of qualified status, shall inform the browser and request that it end the measures.

Read that as an engineer and you can see what each side got. The browsers got a lawful path to act against a specific compromised certificate, which earlier drafts appeared to remove. The trust service providers got a rule that a browser cannot impose extra requirements of its own, and cannot maintain a precautionary block indefinitely once a supervisory body has investigated and declined to withdraw qualified status. What remains contested is the case where browser and supervisor disagree in good faith about whether a practice is dangerous, because the text resolves that in the supervisor’s favour.

The implementing act completing this part arrived late. Article 45(2) required the Commission to establish reference standards for these certificates by 21 May 2025; Commission Implementing Regulation (EU) 2025/2527 of 16 December 2025 lays them down. As of August 2026 there is no reported case of Article 45a being invoked, which is unsurprising, because the recognition obligation has not yet produced widespread issuance.

The timeline, with the dates that are already running#

Now the arithmetic, because this is the part people get wrong. Article 5a(1) names no date. It sets a period of 24 months from the entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6). Those acts were due by 21 November 2024, were adopted a week late on 28 November 2024, and five of them were published in the Official Journal on 4 December 2024.

Each entered into force on the twentieth day after publication, which was 24 December 2024. Twenty-four months later is 24 December 2026. That is the wallet deadline, and it is why every consultancy in Europe writes “December 2026” without explaining where the date comes from.

The same clock drives two more obligations. Article 5f(2) gives private relying parties in the named sectors, transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications, until 36 months from that same start, 24 December 2027, to accept wallets where they must use strong user authentication and the user asks them to; microenterprises and small enterprises as defined in Commission Recommendation 2003/361/EC are excluded. Article 45e gives member states the same 24 months to make the Annex VI attributes electronically verifiable.

Article 5f(1) has no separate deadline: where member states require electronic identification to access a public sector online service, they shall also accept wallets. Article 5f(3) obliges providers of very large online platforms designated under Article 33 of the Digital Services Act, Regulation (EU) 2022/2065, to accept and facilitate wallet use for authentication where they require it, on the user’s voluntary request and for the minimum data necessary.

Later waves filled in the rest. Implementing Regulations (EU) 2025/846 on cross-border identity matching, 2025/847 on security breaches, 2025/848 on the registration of wallet-relying parties and 2025/849 on the list of certified wallets completed the wallet-specific set, and a larger 2025 batch covered the trust services. Implementing Regulation (EU) 2026/798 on remote user onboarding was published on 8 April 2026, which matters because a wallet issued at assurance level high to somebody who never visits an office is the case almost everyone will use.

Then in July 2026 came the alignment round: Implementing Regulations (EU) 2026/1730, 2026/1731 and 2026/1735. The middle one, of 15 July 2026, amended all four core technical acts at once, updating cryptographic mechanism requirements and wallet unit attestation specifications, adding an Article 14a mandating display of the EU Digital Identity Wallet Trust Mark, removing the delegation of tasks to an intermediary application, and setting the 2028 date for registration certificate validation.

Name the pattern plainly. Five months before the statutory deadline for shipping certified wallets to 450 million people, the technical specifications those wallets must meet were still being amended. That is not a scandal, and every large standards programme looks like this from the inside. It is, however, the single best predictor of what December 2026 will actually look like.

Sofia at the counter, and where the rollout actually stands#

Let us finish the transaction, with real field names, and then look at whether it will happen on time.

Sofia Ivanova, born 17 April 1992, sets up her Bulgarian wallet. Her PID Provider verifies her at assurance level high and issues person identification data into the wallet unit. The mandatory core, in the encoding fixed by Implementing Regulation (EU) 2024/2977, looks like this, with optional fields shown for contrast.

{
  "family_name":   "Ivanova",
  "given_name":    "Sofia",
  "birth_date":    "1992-04-17",
  "birth_place":   "BG",
  "nationality":   ["BG"],

  "portrait":      "<optional: facial image>",
  "resident_city": "<optional>",
  "sex":           "<optional>",
  "personal_administrative_number": "<optional>"
}

She then collects a second credential. Bulgaria’s driving licence authority is a public sector body responsible for an authentic source, so what it issues is a PuB-EAA under Article 45f, meeting Annex VII, and by Article 45b(3) it must be recognized as such in every member state. It carries her driving privileges and a derived attribute, age_over_21, computed and signed by the issuer rather than left for the verifier to work out.

At the counter in Porto in March 2027 the relying party instance presents its access certificate, and the wallet checks it against the Portuguese Access Certificate Authority’s trust anchor from the published list. The wallet reads the registration certificate: relying party PT-RP-0041299, service counter-rental, one intended use, five declared attributes. The request asks for those five. The wallet displays the EU Digital Identity Wallet Trust Mark, the legal name Alugar Porto Lda, the intended use and the five items. Sofia approves, all or nothing, under RPA_10a, and the wallet returns family_name, given_name, portrait, driving_privileges and age_over_21, each selectively disclosed from the two credentials and each carrying its issuer’s signature.

Count what changed. The company did not learn her exact date of birth, her address, her nationality, her licence number or her personal administrative number. It did learn her name and see her face, because for a car hire counter that is defensible and it was declared. Her dashboard now holds a record from which she can demand erasure under Article 17 of the General Data Protection Regulation or report the company to a data protection authority. And the company holds a cryptographically signed, non-repudiable record that Sofia Ivanova presented a government-issued licence attestation on that date, which is stronger evidence than a photocopy and lives in its systems as long as its retention policy says.

Now the state of play. As of August 2026 the deadline is four months away and the picture is uneven. Denmark launched AltID in production on 3 June 2026, the clearest example of a national wallet in real use, although its relying party registry is at that point a national arrangement rather than the eIDAS registry the regulation requires. France runs France Identité as a live national identity app with a public playground for relying parties, but it is not yet certified as a wallet. Germany’s state wallet, run by the federal digital ministry with the federal agency for disruptive innovation, has a public sandbox and a staged rollout expected in early 2027. Austria, Belgium, Greece, Luxembourg, Poland and Slovakia have existing national identity apps confirmed for upgrade. Others have announced programmes with no public testing environment at all.

Independent readiness assessments converge on the same shape. One country-by-country review published in the first quarter of 2026 classified the twenty-seven member states as three almost certain to meet December 2026, five very likely, eight likely, seven possible and four unlikely. That is a majority meeting the deadline in some form and a substantial minority not, with the caveat that “available” and “usable” will not mean the same thing everywhere on the same day. A wallet that exists, holds person identification data and can present it to two government services satisfies the letter of Article 5a, and is not what the press releases have described.

The evidence base underneath is better than it was. Four large-scale pilots ran from April 2023 with Commission co-funding: POTENTIAL on electronic government, banking, SIM registration, mobile driving licences, signatures and prescriptions; NOBID on payments; DC4EU on education credentials and social security; and EWC on travel credentials, organizational identity and payments. POTENTIAL ran to September 2025 and closed formally on 27 November 2025, reporting more than 1,300 tests across more than 140 organizations from 19 member states plus Ukraine, and more than 1,000 successful transactions of which 249 were cross-border. NOBID held its final meeting in Rome on 26 June 2025 after involving six countries and more than thirty partners. Two successor pilots began in 2025: APTITUDE on digital travel credentials and advanced banking, and WE BUILD, with around 200 participants and a budget of some 25 million euros.

Those numbers deserve perspective. Two hundred and forty-nine successful cross-border transactions is an excellent pilot result and a rounding error against 450 million people. The pilots proved the architecture works. They did not prove it scales, and nothing yet has.

One last observation. Article 5f(5) requires the Commission, within 24 months after deployment, to assess demand, availability and usability, taking into account user take-up, cross-border presence of service providers, technological developments and consumer demand. Europe has written into the law an obligation to come back in 2028 and ask whether anybody used it. Given that the honest verdict on eIDAS 1 came from exactly such an evaluation, that may prove one of the most useful sentences in the regulation.

51.98 Common wrong ideas#

Wrong: The European Union is building a single identity app for all Europeans. Right: Regulation (EU) 2024/1183 obliges each of the twenty-seven member states to provide at least one wallet of its own, built directly, under mandate, or by a recognized private party, so there will be at least twenty-seven distinct pieces of software held together by shared implementing acts, formats, protocols and trust lists plus certification under Article 5c.

Wrong: Using the wallet will be compulsory. Right: Article 5a(15) says use shall be voluntary and that access to public and private services, to the labour market and to the freedom to conduct a business shall not be restricted or made disadvantageous for non-users; what it does not govern is queue design, fees, waiting times and default paths, so whether the alternative route stays usable is an empirical question answered differently in different countries.

Wrong: Selective disclosure means a verifier only ever learns a yes or no answer. Right: It is a capability of the credential format, supported by both SD-JWT VC and the ISO/IEC 18013-5 mobile document, letting the holder reveal some signed fields and withhold others; what is revealed depends on what the relying party registered and requested, so the limit on the request is registration under Article 5b, not cryptography.

Wrong: The regulation’s unlinkability requirement is satisfied by the wallets being built. Right: Article 5a(16)(b) requires the framework to enable privacy preserving techniques ensuring unlinkability where the attestation does not require identifying the user, and the salted-digest constructions in the selected formats leave fixed values two relying parties can compare to detect the same credential, which is why sixteen cryptographers wrote in June 2024 that the approach cannot deliver it and why the framework offers operational mitigations rather than a cryptographic guarantee.

Wrong: The wallet deadline is the end of December 2026 because the regulation says so. Right: Article 5a(1) sets a period of 24 months from the entry into force of the acts required by Article 5a(23) and Article 5c(6); those five acts were adopted on 28 November 2024, published on 4 December 2024 and entered into force on 24 December 2024, so the deadline is 24 December 2026 and the same clock produces 24 December 2027 for the Article 5f(2) and Article 45e duties.

Wrong: Article 45 forces browsers to trust whatever certificate authority a government nominates, with no way to respond to abuse. Right: Article 45(1a) requires browsers to recognize qualified website authentication certificates and display their identity data and 45(1b) bars additional mandatory requirements, but the new Article 45a permits precautionary measures against an identified certificate or set of certificates where there are substantiated concerns about security breaches or loss of integrity, subject to written notification and a supervisory investigation that can require the measures to end.

Wrong: A qualified electronic attestation of attributes and a plain one differ only in marketing. Right: A plain attestation gets only the non-discrimination rule in Article 45b(1), a qualified one must meet Annex V and gets the legal effect of a lawfully issued paper attestation under Article 45b(2), and one from a public sector body responsible for an authentic source must meet Annex VII and is guaranteed cross-border recognition by Article 45b(3).

Wrong: The government will be able to see every place you use your wallet. Right: Presentations pass directly from phone to relying party with no central hub, Article 5a(5)(b) forbids the wallet from telling attestation providers how their attestations are used, and Article 5a(14) bars the provider from collecting unnecessary usage data or combining it with its other services; the residual risk is correlation at the edges, which is what the unlinkability debate is about.

51.99 Chapter summary in 20 lines#

1. Regulation (EU) 2024/1183 of 11 April 2024 amends the 2014 eIDAS Regulation to create the European Digital Identity Framework, and it entered into force on 20 May 2024.
2. Regulation (EU) No 910/2014 of 23 July 2014 succeeded at trust services and stalled at electronic identification, and the wallet exists because of that second failure.
3. The Commission’s 2021 evaluation found 14 member states had notified 19 schemes covering 59 per cent of the population, and that only 14 per cent of providers of seven key public services accepted a notified scheme from another country.
4. Article 5a(1) obliges every member state to provide at least one European Digital Identity Wallet within 24 months of the entry into force of the implementing acts under Article 5a(23) and Article 5c(6).
5. Those acts, Implementing Regulations (EU) 2024/2977 and 2024/2979 to 2024/2982, were adopted on 28 November 2024 and entered into force on 24 December 2024, making the wallet deadline 24 December 2026.
6. Article 5f(2) requires private relying parties in transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications to accept wallets by 24 December 2027.
7. The wallet must be free of charge to natural persons, must offer qualified electronic signatures free by default, must be certified at assurance level high, and its user-device source code must be open-source licensed.
8. Article 5a(4) requires selective disclosure, locally stored pseudonyms, wallet-to-wallet exchange, and a dashboard logging every transaction with routes to demand erasure and to report a relying party.
9. Article 5a(15) makes use voluntary and forbids disadvantaging non-users, and Article 5a(14) forbids the provider from collecting unnecessary usage data or combining it with its other services.
10. Implementing Regulation (EU) 2024/2977 fixes five mandatory person identification data attributes for natural persons: family_name, given_name, birth_date, birth_place and nationality, with portrait among the optional ones.
11. Attestations come in three tiers with different legal effects: a plain electronic attestation, a qualified one meeting Annex V, and one from a public sector body responsible for an authentic source meeting Annex VII, which alone carries guaranteed cross-border recognition.
12. Article 45e obliges member states, on the same 24-month clock, to make the eleven Annex VI attribute categories electronically verifiable against public sector authentic sources at the user’s request.
13. The Architecture and Reference Framework is the engineering document, developed openly on GitHub, and its current version as of August 2026 is v3.0.0 of 23 July 2026, which added Relying Party Services, trust-anchor retrieval from both ETSI list formats, and a Functional Conformance Assessment Framework.
14. The framework selects two credential formats, SD-JWT VC and the ISO/IEC 18013-5 mobile document, and two protocols, OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations, profiled through the OpenID4VC High Assurance Interoperability Profile.
15. Article 5a(16)(b) requires privacy preserving techniques ensuring unlinkability, a requirement whose published text contains the typographical error “unlikeability”, and which the deployed salted-digest constructions do not satisfy in the strong sense.
16. Sixteen cryptographers argued in June 2024 that only anonymous credentials of the BBS type can meet it, while implementers reply that shipping secure elements do ECDSA and not BBS and that batch issuance with rotating or once-only presentation is the deployable mitigation.
17. Article 5b requires every relying party to register and declare its identity, intended use and the attributes it will request, forbids requesting anything else, and deems intermediaries relying parties barred from storing transaction content.
18. Registration is enforced through access certificates that authenticate the requester and registration certificates carrying exactly one declared intended use, but Implementing Regulation (EU) 2026/1731 of 15 July 2026 delays the duty to validate registration certificates to 11 August 2028.
19. Article 45(1a) requires browsers to recognize qualified website authentication certificates and 45(1b) bars extra mandatory requirements, while the new Article 45a permits precautionary measures against identified compromised certificates, a compromise reached after the open letter of 2 November 2023 signed by 504 researchers from 39 countries.
20. As of August 2026 Denmark had launched AltID in production on 3 June 2026, Germany expected a staged rollout in early 2027, and independent reviews placed roughly half the member states as likely or better to meet 24 December 2026, mostly with a limited first release.

Chapter sources: Regulation (EU) No 910/2014 of 23 July 2014 on electronic identification and trust services and repealing Directive 1999/93/EC, Official Journal L 257 of 28 August 2014, in force 17 September 2014, applying from 1 July 2016, with mutual recognition binding from 29 September 2018; Directive 1999/93/EC of 13 December 1999; Regulation (EU) 2024/1183 of 11 April 2024 establishing the European Digital Identity Framework, published 30 April 2024 and in force from 20 May 2024, in particular Articles 5a to 5f, the replaced Article 45 and new Article 45a, Articles 45b to 45h and Annexes IV to VII; Commission proposal COM(2021) 281 final of 3 June 2021 and Commission Staff Working Document SWD(2021) 124, for the figures of 14 notifying member states, 19 notified schemes, 59 per cent coverage and 14 per cent acceptance among providers of seven key public services; Commission Implementing Regulations (EU) 2024/2977, 2024/2979, 2024/2980, 2024/2981 and 2024/2982, all of 28 November 2024, published 4 December 2024 and in force from 24 December 2024; Implementing Regulations (EU) 2025/846, 2025/847, 2025/848 of 6 May 2025 and 2025/849; Implementing Regulation (EU) 2025/2527 of 16 December 2025 on reference standards for qualified certificates for website authentication; Implementing Regulation (EU) 2026/798 on remote user onboarding, published 8 April 2026; Implementing Regulations (EU) 2026/1730, 2026/1731 of 15 July 2026 and 2026/1735; the European Digital Identity Wallet Architecture and Reference Framework version 3.0.0 of 23 July 2026, in particular sections 3.11 and 3.11.2, section 7.5, the Annex 2 requirements ISSU_35, OIA_16, RPA_10a, VCR_17, VCR_18 and WUA_28a, and the discussion paper on privacy risks and mitigations setting out presentation-frequency methods A to D, with releases v2.7.0 of 10 November 2025, v2.8.0 of 2 February 2026 and v2.9.0 of 21 May 2026; Cryptographers’ Feedback on the EU Digital Identity’s ARF, June 2024, by Carsten Baum, Olivier Blazy, Jan Camenisch, Jaap-Henk Hoepman, Eysa Lee, Anja Lehmann, Anna Lysyanskaya, Rene Mayrhofer, Hart Montgomery, Ngoc Khanh Nguyen, Bart Preneel, abhi shelat, Daniel Slamanig, Stefano Tessaro, Soren Eller Thomsen and Carmela Troncoso; the open letter on eIDAS Article 45 of 2 November 2023 signed by 504 researchers from 39 countries, the industry joint statement of the same date co-signed by Mozilla, Cloudflare, the Linux Foundation and the Open Source Security Foundation, and the Electronic Frontier Foundation commentary “Article 45 Will Roll Back Web Security by 12 Years”; ETSI TS 119 612 and ETSI TS 119 602; ISO/IEC 18013-5:2021; the IETF SD-JWT and SD-JWT VC specifications and the OpenID Foundation OpenID4VCI, OpenID4VP and OpenID4VC High Assurance Interoperability Profile documents; Regulations (EU) 2016/679, 2019/881 and 2022/2065, Directive (EU) 2019/882 and Commission Recommendation 2003/361/EC; the Commission overview of pre-notified and notified eID schemes, last updated 2 February 2026; the POTENTIAL, NOBID, DC4EU and EWC pilot closing reports of 2025 and the APTITUDE and WE BUILD launch materials; and national rollout snapshots of July and August 2026 with country-by-country readiness assessments from the first half of 2026.