eIDAS 2.0: Comprehensive EU Digital Identity and Trust Services Compliance Guide

eIDAS 2.0 (Regulation (EU) 2024/1183) is the substantially revised version of the original eIDAS Regulation (Regulation (EU) 910/2014), published in the Official Journal of the EU on April 30, 2024. The original eIDAS (2014) created the EU framework for electronic identification and trust services — establishing legal recognition for qualified electronic signatures, electronic seals, timestamps, and certified delivery services. eIDAS 2.0 significantly expands this framework by: (1) Introducing the EU Digital Identity Wallet (EUDIW): a personal digital identity tool that all EU member states must provide to their citizens and businesses. (2) Mandating acceptance: Key sectors (banking, telecoms, healthcare, government services, transport, energy, insurance) must accept the EUDIW from users who choose to use it. (3) Expanding trust services: New trust service categories including electronic attestation of attributes, electronic archiving, electronic ledger services, and management of remote electronic signature/seal creation devices. (4) Strengthening QTSP oversight: More prescriptive security requirements, updated conformity assessment processes, and harmonized supervisory powers. eIDAS 2.0 represents the EU's ambition to give every EU citizen a secure, universally accepted digital identity that works across borders, sectors, and devices.

eIDAS 2.0 makes six major changes relative to the original eIDAS 1.0 framework: (1) EU Digital Identity Wallet: The single largest addition. eIDAS 1.0 had no wallet concept; eIDAS 2.0 creates a mandatory EUDIW that member states must issue and key sectors must accept. (2) Attribute attestation: eIDAS 2.0 introduces qualified electronic attestation of attributes (QEAA) as a new trust service — enabling verified, privacy-preserving sharing of credentials (age, qualifications, health data) without exposing underlying identity documents. eIDAS 1.0 had no equivalent. (3) New trust service categories: Electronic archiving, electronic ledger (blockchain notarization), and management of remote signature creation devices are added as regulated trust services. (4) Cross-border acceptance mandate: eIDAS 1.0 required mutual recognition only for notified eID schemes; eIDAS 2.0 extends mandatory acceptance to the EUDIW and requires designated sector relying parties to accept it. (5) Stronger security requirements: QWAC and QTSP security standards are upgraded; minimum assurance levels for identity proofing at wallet issuance are raised to "high." (6) Supervisory powers: Supervisory bodies gain new investigative and enforcement tools, including the ability to impose temporary suspension of qualified trust services pending investigation.

The EU Digital Identity Wallet (EUDIW) is a digital application — typically a smartphone app — that allows EU citizens and businesses to store and present their digital identity and personal attributes in a secure, portable, and privacy-preserving way. Key features of the EUDIW: (1) Identity storage: National identity credential (analogous to a digital passport or ID card) issued and backed by the member state. (2) Attribute attestation: Store verified credentials from qualified providers — degree certificates, driving licences, professional qualifications, health records, insurance documents. (3) Selective disclosure: Citizens can choose exactly which attributes to share with a service — for example, proving you are over 18 without revealing your date of birth or name. (4) Cross-border use: Works across all 27 EU member states; accepted by online services and physical readers. (5) Strong authentication: Wallet authentication meets "high" assurance level under eIDAS 2.0 — the strongest level for digital identity. (6) Offline capability: The EUDIW specification includes an ISO 18013-5 mDL (mobile driving licence) interface enabling offline verification via NFC/Bluetooth. The EUDIW must be made available free of charge to all EU citizens and businesses who wish to use it, with member states obligated to issue it by November 2026. Technical specifications are defined in the Architecture and Reference Framework (ARF) published by the European Commission.

eIDAS 2.0 Article 5a(5) establishes mandatory acceptance of the EUDIW for "relying parties" in designated sectors. The mandatory acceptance sectors are: (1) Banking and financial services: Banks, payment service providers, and investment firms must accept EUDIW for remote customer onboarding and identity verification (replacing or supplementing current eKYC methods). (2) Telecommunications: Electronic communications service providers must accept EUDIW for subscriber identity verification. (3) Air transport: Airlines and airports for passenger identity verification. (4) Rail transport: Railway operators accepting EUDIW for ticketing and identity verification. (5) Healthcare: Healthcare professionals and facilities for patient identity verification and accessing health records. (6) Government services: All digital public services (tax, benefits, permits) must accept EUDIW. (7) Energy utilities: Energy service providers subject to smart metering regulations. (8) Insurance: Insurance service providers for remote customer identification. Acceptance is "mandatory" in the sense that these service providers must build the technical capability to accept EUDIW from users who choose to present it. They cannot require users to use the EUDIW (other options must remain available), but they cannot refuse to accept it when presented. Implementation deadline: aligned with the EUDIW availability date — once a member state issues its wallet, relying parties in these sectors must be ready to accept it.

