EUDI Wallet 2026: Five Things Private PKI Teams Should Stop Ignoring

The 2026 EUDI Wallet Rollout in One Paragraph

Regulation (EU) 2024/1183, the amendment commonly referred to as eIDAS 2.0, entered into force on 20 May 2024 and obliges every Member State to issue at least one European Digital Identity Wallet (EUDI Wallet) by Q4 2026. The Commission’s reference deadline tracks the implementing acts published under Article 5a and the supporting acts adopted between November 2024 and 2025, which lock down technical requirements, certification scope, and cross-border interoperability profiles.

The current canonical specification is the Architecture and Reference Framework (ARF) version 1.4, which fixes the credential formats (ISO/IEC 18013-5 mobile driving licence (mDL) over OpenID for Verifiable Credentials, plus SD-JWT VC for selective disclosure), the transport bindings (OpenID4VP for presentation, OpenID4VCI for issuance), and the trust model anchored on the eIDAS Trusted Lists (Implementing Decision (EU) 2015/1505 still applies, extended by Article 22a). Four large-scale pilots — POTENTIAL, EWC, NOBID, and DC4EU — have been running since April 2023 under DIGITAL-2022-DEPLOY-04, with reference implementations published on the EU Digital Identity GitHub organisation.

The baseline cryptography mandated by the ARF reflects this: P-256 (secp256r1, OID 1.2.840.10045.3.1.7) is mandatory for Wallet Instance Attestations, ECDSA with SHA-256 is the floor signature suite, and ISO/IEC 18013-5 device authentication uses the same curve through the mdoc COSE_Sign1 structure. None of this is hypothetical anymore.

Why "This Is for Citizens" Isn’t True for Enterprise PKI

The dominant misreading of eIDAS 2 inside private enterprise PKI teams is that the Wallet is a consumer-grade identity layer maintained by Member States and Qualified Trust Service Providers (QTSPs), and that the only enterprise touchpoint is a button on a public website. Article 5b of Regulation 2024/1183 contradicts this directly: it requires "very large online platforms" under the Digital Services Act and any private relying party operating in a regulated sector — banking, healthcare, telecom, transport, energy, gambling, online travel — to accept the Wallet for authentication wherever strong customer authentication is required under sector law.

PSD2’s SCA, the AMLD6 customer due diligence obligation, the eHDSI cross-border health data exchange, and the Single Digital Gateway Regulation (EU) 2018/1724 all converge on the Wallet as the recognised proof.

For an enterprise PKI lead, that means three concrete things.

• First, every business-to-consumer (B2C) onboarding flow that today relies on national eID, video KYC, or document scanning will receive Person Identification Data (PID) and Qualified Electronic Attestations of Attributes (QEAA) in SD-JWT VC or mdoc format, signed by issuers listed in a national Trusted List. The relying party software has to validate those signatures, walk the chain to the Trusted List, and reconcile the cryptographic identity against an internal subject. That validation engine is closer to a certificate authority client than to an OAuth client, and it is a PKI problem.
• Second, employee identity for cross-border B2B services — eDelivery, eInvoicing under Directive 2014/55/EU, public procurement under Directive 2014/24/EU — will increasingly be expressed as Wallet attestations, including Electronic Attestations of Attributes such as "legal representative of company X, registration number Y".
• Third, regulated B2B flows in banking (DORA, EBA RTS on SCA), healthcare (EHDS Regulation (EU) 2025/327), and government procurement will require the relying party to honour Wallet-signed authorisations with the same legal weight as a Qualified Electronic Signature under Article 25(2).

The Wallet is not consumer noise; it is a new credential issuer your PKI policy has to recognise.

Identity Federation: Where Your Private CA May Need to Bridge

Most enterprise identity stacks today are a federation broker (Azure Entra ID, PingFederate, Keycloak, ForgeRock) speaking OIDC and SAML, fronting a directory and an internal issuing CA that produces client authentication certificates for workforce devices. The EUDI Wallet does not replace this; it adds a Verifiable Credentials (VC) plane. The brokers have to learn to consume an OpenID4VP presentation, validate one or more Verifiable Presentations, extract claims, and produce an internal session token (id_token, SAML assertion) that downstream applications can already consume.

The ARF section on Relying Party registration (ARF v1.4, sections 6.3 and 7.3.4) mandates that every relying party be registered in a national Relying Party registry, with an associated Access Certificate issued by a Relying Party Access Certificate Authority. That access certificate is an X.509 certificate, profiled in the Implementing Act on Wallet Relying Party registration, and it is precisely where your private CA may need to bridge.

Concretely, the access certificate carries the relying party identifier, the set of attributes the RP is authorised to request (the "intended use"), and is signed under a chain anchored in the Member State’s Trusted List. Some Member States are planning to allow accredited enterprise CAs to issue these certificates under a delegated trust agreement; others will issue them centrally. Either way, your X.509 profile work matters: the access certificate profile fixes the EKU OIDs, the Subject Information Access extension pointing to the registration record, and the certificatePolicies extension carrying the policy identifier of the registry. ARF Annex 2 references draft OIDs in the 0.4.0.194112 arc (ETSI) for the Wallet-specific extensions.

