eIDAS 1.0 vs. 2.0: What Actually Changed and Why It Matters - Arbiter Blog

If you integrated a notified eID under Regulation (EU) No 910/2014 or stood up a qualified trust service, you already know more about eIDAS than most people writing about it. This article is for you. The aim is to be honest about what 1.0 did, what it failed to do, and what 2.0 actually changes underneath the marketing language.

Short version. The trust services half of eIDAS 1.0 worked. The eID half, judged against its own ambitions, did not. eIDAS 2.0 is, in large part, an admission of that and a redesign of the eID layer. Your QTSP work carries forward. Your assumptions about how a relying party plugs into a national eID gateway do not.

What eIDAS 1.0 was actually trying to do

Regulation 910/2014 had two halves stapled together. One half covered trust services: qualified electronic signatures (QES), qualified seals, qualified timestamps, qualified website authentication certificates, and the legal recognition of those instruments across member states. The other half covered electronic identification: a scheme where a member state could notify its national eID, and other member states had to accept it for access to public services.

The trust services half delivered. QES has legal weight under Article 25. The trusted list infrastructure works. Banks, notaries, and government back offices rely on it daily. Whatever you built around qualified certificates and the EU Trusted List Browser is still useful.

The eID half is the part to be candid about.

Why the eID side stalled

A few specific things went wrong, worth naming because eIDAS 2.0 is designed against each of them.

Notification was slow and uneven. By the time the notification list looked respectable, the underlying technology in each country was already aging. Each member state ran its own architecture: smartcards in some places, mobile signatures in others, bank-ID models elsewhere. The result was technical heterogeneity hidden behind a legal promise of mutual recognition.

Mutual recognition existed on paper, but onboarding for a relying party was painful. To accept a Belgian eID in a German service, you generally went through an eIDAS node and a national gateway. The integration surface was a member-state-specific endpoint, and its operational ownership was not friendly to private-sector relying parties.

The private sector was mostly excluded from the upside. Mandatory acceptance applied to public services only. A Spanish bank had no legal obligation to accept a Portuguese eID, and usually no commercial incentive to build for one. So citizens kept logging in with national patterns and the cross-border use case never reached scale.

User experience was poor. Redirect chains, card readers, mobile apps that only ran in one country. Users routed around it.

The architectural diff

This is the heart of it. The two regulations are not the same shape.

Aspect	eIDAS 1.0 (Regulation 910/2014)	eIDAS 2.0 (Regulation (EU) 2024/1183)
Scope of eID	Notified national eID schemes for cross-border access to public services	EU Digital Identity Wallet available to every EU citizen and resident
Identity instrument	Heterogeneous national schemes (smartcards, mobile signatures, bank IDs)	A single wallet category provided by member states or under their authority
Private-sector acceptance	Voluntary, with no general obligation	Mandatory acceptance for designated sectors and very large online platforms
Technology approach	Federation through eIDAS nodes and national gateways, SAML-based profiles	User-held credentials presented via OpenID4VP, OpenID4VCI, SD-JWT VC, and ISO/IEC 18013-5 mdoc
User control	Identity attributes brokered through the member-state gateway	Citizen holds credentials in their wallet and chooses what to present, with selective disclosure
Cross-border interoperability	Mutual recognition in principle, integration pain in practice	Common credential formats and protocols defined by the Architecture Reference Framework
Sector obligations	None for private actors in general	Acceptance obligations for banking and finance, telecom, energy, transport, postal, healthcare, education, and others

The biggest single change is in that fourth row. eIDAS 1.0 was a federation model: the relying party sent the user to a national eID gateway, which authenticated them and pushed assertions back. eIDAS 2.0 is a user-held model: the citizen holds verifiable credentials in their wallet and presents them directly to the relying party using OpenID4VP and related protocols.

That changes the trust topology. Under 1.0, your trust chain ran through the member state. Under 2.0, it runs through the wallet provider and the issuer of each credential, with the relying party verifying signatures against trust anchors published per the ARF. The member state is still upstream, but no longer the live integration partner for every authentication event.

It also changes the integration shape. The relying party no longer talks to a country-specific endpoint. It implements an OpenID4VP verifier, accepts a small set of credential formats, and asks for specific claims. The wallet decides what to release, the user authorizes it, and verification happens locally against published trust material.

What carries over from 1.0

eIDAS 2.0 does not delete the trust services half of 910/2014. It amends it. Qualified electronic signatures, qualified seals, qualified timestamps, qualified web authentication certificates, and the QTSP regime all continue. The trusted list infrastructure continues. The Level of Assurance framework from Implementing Regulation 2015/1502 continues to apply, with LoA High being the relevant bar for wallet attestations.

Practically: your QTSP relationships hold. Your signature validation code keeps working. Your understanding of advanced versus qualified, of seals versus signatures, of the legal effects clauses, all still applies. The wallet adds a new identity instrument on top of that machinery, not in place of it.

What is new

The Personal Identification Data set, PID, is the core identity attribute set that every wallet must support. Think of it as the floor everyone can rely on.

Electronic Attestations of Attributes, EAA, and their qualified variant QEAA, let issuers other than the state issue verifiable credentials into the wallet. A bank can attest that a person holds an account in good standing. A university can issue a diploma. The wallet is the container, not the issuer.

Registration of relying parties is new. To request certain categories of attributes, a relying party has to be registered in the member state where it is established, with its intended purpose declared. That is a deliberate constraint on over-asking, and operational work that did not exist under 1.0.

Sector acceptance obligations are new. Designated private-sector relying parties have to accept the wallet for strong customer authentication and identification, subject to the implementing acts. This is the legal lever 1.0 lacked.

The Architecture Reference Framework is new as a normative reference. The ARF is maintained on GitHub by the Commission and pins down the protocols, formats, and trust model. The four large-scale pilots, POTENTIAL, EWC, NOBID, and DC4EU, served as the technical proving ground.

If you already did 1.0 work

Keep your trust list tooling and your understanding of qualified certificates. The wallet ecosystem uses trust lists, signed metadata, and certificate-based verification at multiple layers. The mental model transfers.

Keep your LoA reasoning. High LoA is what wallets are aiming at, and the framework you learned still applies.

Discard the assumption that a national eID gateway is your integration surface. It is not. Your integration surface is an OpenID4VP verifier inside your own application, plus access to published trust material. The relying party is closer to the credential than it used to be.

Discard the assumption that private-sector acceptance is a commercial decision. In several sectors, it will be a regulatory one.

Discard the assumption that cross-border means cross-country gateways. It now means a citizen presenting credentials issued at home to a service in another country, with no live call across borders during authentication.

The honest read

eIDAS 1.0 produced a working trust services regime and a cross-border eID layer that, judged on its own goals, underperformed. eIDAS 2.0 keeps the part that worked and resets the part that did not. The redesign is not cosmetic. It moves identity from a federation of state gateways to a wallet held by the citizen, with the relying party verifying credentials directly using open protocols.

If you are coming from 1.0, the work in front of you is mostly about implementing a verifier, registering as a relying party, and adjusting to a credential-presentation model. The parts of 1.0 you actually built on, qualified trust services and the LoA framework, are still load bearing under 2.0. The integration patterns you learned for cross-border eID, the eIDAS node, the gateway redirects, the country-specific endpoints, are not the patterns of the next decade.

For background, the EU Commission's eIDAS policy page and the text of Regulation (EU) 2024/1183 are the primary sources worth reading directly.