A Qualified Trust Service Provider (QTSP) is a trust service provider that has been granted qualified status by its national supervisory body following assessment against strict security and reliability standards. eIDAS 2.0 expands the range of qualified trust services that QTSPs can provide: (1) Qualified electronic signatures (QES): The highest-level digital signature, legally equivalent to a handwritten signature across the EU. Requires identity verification and signing with a qualified signature creation device. (2) Qualified electronic seals: For legal entities (organizations) to authenticate documents and data. (3) Qualified electronic timestamps: Proving data existed at a specific point in time. (4) Qualified electronic registered delivery services: Certified electronic equivalent of registered postal mail. (5) Qualified website authentication certificates (QWAC): Browser-trusted certificates with enhanced identity verification — must now be accepted by major browsers (a key change from eIDAS 1.0 where browser vendors blocked QWACs). (6) Qualified electronic attestation of attributes (QEAA): New in eIDAS 2.0 — verified attribute credentials for the EUDIW. (7) Qualified electronic archiving services: New — providing legally compliant long-term storage. QTSPs are listed on national Trusted Lists maintained by each member state supervisory body. ENISA publishes EU-wide security requirements for QTSP conformity assessment.

QTSP accreditation (referred to as "granting of qualified status") follows a defined process: (1) Conformity Assessment Body (CAB) audit: The applicant must engage an accredited CAB (conformity assessment body) recognized by the national supervisory body. The CAB conducts a technical audit against ETSI standards (typically ETSI EN 319 401, 319 411-2, and service-specific standards). (2) Audit report submission: The CAB submits the conformity assessment report to the national supervisory body. (3) Supervisory body assessment: The supervisory body reviews the CAB report and may conduct its own investigation. Decision period: typically 3 months. (4) Qualified status granted: If the application meets requirements, the supervisory body adds the QTSP to the national Trusted List with "qualified" status for the specific trust services approved. (5) Ongoing audits: QTSPs must undergo conformity assessment at least every 24 months (reduced to 24 months from 36 months in eIDAS 1.0). More frequent audits may be required following incidents. ETSI standards applicable to QTSPs under eIDAS 2.0: ETSI EN 319 401 (General Policy Requirements for TSPs), ETSI EN 319 411-1/2 (certificate issuance), ETSI EN 319 421 (timestamps), ETSI EN 319 521 (registered delivery), ETSI TS 119 431 (remote signing). New ETSI standards for QEAA and EUDIW-related services are being developed.

Businesses that accept electronic identification or use digital signatures are "relying parties" under eIDAS 2.0, with obligations that depend on their sector and the type of interaction: (1) Mandatory-acceptance sectors (banking, telecoms, transport, healthcare, utilities, insurance, government): Must build technical capability to accept EUDIW by November 2026. This means integrating with the EUDIW OpenID4VP (presentation protocol) defined in the ARF. (2) Online service providers generally: While acceptance of the EUDIW is only mandatory in designated sectors, any online service wishing to offer EUDIW-based login can integrate with the OpenID4VP protocol. (3) Using QES in contracts: Any business using qualified electronic signatures for contracts, agreements, or official documents must accept QES from any EU QTSP-issued certificate (cross-border recognition is legally mandated). (4) Accepting QWACs: Under eIDAS 2.0, browsers must accept and visually distinguish QWACs — websites using QWACs for HTTPS must ensure their certificates are from an EU Trusted List QTSP. (5) Attribute verification: Businesses conducting age verification, professional qualification checks, or identity verification in regulated contexts should assess whether EUDIW-based QEAA can replace or supplement existing verification methods. Businesses in mandatory-acceptance sectors should begin EUDIW technical integration projects in 2025, targeting readiness before the November 2026 wallet availability date.

