eIDAS 2.0 & the EU Digital Identity Wallet: What It Means for Your Auth Stack

TL;DR

• eIDAS 2.0 (Regulation (EU) 2024/1183) amends the original 2014 framework and obliges every EU member state to offer citizens an EU Digital Identity Wallet (EUDI Wallet).
• The wallet stores government-grade identity and verifiable credentials (VCs); relying parties request and verify them using open protocols — OID4VCI, OID4VP, and SD-JWT-VC — not bespoke APIs.
• Large platforms must accept the wallet for login where strong user authentication is required; the obligation phases in after the Architecture and Reference Framework (ARF) and implementing acts settle.
• Wallet-readiness and post-quantum signing are converging concerns: credentials are long-lived, so the signatures that protect them need to outlast the harvest-now-forge-later horizon.

What is eIDAS 2.0 authentication?

eIDAS 2.0 authentication is identity verification built on Regulation (EU) 2024/1183, which extends the original eIDAS framework and requires every member state to issue an EU Digital Identity Wallet. Instead of a password or a third-country login, a user presents cryptographically signed verifiable credentials from the wallet, and a relying party verifies them with open standards — establishing legally recognised, privacy-preserving authentication across the EU.

The first eIDAS Regulation ((EU) No 910/2014) standardised electronic identification and trust services — qualified signatures, seals, timestamps. It worked for cross-border e-government, but adoption stayed thin and there was no citizen-facing tool. eIDAS 2.0, published in the Official Journal on 30 April 2024 and in force since 20 May 2024 (EUR-Lex 32024R1183), fixes that gap with one big idea: a personal wallet that every citizen, resident, and business can use to prove attributes online and offline.

CAI Technology is not a government authority. This article explains the regulation and the open protocols around it so engineering and compliance teams can plan; it is not legal advice.

What does eIDAS 2.0 change?

Three shifts matter for anyone running an authentication stack.

1. A mandatory wallet. Each member state must provide at least one EUDI Wallet, free for natural persons, by the deadlines set in the regulation. The wallet is the user’s container for a Person Identification Data (PID) credential plus optional electronic attestations of attributes (diplomas, professional licences, bank or mobile-subscriber attributes).

2. Mandatory acceptance. Where strong user authentication is legally required — and explicitly across regulated sectors and very large online platforms designated under the Digital Services Act — relying parties must accept the wallet as a means of identification. You cannot force users into your proprietary login if they choose to present a wallet credential.

3. Selective disclosure and user control. The regulation bakes in data minimisation: a user proves they are over 18 without revealing a birth date, or proves residency without exposing a full address. This is a legal requirement, not a nice-to-have, and it shapes the credential formats below.

The technical contract for all of this lives in the Architecture and Reference Framework (ARF), maintained in the open at github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework. The ARF is where the Commission, member states, and the reference implementation pin down concrete protocols, credential formats, and trust models. If you build for eIDAS 2.0, the ARF — not a vendor datasheet — is the source of truth.

The EUDI Wallet & ARF in plain terms

Picture three roles. An issuer (a government identity service, a university, a bank) signs a credential and hands it to the user’s wallet. The wallet — an app on an attested device — holds those credentials and controls what gets shared. A relying party (your application) requests the minimum it needs and verifies the signatures and trust chain before granting access.

The ARF describes how these roles interoperate: the trusted lists that say which issuers and relying parties are legitimate, the credential formats, the device-binding and wallet attestation requirements (a wallet should run on a secure element so a stolen credential can’t be replayed elsewhere), and the protocols that move credentials between parties. Importantly, the ARF leans on existing open standards rather than inventing new ones — which is why OpenID and IETF specs do the heavy lifting.

What protocols does the EUDI Wallet use?

Three building blocks, each an open draft you can read today.

• OID4VCI — OpenID for Verifiable Credential Issuance. How an issuer delivers a signed credential into the wallet. It reuses OAuth 2.0 authorization flows, so the issuance handshake looks familiar to anyone who has implemented OIDC. Spec: OpenID4VCI.
• OID4VP — OpenID for Verifiable Presentations. How a relying party requests credentials and how the wallet presents them — including selective disclosure. This is the runtime “login” path. Spec: OpenID4VP.
• SD-JWT-VC — Selective Disclosure JWT Verifiable Credentials. The credential format that makes data minimisation cryptographically real: the issuer signs a JWT whose individual claims can be selectively revealed or withheld by the holder, without breaking the signature. Drafts at the IETF OAuth working group (SD-JWT and SD-JWT-VC). (The ARF also profiles ISO/IEC 18013-5 mDoc for mobile driving licences; SD-JWT-VC is the JOSE-native path most web teams will meet first.)

If your team already speaks OIDC, the conceptual leap is small: the wallet behaves like a user-controlled identity provider, OID4VP is the request/response you wire into your relying party, and SD-JWT-VC is “a JWT, but the holder decides which claims to reveal.”