If your internal CA still issues certificates with handcrafted CSRs and no policy mapping, this is the moment to revisit your certificate policy and Certification Practice Statement governance. The Trusted List itself is published as an XML document (ETSI TS 119 612), and your validator must fetch it, verify the qualified seal, and refresh it within the "next update" window. Treat this as a real piece of operational infrastructure, not a quarterly import.

Document and Signing Flows That Will Expect Wallet Attestations

Article 14 of Regulation 2024/1183 amends eIDAS 1 by formally folding remote signing into the Qualified Electronic Signature (QES) and Qualified Electronic Seal (QSeal) regime. The combination of Article 29a (Qualified Trust Service for the management of a remote QES creation device) and the Implementing Regulation (EU) 2025/847 on remote QSCD requirements means a Wallet can now host a signing key bound to a qualified certificate, where the cryptographic operation occurs server-side inside a FIPS 140-3 or EN 419 221-5 certified HSM, while user consent is captured through the Wallet’s authenticated UI.

The technical protocol is fixed by the Cloud Signature Consortium API (CSC v2.0.0.2) and the ETSI TS 119 432 Remote Signature Protocol, both referenced in the ARF Annex on QES integration. Practically, when a user signs a procurement contract or a tax return through the Wallet, the signature value lands as a CAdES, PAdES, or XAdES Baseline-LTA structure with an embedded RFC 3161 timestamp from a qualified TSA.

For internal e-signing flows this is a small but consequential shift. Today a typical enterprise signing workflow validates against a known list of national eID providers and falls back to in-house OTP-bound advanced signatures. Tomorrow, the same workflow receives a CAdES-B-LTA signature whose signing certificate was issued ten minutes earlier to a Wallet Instance for a one-shot use, with a validity of fifteen minutes and a custom certificatePolicies OID.

Long-term validation (LTV) under ETSI TS 119 102-1 requires you to capture, at signing time, the full revocation status (CRL or OCSP) and the Trusted List snapshot. Your archive must store those artefacts for the full retention period — ten years for invoices under Directive 2006/112/EC, seven years for AML files. Mobile signing UX, captured through the Wallet’s biometric unlock and the QSCD’s Signature Activation Protocol (SAP, ETSI TS 119 432 section 9), removes the smartcard reader from the equation, but it does not remove the obligation to validate. The internal S/MIME and email signing infrastructure remains, but loses ground to Wallet-driven QES wherever a customer-facing or cross-border counterparty is involved.

Crypto Agility Implications: ECC Curves and Hash Algorithms

The ARF v1.4 cryptographic suites annex (Annex 2, section 6.3) is more prescriptive than most PKI teams realise. The mandatory baseline for Wallet Instance Attestations, Person Identification Data, and Qualified Electronic Attestations of Attributes is ECDSA with P-256 (secp256r1, NIST OID 1.2.840.10045.3.1.7) and SHA-256 (OID 2.16.840.1.101.3.4.2.1).

P-384 (secp384r1, OID 1.3.132.0.34) is permitted and is the operational choice for several Member State implementations targeting higher assurance use cases — notably Germany, where BSI TR-03116 still recommends brainpoolP256r1 (OID 1.3.36.3.3.2.8.1.1.7) and brainpoolP384r1 (1.3.36.3.3.2.8.1.1.11) for sovereign deployments. France, Spain, and Italy have aligned with the NIST curves; the Nordic NOBID pilot defaults to P-256. Edwards curves (Ed25519, OID 1.3.101.112) are not part of the mandatory baseline, although they appear in some pilot RP profiles for the device-binding key.

Hash agility is equally explicit. SHA-256 is the mandatory floor, SHA-384 is permitted, and SHA-3 (SHA3-256, OID 2.16.840.1.101.3.4.2.8) appears in the ARF as a future option, gated by the ENISA recommendations on cryptographic standards. RSA is admitted only with PSS padding (RSA-PSS, OID 1.2.840.113549.1.1.10) and a minimum key length of 3072 bits for new QSCDs, in line with SOG-IS ACM v1.3 and ETSI TS 119 312.

For PKI teams running an issuing CA on RSA-2048 with SHA-256, none of this is dramatic in 2026, but it constrains what you can present to a Wallet-side validator and what your CA must accept on a CSR. If your internal CA cannot mint a SubjectAltName with the URN-based Wallet Instance identifier, cannot honour the ARF profile’s use of the id-pkix-ocsp-no-check extension, and cannot rotate a Trust Service Token (TST) on a fifteen-minute cycle, you will be doing emergency development in Q3 2026.