Trust service providers (TSPs) — both qualified and non-qualified — have defined obligations under eIDAS 2.0: (1) Non-qualified TSPs: Must notify the national supervisory body before commencing operations. Must implement security measures proportionate to the risk. Must notify the supervisory body and users within 24 hours of any breach affecting the trust service. Must maintain records for 20 years after service provision. (2) Qualified TSPs (QTSPs): All non-qualified obligations plus: maintain qualified status via regular conformity assessments (every 24 months); implement security measures meeting ETSI standards; maintain termination plans for orderly service shutdown; subscribe to national TSP liability insurance or maintain financial reserves; designate a single point of contact for supervisory body communication. (3) New eIDAS 2.0 trust service obligations: QTSPs providing QEAA (electronic attestation of attributes) must verify attribute sources with the issuing authority before attesting. TSPs providing remote signature management must implement the security requirements of ETSI TS 119 431. (4) Supervisory cooperation: TSPs must cooperate with national supervisory body audits, investigations, and requests for information. (5) Cross-border recognition: QTSPs are automatically recognized across all 27 EU member states via the Trusted List mechanism — they do not need separate national registration in each country where they operate.

The EU Digital Identity Wallet must meet rigorous security requirements defined in the Architecture and Reference Framework (ARF) published by the European Commission: (1) Identity assurance level: "High" assurance level under eIDAS 2.0 — the strongest category. This requires identity proofing with physical presence (or equivalent remote process), verification of identity documents against authoritative sources, and binding of the identity to the wallet device with cryptographic keys. (2) Wallet secure cryptographic device (WSCD): The private keys protecting the wallet's identity credentials must be stored in a hardware-backed secure element (e.g., device TPM, embedded Secure Element, or remote HSM). Keys must never leave the secure element unencrypted. (3) Selective disclosure: The wallet must implement selective disclosure based on Zero-Knowledge Proofs or SD-JWT (selective disclosure JSON Web Tokens), enabling attribute presentation without exposing unnecessary data. (4) Device binding: The wallet must be bound to the specific device and user — transfer of credentials to another device requires full re-enrollment. (5) Attestation: The wallet itself must obtain certification from the member state as a valid EUDIW implementation meeting ARF specifications. Third-party EUDIW apps (beyond the official member state app) may be possible in some frameworks, but must achieve equivalent certification. (6) Privacy-by-design: No single tracking entity (not even the wallet issuer) can correlate wallet presentations across different relying parties — technical measures including unique presentation tokens prevent cross-service tracking.

Cross-border recognition is a foundational principle of eIDAS 2.0, significantly strengthened relative to eIDAS 1.0: (1) EUDIW cross-border recognition: Any EU member state's EUDIW must be accepted across all other 27 member states. A German citizen's EUDIW must work with French government services, Italian hospitals, and Spanish banks — and vice versa. The ARF defines common technical protocols (OpenID4VP for presentation, OpenID4VCI for credential issuance) ensuring technical interoperability. (2) Qualified Trust Service cross-border recognition: Qualified trust services (QES, QEA, QEAA) provided by any EU QTSP are legally recognized across the entire EU without additional procedures. A qualified electronic signature from a Polish QTSP has the same legal standing as a handwritten signature in Germany, Spain, or any other member state. (3) Notified eID scheme recognition: Under eIDAS 1.0, member states had to "notify" their national eID schemes for cross-border recognition — and uptake was limited. eIDAS 2.0 creates a more streamlined recognition process and makes the EUDIW the primary cross-border identity instrument. (4) Third-country interoperability: The ARF includes provisions for potential mutual recognition agreements with non-EU countries, though formal arrangements require bilateral or multilateral treaties. Countries like the UK, Norway, Iceland, and Liechtenstein (EEA members) have separate arrangements. Cross-border recognition removes a major barrier to digital single market participation — businesses can accept a single digital identity from customers across the EU.