How to read this diagram: It splits the wallet journey into two phases. In the upper block the user obtains a credential from an issuer via OID4VCI, which is built on ordinary OAuth 2.0 flows, and the result is a signed SD-JWT-VC stored in the wallet. In the lower block — the actual login — your relying party sends an OID4VP presentation request naming exactly the claims it needs plus a fresh nonce; the wallet performs selective disclosure with the user’s consent and returns a verifiable presentation. The relying party then checks the issuer’s signature, confirms the issuer sits on an eIDAS trusted list, and validates the nonce to defeat replay. The point is that no password and no shared secret cross the wire — trust comes from a verifiable signature the relying party can check independently, which is also why the strength of that signature matters so much.

Timeline & who must support it

eIDAS 2.0 entered into force on 20 May 2024, but the operational obligations phase in as the implementing acts and ARF mature. The European Commission’s digital identity programme page tracks the official milestones; the practical sequence engineering teams should plan around is below.

How to read this diagram: It reads left to right as three dependent waves. First the regulation lands (May 2024) and the detailed rules — implementing acts and the ARF — get finalised; nothing downstream is final until these are. Second, wallets ship: the large-scale pilot consortia validate cross-border flows, then member states issue production wallets to citizens. Third, acceptance becomes mandatory: relying parties in scope — regulated sectors plus the very large online platforms designated under the Digital Services Act — must accept wallet-based identification, reaching a steady state of EU-wide interoperable login. The dependency direction matters for planning: build OID4VP support against the ARF now, because the acceptance obligation arrives whether or not your stack is ready. For the financial and critical-infrastructure deadlines that sit alongside this, see our DORA, NIS2 and PSD3 authentication checklist.

Who is in scope? In short: public-sector services, regulated sectors that already require strong authentication (finance, telecoms, health), and very large online platforms. But the smart move for any EU-facing application is to treat wallet acceptance as a near-term feature, not a distant compliance chore — because the same architecture that satisfies eIDAS 2.0 also reduces your dependence on third-country identity providers, the subject of our deeper piece on EU sovereign identity vs the US CLOUD Act.

Where this meets post-quantum

Verifiable credentials are long-lived. A diploma attestation or a PID credential may need to verify for years, and the issuer’s signing key is a root of trust for everything it signed. That is exactly the profile most exposed to the “harvest-now, forge-later” risk: an adversary who can eventually forge an issuer signature can mint counterfeit credentials that still pass verification. So the cryptography that protects wallet credentials should be chosen with a multi-year horizon in mind — which is where the wallet roadmap and the post-quantum authentication roadmap converge.

This is the design stance behind CAI-AUTH, our EU-operated, self-hostable OIDC identity provider written in Rust (not built on Keycloak). It signs tokens with a composite ML-DSA-87 + Ed25519 signature (alg id CAI-PQ-HYBRID-87-Ed25519, following draft-ietf-lamps-pq-composite-sigs), so a credential or token stays verifiable even if one primitive is later weakened. Because OID4VCI and OID4VP are OAuth/OIDC-shaped, an identity provider that already does discovery-driven algorithm negotiation and standards-based JOSE signing is structurally close to a wallet-ready issuer and relying party. You can read how we map these obligations to capabilities on our compliance page.

A practical note: the regulation does not yet mandate post-quantum algorithms, and the ARF tracks the relevant standards as they stabilise. Treat PQ readiness as forward-looking insurance for long-lived credentials, not a current legal checkbox — but design so you can adopt it without re-architecting.

FAQ

What is eIDAS 2.0?

eIDAS 2.0 is Regulation (EU) 2024/1183, which amends the 2014 eIDAS framework and obliges every EU member state to provide an EU Digital Identity Wallet. It standardises legally recognised digital identity, verifiable credentials, selective disclosure, and cross-border acceptance, in force since 20 May 2024.

What is the EU Digital Identity Wallet?

The EUDI Wallet is a free, state-provided app that stores a citizen’s core identity (Person Identification Data) and optional verifiable credentials such as diplomas or licences. Users present signed credentials to relying parties with selective disclosure, proving attributes online and offline without passwords or third-party login.

Which protocols does the EUDI Wallet use?

The wallet relies on open standards profiled by the Architecture and Reference Framework: OID4VCI (OpenID for Verifiable Credential Issuance) to receive credentials, OID4VP (OpenID for Verifiable Presentations) to present them, and SD-JWT-VC as a selective-disclosure credential format. ISO/IEC 18013-5 mDoc covers mobile documents like driving licences.

Does my application have to accept the EUDI Wallet?

If you operate in a regulated sector requiring strong authentication, or are a very large online platform under the Digital Services Act, mandatory acceptance applies once the obligation phases in. Other EU-facing services are not strictly required yet but benefit from early support for sovereignty and user trust.

How does eIDAS 2.0 relate to post-quantum cryptography?

The regulation does not yet mandate post-quantum algorithms, but wallet credentials are long-lived, so their signatures must outlast the quantum-forgery horizon. Choosing hybrid, post-quantum-ready signing for issuers and providers is forward-looking insurance against harvest-now, forge-later attacks on long-lived credentials.

Ready to plan a wallet-ready, post-quantum auth stack? See how CAI-AUTH maps eIDAS 2.0, DORA and NIS2 to concrete capabilities on our compliance page, or explore a live post-quantum OIDC provider at auth.caitech.ro.