eIDAS 2.0 EUDI Wallet: Sovereign Digital Identity for European Organisations

The eIDAS 2.0 Regulation (EU) 2024/1183, published in the Official Journal of the European Union on 30 April 2024, replaces the original eIDAS framework with a legally binding obligation for public-sector and regulated-sector services to accept the European Digital Identity (EUDI) wallet as a means of authentication and attribute sharing. For compliance officers, CISOs, and IT decision-makers, this is not a distant policy aspiration: it is a hard deadline that redefines which identity infrastructure is legally acceptable for regulated digital services across the EU.

What eIDAS 2.0 Actually Requires from Regulated Organisations

The regulation goes beyond a technical specification: it creates enforceable obligations for relying parties. Article 5a of Regulation (EU) 2024/1183 defines the EUDI wallet as a personal digital identity solution that must be offered by every member state and accepted by certain categories of service provider.

Sectors explicitly named in the regulation include public authorities providing services that require strong authentication, providers of very large online platforms under the Digital Services Act, banks subject to Know Your Customer requirements under the Anti-Money Laundering directives, and healthcare providers. For each of these categories, refusing a valid EUDI wallet presentation will constitute non-compliance once the implementing acts are in effect, regardless of whether the organisation already uses a legacy identity federation.

The European Commission estimates that more than 80% of EU citizens should have access to a EUDI wallet by 2030, as set out in the Digital Decade Policy Programme (European Commission, 2022). This is not a niche tool: it is positioned as the default cross-border identity layer for the EU’s digital single market.

Why US-Controlled Identity Providers Create Jurisdictional Exposure

Replacing Sign in with Google or Microsoft Entra External ID is not primarily a technical preference: it is a jurisdictional risk decision.

Both Microsoft and Google are incorporated in the United States and are therefore subject to the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) and FISA Section 702. Under the CLOUD Act, US federal law enforcement can compel a US provider to disclose data it controls, regardless of where those servers physically sit. When authentication tokens, session assertions, and user-attribute data flow through Entra External ID or Google Identity Platform infrastructure, that identity data enters a legal environment where a foreign government can request access without the data subject’s knowledge or consent.

Ursula von der Leyen, President of the European Commission, stated at the launch of the eIDAS 2.0 framework: “The European Digital Identity Wallet will give Europeans a secure and easy way to prove who they are and share digital documents, without having to rely on commercial providers from outside the EU.” The political intent is explicit: sovereignty over identity is a prerequisite for digital sovereignty in general.

ENISA’s Threat Landscape 2024 report identified identity and credential abuse as the leading initial-access vector in incidents affecting public administration across EU member states. Delegating authentication infrastructure to providers outside EU jurisdiction compounds this risk: a compromise or a lawful disclosure order at the provider level exposes all federated relying parties simultaneously.

The Technical Architecture of the EUDI Wallet and How It Integrates with Existing Systems

The EUDI Wallet Architecture and Reference Framework (ARF), maintained openly at the European Commission’s GitHub repository under the EU Open Source Strategy, defines the protocol stack and data model that all compliant wallet implementations must follow.

Protocol layer: OpenID4VP and OpenID4VCI

The ARF specifies OpenID for Verifiable Presentations (OpenID4VP) as the presentation protocol between a wallet and a relying party, and OpenID for Verifiable Credential Issuance (OpenID4VCI) as the issuance protocol between a qualified issuer and the wallet. Both extend the OpenID Connect family, which means that organisations running existing OIDC-compatible identity providers or SAML federations can integrate wallet acceptance through a conformant identity broker without replacing their entire IAM stack.

In practice, the migration path for a public authority running a SAML federation looks like this: a sovereign identity broker is deployed between the SAML service providers and the EUDI wallet presentation endpoint. The broker speaks OpenID4VP toward the wallet and SAML toward the legacy relying parties. This broker must itself run on EU-controlled infrastructure to avoid reintroducing the jurisdictional exposure that the wallet is meant to eliminate.

Credential format: SD-JWT and selective disclosure

The ARF mandates SD-JWT (Selective Disclosure JSON Web Token) as the baseline credential format. SD-JWT allows a wallet holder to present only the specific claims a verifier requires. A healthcare portal that needs only proof of age and professional registration can receive precisely those attributes, without the wallet disclosing the holder’s full national identity number or address.

For full unlinkability, meaning a verifier cannot correlate multiple presentations from the same wallet holder across services, SD-JWT alone is insufficient. The eIDAS 2.0 regulation explicitly requires that wallets prevent tracking of users across relying parties. This requirement pushes technically ambitious implementations toward cryptographic mechanisms such as BBS+ signatures or similar zero-knowledge proof constructions, where each presentation generates a mathematically independent proof derived from the same underlying credential. The ARF’s open-source reference implementation, published under the EU Open Source Strategy, includes experimental ZKP support alongside the mandatory SD-JWT baseline.

Assessing and Migrating Away from Federations with Jurisdictional Exposure

A practical audit of identity federation exposure should examine three layers: where the identity provider’s compute and storage run, under which country’s laws the provider is incorporated, and which attributes flow through the provider’s infrastructure during authentication.