eIDAS 2.0 has several key compliance milestones: (1) April 30, 2024: Regulation (EU) 2024/1183 published in the Official Journal of the EU. eIDAS 2.0 entered into force. (2) April 2025: QTSP compliance with new eIDAS 2.0 requirements. QTSPs must apply updated ETSI standards and comply with new security obligations. Supervisory bodies begin applying eIDAS 2.0 standards in conformity assessments. (3) November 2026: EU Digital Identity Wallet must be made available by all member states to EU citizens and businesses who wish to use it. Large-scale pilots (LSPs) — funded under the Digital Europe Programme — are testing EUDIW implementations in real-world use cases (mobile driving licences, education credentials, payment, health) to validate ARF specifications before this deadline. (4) Mandatory acceptance sectors: Within a reasonable period after wallets are available (member states specify exact timelines), relying parties in banking, telecoms, transport, healthcare, government, utilities, and insurance must accept the EUDIW. (5) Current status (May 2026): The four EU EUDIW large-scale pilot projects (POTENTIAL, EWC, DC4EU, NOBID) are in late-stage testing. Member states are in various stages of national EUDIW implementation. Some member states (Netherlands, Germany, Spain) are more advanced than others. IT teams building EUDIW integrations should target Q1–Q2 2026 for readiness.

eIDAS 2.0 mandates EUDIW acceptance in specific sectors where identity verification is a core service requirement. The designated mandatory-acceptance sectors: (1) Banking and financial services: For customer identification in account opening, loan applications, and digital banking — enabling compliant eKYC without physical document inspection. (2) Telecommunications: For subscriber registration under electronic communications law. (3) Air transport: For passenger identification at check-in and boarding. (4) Rail transport: For passenger services where identity is required. (5) Healthcare: For patient identity verification in national digital health systems and cross-border patient summaries under the European Health Data Space (EHDS). (6) Public administration: All digital public services (national and local government) are within mandatory acceptance scope. (7) Energy: Smart meter and utility service providers under applicable EU directives. (8) Insurance: For remote policy issuance and claims processing requiring identity verification. The mandatory acceptance obligation means service providers in these sectors must integrate the OpenID4VP protocol (as defined in the ARF) into their authentication and onboarding flows. This is a significant technical project for large financial institutions and healthcare providers — integration timelines typically run 12–18 months from specification finalization. EUDIW acceptance does not replace existing identity methods; users must have the option to use the EUDIW, not be required to use it exclusively.

eIDAS 2.0 and GDPR operate in parallel for digital identity and trust services — both apply to EUDIW issuers, QTSPs, and relying parties: (1) Data minimization: eIDAS 2.0's selective disclosure architecture directly implements GDPR's data minimization principle. The EUDIW enables attribute-level disclosure (share only "over 18 = true" rather than full date of birth), technically enforcing minimal data transfer. (2) Lawful basis: Identity verification using the EUDIW requires a lawful basis under GDPR. For mandatory-acceptance sectors (banking, healthcare), "legal obligation" or "contract" provides the basis. For optional EUDIW-based login, "consent" or "legitimate interests" may apply. (3) Data controller responsibilities: Relying parties receiving identity assertions from the EUDIW are data controllers for the personal data they process — they retain GDPR obligations for retention, rights fulfilment, and breach notification even if the identity assertion came from the wallet. (4) Wallet issuer obligations: Member states and their wallet operators are data controllers or processors for wallet usage data. The ARF mandates that wallet issuers cannot track users' presentations to relying parties — a technical privacy guarantee backed by GDPR's prohibition on unlawful processing. (5) Cross-border data flows: The EUDIW operates entirely within the EU digital identity ecosystem — no third-country data transfers are inherent to its operation, aligning with GDPR transfer restriction requirements. Organizations implementing EUDIW acceptance should conduct a DPIA (Data Protection Impact Assessment) for the new identity processing flows.

The Architecture and Reference Framework (ARF) is the technical specification document published by the European Commission that defines how the EUDIW must work at an implementation level. Key ARF technical components: (1) OpenID4VCI (Verifiable Credential Issuance): The protocol used by credential issuers (member state wallet issuers, QEAA providers) to issue credentials into the EUDIW. Based on the OpenID Foundation's OID4VCI draft standard. (2) OpenID4VP (Verifiable Presentation): The protocol used by the wallet to present credentials to relying parties for verification. Relying parties must implement an OpenID4VP verifier to accept EUDIW presentations. (3) SD-JWT (Selective Disclosure JWT): The primary credential format for most EUDIW credentials (including mdoc/ISO 18013-5 for mobile driving licences). Enables selective disclosure of individual attributes. (4) ISO 18013-5 (mdoc): The international standard for mobile driving licences, used for proximity (offline) EUDIW presentations via NFC/Bluetooth. (5) EUDI Wallet Trust Model: Defines how wallet instances are certified, how credential issuers are trusted, and how relying parties validate presentations through a chain of trust rooted in member state certification. (6) High assurance identity proofing: Aligns with ETSI TS 119 461 for remote identity proofing at high assurance level. The ARF is a living document updated iteratively based on large-scale pilot feedback. Developers building EUDIW integrations should track the European Commission's GitHub repository for ARF updates and EUDIW reference implementation code.