Beyond the curve choice, the post-quantum question is in the room. The Commission’s recommendation of 11 April 2024 on a coordinated PQC roadmap, and ENISA’s 2024 report "Post-Quantum Cryptography: Current State and Quantum Mitigation", both flag eIDAS-bound credentials as primary candidates for hybrid signature profiles. The ARF does not mandate ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) yet, but the trust framework is explicitly designed to accept additional signature suites by Implementing Act. A serious crypto-agility and post-quantum readiness review of your CA software, your HSM firmware (PKCS#11 vendor support for CKM_ML_DSA_KEY_PAIR_GEN), and your certificate consumers belongs on the 2026 roadmap, not the 2028 one.

The 18-Month Integration Roadmap

An 18-month plan from H2 2026 to end 2027 should look like this. It is not maximalist; it is the minimum to avoid a regulatory finding under PKI regulatory compliance obligations adjacent to eIDAS 2 (NIS2 Article 21, DORA Article 9, CRA Article 13).

• Q3 2026 — Inventory and scope. Map every customer-facing onboarding, signing, and authentication flow against the eIDAS 2 acceptance obligations. Identify which flows trigger Article 5b acceptance, which fall under sector law (PSD2 SCA, AML, eHealth), and which are out of scope. Inventory current cryptographic configurations: TLS profiles on the relying party endpoints, signature algorithms in the signing pipeline, supported curves in the federation broker, OCSP and CRL configuration on the issuing CA. Map them against ARF v1.4 Annex 2 and ETSI TS 119 312. Output: a gap document indexed against the cryptographic suites annex, named owners per gap.
• Q4 2026 — Trusted List integration and RP registration. Stand up a production Trusted List client that consumes the EU LOTL (List of Trusted Lists), validates each national TL signature (ETSI TS 119 612), refreshes on the "next update" cadence, and exposes a queryable trust anchor store. Register the enterprise as a Relying Party in at least one Member State’s RP registry. Obtain the first Access Certificates. Wire them into the federation broker. Pick the first Wallet integration vendor or open-source library (EUDI Reference Wallet, sd-jwt-js, openid4vp-rs). Set up an internal sandbox connected to a pilot Wallet (POTENTIAL, EWC, NOBID, or DC4EU).
• Q1 2027 — Federation broker upgrade. Add an OpenID4VP verifier endpoint to the broker. Implement claims mapping from SD-JWT VC and mdoc payloads to internal user attributes. Define the relationship between a Wallet-issued PID and the internal user record — first-time provisioning, account linking, attribute refresh, account deletion. Update consent and audit logging to capture the OpenID4VP presentation_submission, the verifiable presentation hash, and the Trusted List snapshot at validation time. Confirm GDPR Article 5 minimisation by storing only the disclosed claims, not the full credential.
• Q2 2027 — Signing and document flows. Integrate at least one Wallet-bound QES path through CSC API v2 against a qualified TSP. Update the long-term validation pipeline (LTV) to honour CAdES, PAdES, and XAdES Baseline-LTA produced under the new profile. Verify that the archive layer preserves the Trusted List snapshot and the qualified timestamp tokens. Decommission any legacy advanced-signature fallback that no longer meets the contractual or regulatory bar.
• Q3 2027 — Crypto agility and key custody review. Audit the issuing CA against ETSI EN 319 411-1 and 319 411-2. Confirm support for P-384 and brainpool curves for jurisdictions that require them. Verify HSM firmware exposes ML-DSA and ML-KEM through PKCS#11 vendor mechanisms or through the Common Criteria-certified extension currently under preparation. Plan a hybrid signature pilot on a non-production flow. Refresh the Certificate Policy and CPS to formally reflect the Wallet acceptance scope.
• Q4 2027 — Operational hardening. Run a red-team exercise against the Wallet acceptance surface: forged presentations, replayed nonces, downgraded Trusted Lists, expired Access Certificates, malformed mdoc COSE structures. Confirm incident response runbooks under DORA Article 17 and NIS2 Article 23 cover Wallet-related events. Train support and legal on the new evidence types stored in the archive. Sign off the program as steady-state.

Where Evertrust Fits

The EUDI Wallet rollout is not a parallel universe to private PKI; it is an extension of the same X.509 and trust list machinery your CA already operates, with new profiles, new consumers, and new validation obligations. Trusted List ingestion, Access Certificate lifecycles, RP registration, qualified signing pipelines, and crypto-agility for ECC and post-quantum families are all problems your existing CA platform either solves or actively complicates.

Evertrust’s PKI and certificate lifecycle products are designed around this reality: policy-driven issuance for enterprise X.509 profiles, native support for ECC and forthcoming PQC suites, integration with HSMs and remote QSCDs aligned to ETSI standards, and the operational governance hooks that make Wallet acceptance auditable rather than improvised. Explore the Evertrust PKI platform to see how a single trust foundation can carry both your private CA estate and your EUDI Wallet relying party surface through the next eighteen months.