The migration path from a US-controlled federation to a sovereign identity broker is sequential rather than disruptive. First, deploy a conformant EU-hosted broker such as Keycloak or a nationally certified equivalent. Second, configure the broker to accept OpenID4VP presentations from EUDI wallets. Third, connect existing SAML or OIDC relying parties to the broker. Fourth, decommission the dependency on the US provider once all relying parties have migrated. This sequence avoids service interruption while progressively closing the jurisdictional gap.

Post-Quantum Certificate Migration and Long-Term Archiving under ETSI EN 319

Qualified trust services under eIDAS 2.0, specifically qualified electronic signatures, qualified electronic seals, and qualified timestamps, must comply with ETSI EN 319 401, which sets the general policy requirements for trust service providers. The current generation of qualified certificates relies on RSA and ECDSA algorithms. A cryptographically relevant quantum computer would render these algorithms insecure, an event that NIST, ENISA, and BSI Germany all treat as a credible risk within a 10 to 15-year horizon.

The ETSI Technical Committee ESI has stated: “Trust services must be built on standards that guarantee long-term integrity. The ETSI EN 319 series provides the technical baseline that makes qualified signatures verifiable across borders and across decades.” The EN 319 series already accommodates algorithm agility, but trust service providers must publish updated certificate policies that explicitly include approved post-quantum algorithms such as ML-DSA (CRYSTALS-Dilithium) once these are incorporated into ETSI profile standards.

Long-term archiving creates a specific vulnerability known as “harvest now, decrypt later.” Adversaries collect today’s encrypted or signed documents and decrypt them once quantum capability exists. For documents that must remain legally valid for decades, such as notarial acts, property registers, or medical records, organisations must apply qualified timestamps from a post-quantum timestamp authority before the original signature’s cryptographic assurance expires. This is an active compliance obligation, not a future concern.

The IBM Cost of a Data Breach Report 2024 recorded the average breach cost at USD 4.88 million, the highest figure ever measured. For regulated-sector organisations holding identity records and signed documents, breaches that expose both identity data and the cryptographic keys protecting long-term archives carry compounded liability under GDPR, NIS-2, and sector-specific regulations such as DORA.

Privacy by Design: Minimal Disclosure as a Legal Obligation

eIDAS 2.0 embeds GDPR’s data minimisation principle directly into the wallet specification. Article 5a(5) requires that the wallet must not allow issuers or relying parties to track the user’s use of the wallet across different services. This is a stricter requirement than anything imposed on current federated identity systems, where session cookies and shared identifiers routinely enable cross-service profiling.

In operational terms, this means that a relying party’s wallet integration cannot request more attributes than are strictly necessary for the specific transaction. A verification of professional qualification for a healthcare portal must not also retrieve the user’s home address unless address verification is independently required by the applicable sectoral law. Compliance officers should document the minimum attribute set for each integration scenario and include this in the organisation’s records of processing activities under GDPR Article 30.

FAQ

By what date must public-sector services accept EUDI wallets under eIDAS 2.0?

Regulation (EU) 2024/1183 requires relying parties in designated sectors to accept EUDI wallets within 24 months of the relevant implementing acts entering into force. Those implementing acts are expected in 2024-2025, placing the practical acceptance deadline around late 2026 to early 2027.

Does using Microsoft Entra External ID for regulated services create CLOUD Act exposure?

Yes. Microsoft is a US-incorporated entity subject to the CLOUD Act. Authentication tokens, session data, and user-attribute assertions flowing through Entra External ID infrastructure enter a legal environment where US authorities can compel disclosure regardless of server location. A sovereign identity broker running on EU-controlled infrastructure eliminates this vector.

What is OpenID4VP and why does it matter for EUDI wallet integration?

OpenID for Verifiable Presentations (OpenID4VP) is the protocol defined in the ARF for presenting credentials from a wallet to a relying party. It extends the OpenID Connect family so that OIDC-capable applications can accept wallet credentials without replacing their entire IAM stack. OpenID4VCI is the complementary protocol for loading credentials into the wallet from a qualified issuer.

How do qualified electronic signatures under eIDAS 2.0 interact with post-quantum cryptography?

Current qualified certificates use RSA or ECDSA, which are vulnerable to quantum decryption. ETSI EN 319 401 and the broader EN 319 series support algorithm agility, and trust service providers must migrate to post-quantum algorithms such as ML-DSA. For long-term archives, qualified timestamps must be renewed with post-quantum algorithms before the original signature’s cryptographic assurance expires.

Can an organisation implement selective disclosure in a EUDI wallet without zero-knowledge proofs?

Partially. SD-JWT, the ARF’s mandatory baseline format, enables attribute-level selective disclosure. However, full unlinkability across presentations requires ZKP-based formats such as BBS+ signatures. Because eIDAS 2.0 explicitly prohibits cross-service tracking, organisations handling high-sensitivity attributes should plan for ZKP support as the standard matures in the ARF’s open-source reference implementation.