Notified eID schemes are national electronic identification systems that have been formally notified to the European Commission, making them legally recognized across the EU for cross-border identity verification. Under eIDAS 1.0, this was the primary cross-border identity mechanism — but uptake was limited (only a handful of member states notified schemes, and cross-border usage was low). eIDAS 2.0 retains and simplifies the notification mechanism while adding the EUDIW as the primary pan-EU instrument: (1) Continued legal framework: Existing notified eID schemes (e.g., Swedish BankID, German BundID, Italian SPID) remain valid and cross-border recognized under eIDAS 2.0. (2) Simplified notification: eIDAS 2.0 streamlines the notification process, potentially enabling more member states to notify their national eID solutions. (3) Assurance levels: Three levels — low, substantial, high — define the strength of identity verification and authentication required. Public sector services requiring high-assurance authentication must accept EUDIW and notified schemes at "high" level. (4) Relationship with EUDIW: The EUDIW is not a notified eID scheme — it is a new, distinct identity instrument operating under a separate regulatory framework. They coexist: users may use their notified national eID or their EUDIW, and service providers must accept both where applicable. The practical significance of notified schemes will likely diminish as EUDIW adoption grows, but they remain legally relevant throughout the eIDAS 2.0 transition period.

App developers — both mobile and web — face significant new considerations under eIDAS 2.0: (1) EUDIW integration (mandatory-acceptance sectors): Developers building apps for banking, healthcare, insurance, telecom, government, or transport services must implement OpenID4VP-based EUDIW acceptance. This requires: integrating an OpenID4VP verifier library, defining which wallet credentials are accepted for which user actions, handling selective disclosure attribute presentation, and managing trust anchors from member state wallet registries. (2) EUDIW integration (voluntary): Developers of any app wishing to offer EUDIW-based login — as an alternative to password or social login — can implement OpenID4VP. The EUDIW provides strong-assurance authentication without the developer needing to operate their own identity infrastructure. (3) QES integration: Apps requiring document signing can integrate with cloud-based QES services via QTSP APIs (e.g., remote signature services using ETSI TS 119 432 protocol). QES integration removes the need for users to obtain physical smart cards. (4) QWAC certificate display: Web app developers must ensure their HTTPS infrastructure is compatible with QWACs if their sector is required to present QTSP-issued certificates. Browsers will visually distinguish QWAC-secured sites. (5) Attribute verification: Apps that currently verify ages, qualifications, or professional licences can leverage QEAA from QTSPs issued into the EUDIW — reducing identity proofing overhead. Developer resources: The European Commission publishes open-source reference implementations of OpenID4VCI and OpenID4VP on GitHub, and the ARF includes integration guides and test vectors.

eIDAS 2.0 Article 8 defines three assurance levels for electronic identification — low, substantial, and high — based on the strength of the identity proofing and authentication processes: (1) Low assurance: Basic identity verification with limited confidence the person is who they claim to be. Suitable for low-risk transactions (newsletter subscriptions, non-sensitive preferences). (2) Substantial assurance: Identity proofed and verified against a reliable source (e.g., government database lookup); authentication using at least one factor resistant to remote compromise. Suitable for medium-risk transactions (tax returns, basic public services). (3) High assurance: Full identity proofing with physical presence or equivalent; binding to a unique, non-replicable authentication credential (e.g., hardware-backed key in a secure element); multi-factor authentication resistant to both remote and physical attack. The EUDIW operates at high assurance level. eIDAS 2.0's mandatory acceptance framework requires high-assurance identification for: access to national electronic health records; signing qualified electronic signatures; accessing personal social security data; completing regulated KYC processes in banking and insurance. High assurance level also requires that the authentication credential (the EUDIW or notified eID) cannot be replicated, delegated, or presented without the user's active involvement — meaning biometric authentication or device PIN at time of presentation.

