eIDAS 2.0 EUDI Wallet: Integration Guide for 2026

By the end of 2026, every EU citizen and resident can demand an EU Digital Identity Wallet from their member state. Every public-sector portal will be expected to accept it. Every Very Large Online Platform under the DSA will be required to support it for strong customer authentication. If a relying party’s authentication stack ends at SAML federation and a national eID like SPID or BankID, the relying-party rebuild is happening now or it is not happening on time.

This post is for government CIOs, public-sector platform architects, and private-sector identity engineers scoping a EUDI Wallet relying-party integration. It covers the regulatory baseline, the Architecture and Reference Framework, the OpenID for Verifiable Credentials (OID4VCI and OID4VP) flows, credential format choices, and the migration paths from existing national identity systems.

eIDAS 2.0 in one page: what changes from eIDAS 1

Regulation (EU) 2024/1183 amended Regulation (EU) No 910/2014 (eIDAS) on 20 May 2024. The amended regulation is commonly called eIDAS 2.0. The core change is the introduction of the European Digital Identity Wallet (EUDI Wallet).

Under eIDAS 1, member states could notify electronic identification schemes for cross-border recognition. Adoption was uneven. Some member states had high-quality notified eIDs (Estonia, Belgium, Germany); others had weak or no notified schemes. Cross-border use was rare in practice.

Under eIDAS 2.0:

• Every member state must provide at least one EUDI Wallet to citizens and residents who request one. The wallet is provided free of charge.
• Citizens choose what to share from their wallet. Selective disclosure of attributes is built into the architecture.
• Public-sector services must accept the EUDI Wallet for authentication and for attribute presentations where relevant.
• Very Large Online Platforms under the Digital Services Act must accept the EUDI Wallet for user authentication, with technical requirements set by implementing acts.
• Qualified electronic attestations of attributes (Q)EAA, issued by qualified trust service providers (QTSPs), join the qualified signature and qualified seal as recognized trust services.

The practical timeline: implementing acts set technical specifications, member states then have 24 months from adoption of the relevant implementing acts to provide the wallet. The functional deadline lands in late 2026 for the first wave of member states, with most others following through 2027.

The Architecture Reference Framework: what your stack must speak

The Architecture and Reference Framework (ARF), maintained by the European Commission’s eIDAS Expert Group, is the binding technical specification for EUDI Wallet implementations. ARF v1.5 (early 2026) is the current operative version, with v1.6 incremental updates expected in the next year.

The ARF defines:

• Wallet roles: Holder (the citizen with the wallet), Issuer (PID provider or attribute attestation provider), Relying Party (a public or private service requesting authentication or attribute presentation).
• Person Identification Data (PID): the baseline credential issued by member states. Includes a minimum dataset (family name, given name, birth date, current address or place of birth, gender, nationality, and a national identifier where applicable).
• (Q)EAA: electronic attestations of attributes for everything else (driving license, age verification, professional qualifications, education attainments, bank account ownership, residency status).
• Wallet attestation: a credential the wallet itself presents to prove its conformance to the regulation.
• Trust framework: notified eIDs, qualified trust service providers, and the EU List of Trusted Lists (LOTL) for verification.

For a relying party, the four ARF specifications to know are:

1. OpenID for Verifiable Credential Issuance (OID4VCI): how a wallet receives a credential from an issuer.
2. OpenID for Verifiable Presentations (OID4VP): how a relying party requests and receives a credential presentation from a wallet.
3. Self-Issued OpenID Provider v2 (SIOP v2): the underlying protocol enabling the wallet to act as an identity provider.
4. Status list profiles (Status List 2021 or W3C Bitstring Status List) for credential revocation checking.

These are all OpenID Foundation specifications. A team already familiar with OpenID Connect has most of the protocol vocabulary; what is new is the credential format handling and the wallet interaction model.

Becoming a relying party: registration, scopes, and trust lists

Relying parties (RPs) in the EUDI Wallet ecosystem must register and be approved before they can request credential presentations. The registration process is operated per member state but harmonized in form:

1. RP registration with the member state’s competent authority. The registration includes the RP’s legal identity, the purposes for which credentials will be requested, and the categories of attributes the RP is authorized to request.
2. Trust framework inclusion in the member state’s trusted list, which feeds into the EU List of Trusted Lists (LOTL).
3. Technical credentials (signing keys, TLS certificates) issued or attested by the member state.
4. Compliance posture verified: GDPR data minimization, purpose limitation, transparency obligations under eIDAS 2.0 Article 5b.

The RP cannot request attributes outside of its registered scope. A government tax service registered for fiscal residency cannot request a driving license. A private bank registered for KYC cannot request education credentials. The wallet enforces this at presentation time by checking the request against the RP’s registered scopes.

Registration is per-member-state but the resulting authorization is recognized cross-border through the LOTL. An RP registered in Germany can be presented to by a wallet issued in Spain, as long as the request is within the RP’s registered scopes and the LOTL recognizes the RP.

OID4VCI and OID4VP flows for issuance and verification

The two protocols an RP team must implement carefully:

OID4VCI (issuance) is mostly relevant for organizations that issue credentials (driving license authorities, educational institutions, banks issuing account ownership attestations). The flow:

1. Issuer offers a credential to the holder, either through a pre-authorized code flow (issuer pushes; holder claims) or an authorization code flow (holder requests; issuer authenticates).
2. Wallet receives the offer, presents it to the holder for consent.
3. On consent, the wallet requests the credential from the issuer’s token endpoint, presenting any required proofs (typically a proof of key possession).
4. Issuer issues the credential in the agreed format (SD-JWT VC or ISO mDL).
5. Wallet stores the credential.

OID4VP (verification) is the flow most RPs implement. The simplified flow:

1. RP creates a presentation request specifying which credential types and attributes are needed, with a nonce and a signed request object.
2. RP delivers the request to the wallet, either through a redirect (same-device) or a QR code (cross-device).
3. Wallet receives the request, displays it to the holder showing exactly what is being requested and by whom.
4. On holder consent, the wallet constructs a verifiable presentation (signed by the holder’s wallet-bound key) containing the requested credentials with selective disclosure applied.
5. Wallet delivers the presentation to the RP’s response endpoint.
6. RP verifies the presentation: signature validity, credential validity (status list check), issuer trust list membership, attribute extraction.

The protocol detail that catches teams: OID4VP supports both direct_post (the wallet posts the presentation to a known RP endpoint) and direct_post.jwt (the presentation is wrapped in a JWT signed by the wallet). Most production deployments use direct_post.jwt for additional integrity protection. Test environments often default to direct_post, which leads to integration drift if not caught.

Credential formats: SD-JWT VC vs ISO mDL

The ARF supports two primary credential formats:

• SD-JWT VC (Selective Disclosure JWT Verifiable Credential): a JSON-based format with built-in selective disclosure. The credential is a JWT plus a set of disclosure salts; the holder presents only the disclosures relevant to the request. SD-JWT VC is the default for most general-purpose attribute attestations.
• ISO/IEC 18013-5 mDL: the international standard for mobile driving licenses. CBOR-based, with strong fit for the driving license use case and growing adoption for other government-issued credentials.

The format choice is largely determined by the credential issuer:

• Driving licenses are typically ISO mDL.
• General attribute attestations from QTSPs and government services are typically SD-JWT VC.
• Cross-border health credentials may use either, depending on member state preference.

RPs must support both formats to receive presentations from the full ecosystem. A library like Sphereon Verifier, Microsoft Entra Verified ID, or one of the open-source implementations from the Large Scale Pilots provides cross-format support. Building both from scratch is possible but not necessary in 2026.

UX patterns: same-device, cross-device, and offline presentation

The wallet interaction happens in one of three modes:

• Same-device flow: the holder is using a phone with the wallet installed and the RP’s web app or native app is also on the same phone. The RP redirects to a wallet URL scheme (openid4vp://…) and the wallet handles the request locally.
• Cross-device flow: the holder is using the RP service on a desktop or kiosk. The RP renders a QR code; the holder scans it with their wallet phone. The wallet handles the request and posts the presentation back to the RP’s endpoint over the network.
• Offline presentation: the holder presents a credential in person (e.g. age verification at a venue, identity check at an inspection). NFC or Bluetooth Low Energy transports a presentation request from the verifier device to the wallet; the wallet responds the same way.

Each mode has different security and UX considerations. The same-device flow is the smoothest but requires careful handling of deep-link integrity (a malicious app could intercept the wallet URL scheme). The cross-device flow needs a session binding pattern to prevent the QR code from being relayed to a different holder. Offline presentation requires the wallet and verifier to share a fresh session key established through a pairing handshake.

A production RP deployment typically implements all three modes. The same-device flow is the default for mobile users; the cross-device flow covers desktop users; offline applies if the RP operates physical verification points.

Migration path from national eID to EUDI

Most EU public-sector services already integrate with a national eID: SPID in Italy, BankID in Sweden and Norway, ID-Porten in Norway, DigiD in the Netherlands, FranceConnect in France, ItsMe in Belgium, Mobiilivarmenne in Finland. The migration to EUDI Wallet support is rarely a replacement; it is an addition.

A pragmatic migration sequence:

1. Add EUDI Wallet as an additional authentication option alongside the existing national eID. Users who have a wallet can use it; users who do not continue with the national eID.
2. Mirror the attribute set. If the national eID provides name, fiscal code, and address, the EUDI Wallet integration requests the same attributes. The downstream service logic does not change.
3. Progressive features. Wallet-only features (selective disclosure, qualified attribute attestations from third parties) can be exposed once core authentication is stable.
4. Cross-border first. The EUDI Wallet’s most differentiated value is cross-border. A foreign user can now authenticate to a domestic service without the friction of cross-border eID federation that eIDAS 1 attempted but largely failed to deliver.
5. Sunset the national eID only when adoption of the EUDI Wallet within the user base exceeds 70 to 80%, typically 3 to 5 years after wallet launch.

The Large Scale Pilots (POTENTIAL, EWC, NOBID, DC4EU) ran through 2024 and 2025 with technical validation across payments, travel, education, and eHealth. The pilots produced reference architectures for relying party integration in each domain. Public-sector integrators can reuse the patterns rather than reinventing them.

What member-state wallets look like in 2026

Member-state implementations are visibly diverging in 2026 even within the ARF baseline:

• Germany: SPRIND-led “IDunion” and Bundesdruckerei-led EUDI Wallet implementations, with a heavy focus on industrial use cases and qualified attestations.
• Italy: IT Wallet from PagoPA, leveraging the existing SPID and CIE infrastructure and integrating with the dominant IT public services platform.
• France: France Identite app, building on the existing dematerialized national identity card.
• Spain: DNI Wallet, integrated with the national digital identity card infrastructure.
• Netherlands: NL Wallet, built on the DigiD foundation with strong emphasis on government services use cases.

The cross-border interoperability test is whether a German wallet works with an Italian relying party and vice versa. The LOTL infrastructure, the ARF compliance, and the credential format harmonization are all aimed at that test. The 2026 Large Scale Pilot follow-up rounds focus on closing the remaining gaps.

A relying party integration plan for 2026

For a public-sector service or a private relying party scoping a EUDI Wallet integration before the end of 2026, the achievable scope:

1. Architecture and trust framework registration (4 to 6 weeks): RP registration with the member-state competent authority, trust list inclusion, scope definition.
2. OID4VP integration (8 to 12 weeks): implement same-device and cross-device flows, integrate a verifier library supporting SD-JWT VC and ISO mDL, build the attribute extraction and downstream identity binding logic.
3. Wallet attestation handling (2 to 4 weeks): verify wallet attestation in presentation requests, handle the case of non-conformant or revoked wallets.
4. Status list integration (2 to 4 weeks): real-time revocation checking against credential issuer status lists, with appropriate caching.
5. Cross-border testing (4 to 8 weeks): test with at least three member-state wallets, document divergences, file bugs against the relevant implementations.
6. Pilot launch and stabilization (4 weeks): limited rollout, monitoring, iteration.

End-to-end, a focused team can take a relying party from no wallet support to live integration in approximately 6 months. Slower paths exist (vendor procurement plus integration plus internal change management often takes 12 to 18 months), but the technical work itself is bounded.

The EUDI Wallet is one of the largest digital identity rollouts in the world by 2027. The relying parties that integrate early benefit from a real cross-border identity layer that eIDAS 1 promised and never delivered. The ones that wait until adoption forces them will integrate under time pressure, against a wallet ecosystem that has already converged on operational norms set by the early adopters. The architectural choice is open today; in 18 months it will not be.