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.
Supports the wallet, attestation, archiving, ledger, and supervision additions.
electronic attestation of attributes
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.
Explains wallet units, user control, selective disclosure, attestations, and presentations to relying parties.
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.
Supports the baseline eIDAS recognition model for notified electronic identification schemes.
notified electronic identification scheme
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.
Explains that organisations can request data from wallet users and must register in the Member State where established to become recognised service providers.
must register
Under the original eIDAS definition, a relying party is a natural or legal person that relies on electronic identification or a trust service. Baseline reliance can involve certificates, signatures, seals, timestamps, or trusted-list status; EUDI Wallet reliance was added by the 2024 amendment.
Defines relying party and baseline trust-service reliance concepts.
relying party
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.
Supports the legal effects, requirements, authentic-source verification, and wallet-interface rules for electronic attestations of attributes.
qualified electronic attestation of attributes
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.
Supports the original focus on electronic identification and trust services.
trust service
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.
Supports trust-service lifecycle timing such as the QTSP audit cycle, trusted-list updates, certificate validity, and revocation publication.
at least every 24 months
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.
Supports wallet supervisory actions, relying-party registration suspension or cancellation, and wallet suspension or cessation.
suspend or cancel the registration
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.
Supports trust-service supervision, audits, qualified-status withdrawal, trusted-list updates, and breach handling.
withdraw the qualified status
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.
Supports the amended web-browser and supervisory-body handling for qualified certificates for website authentication.
web-browser
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.
Supports QWAC definitions and Annex IV certificate content requirements.
qualified certificate for website authentication
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.
Supports wallet certification, notification, supervision, suspension, and remediation claims.
certified by the conformity assessment bodies
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.
Supports qualified trust service audits, supervisory bodies, qualified status, and trusted lists.
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.
Provides architecture context for wallet certification and risk management.
certification and risk management
Scope boundary
eIDAS 2.0 amendments
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.
Supports the wallet, attestation, archiving, ledger, and supervision additions.
electronic attestation of attributes
Original eIDAS framework
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.
Defines the role categories that should be separated during scoping.
relying party
Relationship between the regulations
eIDAS 2.0 amendments
Regulation (EU) 2024/1183 amends eIDAS; it does not create a stand-alone compliance silo. Wallet provisions are inserted into the same eIDAS framework.
Supports treating eIDAS 2.0 as amendments within the eIDAS framework.
Regulation (EU) No 910/2014
Identity presentation and recognition model
eIDAS 2.0 amendments
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.
Explains wallet units, user control, selective disclosure, attestations, and presentations to relying parties.
selective disclosure
Original eIDAS framework
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.
Supports the baseline eIDAS recognition model for notified electronic identification schemes.
notified electronic identification scheme
Operational implication
Wallet design reviews should test user control, presentation, selective disclosure, relying-party authentication, and wallet-unit evidence, not only eID assurance level labels.
Supports using wallet-specific architecture evidence rather than only eID assurance evidence.
Wallet Unit
Relying-party requirements
eIDAS 2.0 amendments
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.
Explains that organisations can request data from wallet users and must register in the Member State where established to become recognised service providers.
must register
Original eIDAS framework
Under the original eIDAS definition, a relying party is a natural or legal person that relies on electronic identification or a trust service. Baseline reliance can involve certificates, signatures, seals, timestamps, or trusted-list status; EUDI Wallet reliance was added by the 2024 amendment.
Defines relying party and baseline trust-service reliance concepts.
relying party
Operational implication
For wallet integrations, collect relying-party registration, requested attributes, validation method, and user-request records before treating the service as ready for production.
Supports registration and data-request evidence for service providers using wallets.
request data from wallet users
Attribute attestations and baseline trust services
eIDAS 2.0 amendments
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.
Supports the legal effects, requirements, authentic-source verification, and wallet-interface rules for electronic attestations of attributes.
qualified electronic attestation of attributes
Original eIDAS framework
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.
Supports the original focus on electronic identification and trust services.
trust service
Operational implication
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.
Explains attestation providers, authentic sources, relying-party requests, and wallet presentation of attributes.
attestations
Timing and deadlines
eIDAS 2.0 amendments
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.
Supports trust-service lifecycle timing such as the QTSP audit cycle, trusted-list updates, certificate validity, and revocation publication.
at least every 24 months
Operational implication
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.
Provides high-level Commission context for wallet rollout without replacing actor-specific legal triggers.
by 2026
Enforcement
eIDAS 2.0 amendments
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.
Supports wallet supervisory actions, relying-party registration suspension or cancellation, and wallet suspension or cessation.
suspend or cancel the registration
Original eIDAS framework
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.
Supports trust-service supervision, audits, qualified-status withdrawal, trusted-list updates, and breach handling.
withdraw the qualified status
Operational implication
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.
Supports keeping enforcement claims limited to official source supervisory mechanisms instead of unsupported penalty amounts.
supervisory body
Website-authentication certificates
eIDAS 2.0 amendments
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.
Supports the amended web-browser and supervisory-body handling for qualified certificates for website authentication.
web-browser
Original eIDAS framework
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.
Supports QWAC definitions and Annex IV certificate content requirements.
qualified certificate for website authentication
Operational implication
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.
Supports retaining QWAC issuer, subject, domain, validity, and status evidence.
certificate validity status
Certification and qualified-service assurance
eIDAS 2.0 amendments
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.
Supports wallet certification, notification, supervision, suspension, and remediation claims.
certified by the conformity assessment bodies
Original eIDAS framework
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.
Supports qualified trust service audits, supervisory bodies, qualified status, and trusted lists.
trusted lists
Operational implication
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.
Provides architecture context for wallet certification and risk management.
certification and risk management
Practical decision rule
Which column controls your eIDAS work?
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.
Supports the baseline eIDAS trust-service and certificate control points in the decision bullets.
qualified trust service
1
Section 1
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.
Defines the original eIDAS scope for electronic identification schemes, trust services, legal effects, qualified trust services, and trusted lists.
electronic identification and trust services
2
Section 2
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.
Amends eIDAS to add the European Digital Identity Wallet, wallet certification, relying-party rules, and electronic attestation of attributes provisions.
Explains the service-provider role in the EUDI Wallet ecosystem, including requesting data from wallet users and registering as a recognised service provider.
request data from wallet users
3
Section 3
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.
Provides official architecture context for wallet ecosystem roles, wallet units, relying parties, attestations, selective disclosure, certification, and risk management.
Architecture and Reference Framework
4
Section 4
Timeline facts to use carefully
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.
Primary legal source for the 2024 amendments that add the EUDI Wallet, relying-party rules, attestations of attributes, and wallet supervision.
Amends eIDAS to add the European Digital Identity Wallet, wallet certification, relying-party rules, and electronic attestation of attributes provisions.
Sets wallet-related legal triggers, including timing linked to implementing acts and Member State wallet provision.
Show 10 more
Supports the wallet, attestation, archiving, ledger, and supervision additions.
Shows the 2024 legal amendment to the eIDAS framework.
Supports treating eIDAS 2.0 as amendments within the eIDAS framework.
Commission guidance source for service providers that request data from wallet users and must register to become recognised in the wallet ecosystem.
Explains the service-provider role in the EUDI Wallet ecosystem, including requesting data from wallet users and registering as a recognised service provider.
Explains that organisations can request data from wallet users and must register in the Member State where established to become recognised service providers.
Show 1 more
Supports registration and data-request evidence for service providers using wallets.