Qualified electronic attestation of attributes (QEAA) is a new trust service category introduced in eIDAS 2.0, enabling QTSPs to issue verified, tamper-proof credential attestations that can be stored in the EUDIW and selectively disclosed to relying parties. How QEAA works: (1) Attribute source: An authoritative source (e.g., university, professional body, government registry, insurer) provides verified attribute data to a QTSP. (2) QTSP attestation: The QTSP issues a digitally signed credential (in SD-JWT or ISO mdoc format) attesting that a specific person possesses verified attributes — e.g., "holds a valid pharmacist licence in Germany" or "has completed anti-money laundering training (date)." (3) Wallet storage: The QEAA is stored in the user's EUDIW, cryptographically bound to the wallet. (4) Selective disclosure: When the user presents the QEAA to a relying party, they can disclose only the specific attributes needed — e.g., "licensed professional = true" without revealing the licence number or issuing authority. (5) Verification: The relying party verifies the QTSP's digital signature against the national Trusted List, confirming the attestation is authentic and current. Use cases: professional qualification verification (doctors, lawyers, engineers), educational credentials (diplomas, certifications), health insurance status, driving licence details, social security eligibility. QEAA enables a "once only" data sharing principle — users retrieve their attributes once from authoritative sources and present them repeatedly without repeated government interactions.

eIDAS 2.0 has significant implications for organizations and trust service providers operating existing Public Key Infrastructure (PKI): (1) QWAC browser acceptance: Under eIDAS 1.0, browser vendors (Google, Apple, Mozilla, Microsoft) refused to give special treatment to QWACs in their root certificate programs — meaning QWACs appeared identical to ordinary DV/OV TLS certificates. eIDAS 2.0 introduces a legal obligation for browser vendors to "recognise and give a distinct display to websites using QWACs" — a major change that may alter how HTTPS certificate trust is presented to users. (2) CA/Browser Forum impact: The CA/Browser Forum (which governs commercial TLS certificate issuance) has historically operated independently of eIDAS. eIDAS 2.0's browser mandate may create tension between EU law obligations and Forum baseline requirements — an active area of regulatory and technical debate as of 2026. (3) Qualified certificates updated: eIDAS 2.0 updates the technical profiles for Qualified Certificates for Electronic Signatures (QCeSig) and Electronic Seals (QCeSeal) to align with current ETSI standards. Organizations using QES in existing workflows must verify their certificates remain valid under updated profiles. (4) Remote signing growth: eIDAS 2.0's formal recognition of remote signing (cloud HSM-based QES) and QTSP-managed signing services accelerates the shift from smart-card-based QES to server-side signing. This is more practical for high-volume document workflows. Organizations with existing PKI programs should audit their certificate portfolios against eIDAS 2.0 requirements and plan QTSP contract renewals aligned with the updated standards.

Several misconceptions about eIDAS 2.0 circulate in technical and business communities: (1) "The EUDIW replaces national ID cards" — False. The EUDIW is a digital complement to physical identity documents; member states are not required to eliminate physical IDs. The wallet stores a digital representation bound to physical identity documents. (2) "All websites must accept the EUDIW" — False. Mandatory acceptance applies only to designated relying party categories (banking, telecoms, healthcare, transport, government, utilities, insurance). Other websites may voluntarily integrate but are not required to. (3) "eIDAS 2.0 creates a centralized EU identity database" — False. The EUDIW is a decentralized architecture: identity data is stored on users' devices, not in a central EU database. Member states issue the wallet credentials but do not have access to where users present them. (4) "QTSP certificates automatically replace all digital signatures" — False. eIDAS 2.0 maintains multiple signature levels (simple, advanced, qualified); qualified electronic signatures (QES) have legal equivalence to handwritten signatures, but lower-level signatures remain valid for lower-risk use cases. (5) "eIDAS 2.0 violates GDPR because the government tracks wallet use" — The ARF explicitly prohibits wallet issuers from tracking presentations; selective disclosure prevents attribute correlation across relying parties. The architecture is privacy-by-design. (6) "eIDAS 2.0 is the same as eIDAS 1" — Substantively different: EUDIW, QEAA, browser QWAC mandate, expanded trust services, and stronger QTSP oversight are all new. Organizations relying on eIDAS 1 analysis should re-evaluate their compliance position.