The original eIDAS framework focused on notified electronic identification schemes and trust services for electronic transactions. The 2024 amendments add European Digital Identity Wallets, wallet relying-party rules, electronic attestations of attributes, and updated supervision for wallet and trust-service ecosystems.
This page helps separate legacy eIDAS evidence from new wallet-specific work without treating every identity, certificate, or authentication decision as the same obligation.
is not a separate replacement regime. Regulation (EU) 2024/1183 entered into force on 20 May 2024 and amended Regulation (EU) No 910/2014, keeping the eID and trust-service framework while expanding it around the . For compliance planning, ask whether the issue concerns notified eID and trust services, wallet issuance and certification, relying-party registration, attribute attestations, or wallet data requests. Member State wallet provision and several acceptance duties run from the entry into force of specified implementing acts, so the actor and legal trigger matter more than the label 'eIDAS 2.0 deadline.'
Side-by-side comparison
eIDAS 2.0 vs eIDAS: operational differences
Use these rows to identify whether a question belongs to the baseline eIDAS trust-service framework, the 2024 EUDI Wallet amendments, or both.
The 2024 amendments add the EUDI Wallet ecosystem, wallet certification, relying-party registration, attribute attestations, wallet trust marks, and updated supervision.
Second framework
Original eIDAS framework
The original framework remains the base for notified electronic identification schemes and trust services such as signatures, seals, timestamps, registered delivery, qualified certificates, QWACs, and trusted lists.
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.
Regulation (EU) 2024/1183 amends eIDAS; it does not create a stand-alone compliance silo. Wallet provisions are inserted into the same eIDAS framework.
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.
The amendment entered into force on 20 May 2024. Member State wallet provision is due within 24 months after the specified Article 5a(23) and Article 5c(6) implementing acts enter into force; the Commission adopted the first five wallet implementing regulations on 28 November 2024 and describes rollout by the end of 2026.
Track timing by actor, provision, and implementing act. Wallet providers, private relying parties, QTSPs, attestation issuers, and Member States do not all share one launch date.
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 cited 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 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.
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.
Regulation (EU) 2024/1183 amends eIDAS; it does not create a stand-alone compliance silo. Wallet provisions are inserted into the same eIDAS framework.
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.
The amendment entered into force on 20 May 2024. Member State wallet provision is due within 24 months after the specified Article 5a(23) and Article 5c(6) implementing acts enter into force; the Commission adopted the first five wallet implementing regulations on 28 November 2024 and describes rollout by the end of 2026.
Track timing by actor, provision, and implementing act. Wallet providers, private relying parties, QTSPs, attestation issuers, and Member States do not all share one launch date.
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 cited 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 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.
Use the column when the work involves a , wallet provider, wallet relying party, wallet certification, person identification data in the wallet, electronic attestations of attributes, or wallet data requests.
Use the original eIDAS column when the work involves notified eID schemes, trust-service classification, QTSP status, signatures, seals, timestamps, registered delivery, website authentication certificates, trusted lists, validation, preservation, or certificate revocation/status checks.
Use both columns when a wallet interaction relies on a trust service or qualified certificate, such as validating a qualified certificate, issuing a qualified attestation, or checking a trusted list as part of wallet ecosystem assurance.
Escalate for legal review when a relying party wants more attributes than the registered intended use supports, when a wallet or certificate status changes, or when a browser, supervisory body, trust list, or attestation issuer raises a concern.
Baseline eIDAS: electronic identification and trust services
The original eIDAS structure covers notified electronic identification schemes and trust services established in the Union. It defines trust services such as electronic signatures, seals, timestamps, registered delivery, certificate services for website authentication, and validation or preservation services.
For a product or procurement review, the baseline eIDAS questions are still concrete: is a trust service being provided, is it qualified or non-qualified, is a qualified certificate involved, does a trusted list confirm qualified status, and what legal effect is claimed for the signature, seal, timestamp, registered delivery service, website authentication certificate, or electronic document?
Keep evidence of the service classification and whether the provider has qualified status.
For qualified trust services, check the relevant trusted list entry rather than relying only on a contract or marketing claim.
For signatures and seals, keep validation evidence showing the certificate, status, signing time, and whether the claimed qualified legal effect is supported.
For website authentication, verify the certificate purpose and the identity information required for qualified website authentication certificates.
eIDAS 2.0: wallet, relying-party, and attestation expansion
The 2024 amendments add the as an electronic identification means that lets users store, manage, validate, and present person identification data and electronic attestations of attributes. The wallet workstream is therefore broader than login: it includes user control, selective disclosure, wallet certification, trust marks, relying-party authentication, and interfaces for requesting and validating data.
Relying parties become a distinct operational issue. A relying party that wants to rely on wallet data must be identified and authenticated, register the intended wallet use and data to be requested, keep that registration current, and validate person identification data and electronic attestations of attributes requested from wallets.
Treat wallet relying-party registration as a new onboarding control, not as ordinary customer authentication documentation.
Record the intended wallet use and the categories of data requested from users before product launch.
Build user-facing data request screens around selective disclosure and the minimum data needed for the specific authentication or service request.
Separate issuer evidence for person identification data, qualified electronic attestations of attributes, public-sector attestations, and non-qualified attestations.
Implementation evidence should not be merged blindly
Some evidence remains reusable across both columns, especially trusted-list checks, qualified-status records, certificate validation outputs, and provider due diligence. Other evidence is wallet-specific: relying-party registration, wallet certification status, ARF role mapping, requested-attribute records, user consent or approval screens, and logs showing what wallet data was requested and presented.
A useful comparison record should therefore say which eIDAS provision or wallet role each artifact supports. A certificate-policy mapping may support trust-service assurance, while a relying-party registration record supports wallet governance. Putting both in the same folder is fine; calling them the same control is not.
For trust services, keep provider status, conformity assessment, trusted-list, certificate, revocation, and validation records.
For wallet relying parties, keep registration evidence, intended-use descriptions, requested data categories, change notifications, and validation logic.
For attestations, keep the issuer type, attribute source, validity period, revocation or status-check method, and whether the attestation is qualified or issued by or on behalf of a public-sector authentic source.
For QWACs and other qualified certificates, keep certificate purpose, subject identity, domain or certificate-scope data, validity-status access, and the trusted-list status of the issuing qualified trust service provider.
Regulation (EU) 2024/1183 entered into force on 20 May 2024. It requires each Member State to provide at least one wallet within 24 months after the relevant Article 5a(23) and Article 5c(6) implementing acts enter into force. The Commission adopted the first five wallet implementing regulations on 28 November 2024, and its current public guidance describes Member State wallet provision by the end of 2026. That does not create one deadline for every relying party or integration.
Where timing matters operationally, track the exact trigger in the record: date of the implementing act, wallet certification status, relying-party registration readiness, trust-service audit cycle, certificate expiry, revocation publication, or trusted-list status change.
Use the regulation text for legal triggers that are stated as months after implementing acts.
Use Commission wallet pages for the current end-of-2026 Member State rollout context, not for country-specific production promises unless an official national or EU source states them.
For certificates and trust services, use lifecycle events such as audit, revocation, expiry, trusted-list update, and status-check availability rather than a generic annual review.
Do not convert pilot activity or ARF version changes into mandatory compliance deadlines unless the legal source supports that conversion.