eIDAS 2.0 vs eIDAS What changed

Adds European Digital Identity Wallets, wallet providers, wallet certification, relying-party registration, electronic attestations of attributes, electronic archiving, electronic ledgers, and new wallet supervision provisions.

Covers notified electronic identification schemes and trust service providers established in the Union, including signatures, seals, timestamps, registered delivery, website authentication certificates, qualified certificates, and trusted lists.

A login, certificate, or signature question is not automatically a wallet question. Scope the concrete role before assigning eIDAS 2.0 work.

Regulation (EU) 2024/1183 amends eIDAS; it does not create a stand-alone compliance silo. Wallet provisions are inserted into the same eIDAS framework.

Regulation (EU) No 910/2014 is the base regulation for EU electronic identification and trust services in the internal market.

Keep one eIDAS program taxonomy, but tag each artifact as wallet, eID scheme, trust service, certificate, attestation, or relying-party evidence.

The wallet lets users securely store, manage, validate, and present person identification data and electronic attestations of attributes to relying parties and other wallet users, with user control and selective disclosure.

The baseline eIDAS model centers on recognition of electronic identification means under notified schemes and the assurance levels used for cross-border access to public services.

Wallet design reviews should test user control, presentation, selective disclosure, relying-party authentication, and wallet-unit evidence, not only eID assurance level labels.

Wallet relying parties must register information including intended wallet use and data to be requested, keep registration information current, and validate person identification data and attestations requested from wallets.

A relying party under eIDAS is any natural or legal person that relies on electronic identification, a wallet or other eID means, or a trust service; baseline eIDAS use often focuses on relying on certificates, signatures, seals, timestamps, or trusted-list status.

For wallet integrations, collect relying-party registration, requested attributes, validation method, and user-request records before treating the service as ready for production.

Adds a detailed regime for electronic attestations of attributes, including qualified electronic attestations of attributes, public-sector attestations issued by or on behalf of authentic sources, revocation status, wallet interfaces, and electronic verification against authentic sources.

The original eIDAS trust-service model did not center on wallet-held attribute attestations; it focused on eID means and trust services such as signatures, seals, timestamps, registered delivery, website authentication, validation, and preservation.

Do not store attribute attestations as generic identity documents. Track issuer type, authentic source, attested attributes, validity period, revocation or status-check method, and whether the attestation has qualified or public-sector legal effect.

Wallet obligations are tied to the 2024 amendments and implementing acts; the legal text uses triggers such as 24 months after relevant implementing acts for Member State wallet provision and related authentic-source verification measures.

Trust-service timing is driven by existing eIDAS lifecycle events: conformity assessments, supervisory-body verification, trusted-list updates, certificate validity, revocation publication, status-check availability, and legal-effect requirements.

Track timing by source and trigger. Do not publish a single eIDAS 2.0 launch date for every actor, because wallet providers, relying parties, QTSPs, issuers, and Member States have different milestones.

Wallet supervision includes national supervisory bodies, Cooperation Group coordination, security-breach handling, relying-party registration suspension or cancellation for illegal or fraudulent wallet use, and possible suspension or cessation of wallet provision.

Trust-service supervision includes national supervisory bodies, audits, requests for conformity assessment, grant or withdrawal of qualified status, trusted-list updates, breach handling, and Member State penalty rules.

Do not cite a generic eIDAS fine table unless a grounded source supports the exact penalty rule. For this comparison, the reliable enforcement distinction is the supervisory route and corrective action available for wallets versus trust services.

The amended framework keeps certificates in scope and adds browser-facing rules around qualified certificates for website authentication, including a route for web-browser providers to notify concerns and for supervisory bodies to investigate.

Baseline eIDAS already defines certificates for website authentication and qualified certificates for website authentication, with Annex IV fields such as indication of qualified status, identity of the issuing qualified trust service provider, subject identity, domain names, validity period, certificate identity code, and validity-status services.

For QWAC evidence, preserve the certificate purpose, subject and domain data, issuer QTSP status, validity period, revocation or status endpoint, trusted-list evidence, and any browser concern or supervisory-body correspondence.

Wallets are certified by conformity assessment bodies, Member States inform the Commission and Cooperation Group about certified wallets, and supervisory bodies can require remediation or suspend or cease wallet provision where requirements are not met.

Qualified trust service providers are audited by conformity assessment bodies, supervised by national supervisory bodies, and may provide qualified services only after qualified status is indicated in trusted lists.

Wallet assurance evidence and QTSP assurance evidence are adjacent but different: one tracks wallet certification and ecosystem status; the other tracks qualified status, audits, and trusted-list publication.