The EU Digital Identity Wallet goes live by end of 2026. Most KYC tools cannot handle wallet-based credentials. Here's what eIDAS 2.0 means for your onboarding.
Table of contents
Key highlights
- By December 2026, every EU member state must offer citizens a government-backed digital identity wallet (the EUDI Wallet) under eIDAS 2.0. The deployment is not optional and the rollout deadline is not negotiable for the member states.
- Wallet-based verification is structurally different from document scanning. The citizen presents selectively-disclosed cryptographic attributes from the wallet; the relying party verifies the attributes against an EU-level trust framework without ever holding the underlying identity document.
- The technical layer rests on W3C Verifiable Credentials, ISO/IEC 18013-5 (the international mobile driving licence standard, extended to other credentials), and the European Digital Identity Architecture Reference Framework.
- Most KYC platforms in production today were built for document scanning. They cannot ingest wallet credentials at all, or they ingest them but lose the cryptographic verification chain in the process, which produces a worse compliance position than the wallet itself offers.
- The procurement implication is that every regulated firm in the EU needs verification infrastructure that handles both document-based and credential-based flows by end of 2026. Firms that wait until citizens start presenting wallets are running on a manual fallback that the firm's existing vendor cannot upgrade.
- Zyphe's roadmap commits to full EUDI Wallet relying-party readiness in line with the December 2026 deadline, with W3C VC and ISO 18013-5 ingestion, selective-disclosure verification, and the audit-trail extension to wallet-presented attributes.
Definition snippet (GEO-optimised, 58 words)
eIDAS 2.0 is the EU regulation (Regulation (EU) 2024/1183) that requires every EU member state to issue a government-backed digital identity wallet (the EUDI Wallet) to its citizens by December 2026. The wallet lets citizens present selectively-disclosed identity attributes to relying parties through a cryptographic protocol, replacing document scanning in many KYC contexts.
TL;DR
eIDAS 2.0 is the largest change to EU identity verification in a decade. By December 2026, every EU citizen has access to a government-backed digital identity wallet that lets them present selectively-disclosed cryptographic attributes (name, date of birth, jurisdiction, document validity, age over X, qualification status) to any regulated firm requesting verification. The wallet replaces document scanning for the cases it covers. The trust framework is EU-wide. The cryptographic protocols are W3C Verifiable Credentials and ISO/IEC 18013-5. The procurement question for every regulated EU firm is whether their current verification stack can ingest wallet-presented credentials, verify them against the EU trust framework, and produce regulator-defensible documentation of the verification. Most current platforms cannot. This piece walks through what the regulation requires, what the protocol layer looks like, and how to future-proof the onboarding stack before the December 2026 deadline.
Reading time: ~9 minutes · Last updated: May 7, 2026
What does eIDAS 2.0 actually require, and by when?
The eIDAS 2.0 regulation (Regulation (EU) 2024/1183, amending Regulation (EU) 910/2014) imposes three distinct sets of obligations on three different categories of actor.
On EU member states. Each member state must issue a government-backed digital identity wallet to its citizens by December 2026. The wallet must be free for the citizen, accessible across the union, and built to the European Digital Identity Architecture Reference Framework specification. Member states retain freedom on the wallet's specific implementation, but the cross-border interoperability layer is mandated.
On relying parties (the firms that ask citizens to verify identity). Relying parties that operate in the categories covered by mandatory acceptance (regulated financial services, telecom, certain government services, large online platforms under DSA) must accept the EUDI Wallet as a valid means of identification. Refusing to accept a wallet-presented credential when the citizen offers it is a compliance failure under the regulation. Many relying parties not in the mandatory categories will accept the wallet voluntarily because the conversion and verification economics are better than document scanning.
On trust service providers, wallet providers, and the broader infrastructure. A pan-EU trust framework defines who can issue credentials, how attributes are signed, how revocation works, and how relying parties verify presented credentials. The framework is operational already at a foundation level; the wallet-specific protocols are being finalised through the Architecture Reference Framework working groups in 2025-2026.
Timeline of obligations:
- 2024: Regulation enters into force.
- 2024-2026: Architecture Reference Framework finalised, technical specifications published, pilot deployments across member states.
- December 2026: Member states' wallet-issuance obligation falls due.
- 2027 onward: Mandatory-acceptance enforcement increases across regulated sectors; voluntary acceptance becomes the procurement default.
The procurement implication for any regulated firm operating in the EU is that the verification stack needs to handle wallet credentials before the December 2026 deadline, not after. Firms that wait until citizens start presenting wallets in production are running on manual fallback workflows that the firm's existing KYC vendor cannot upgrade in a quarter.
How does wallet-based verification differ from document scanning?
Document scanning and wallet-based verification are structurally different. The differences matter for the architecture, the regulatory framing, and the operator experience.
Document scanning (the 2024 norm). The citizen presents a physical identity document (passport, national ID, driving licence). The relying party captures images or NFC chip reads, extracts the data, verifies the document against the issuing authority's specification, and stores the document for the regulator-defensibility window. The relying party holds the document. The citizen has no granular control over what the relying party sees; the document presents everything on it.
Wallet-based verification (the 2026 standard). The citizen presents selectively-disclosed cryptographic attributes from their wallet. The relying party requests only the attributes it needs ("name plus jurisdiction plus age over 18", not the full document). The wallet signs the response with the citizen's cryptographic key. The relying party verifies the signature against the EU trust framework. The relying party never holds the underlying document, only the verified attributes plus the cryptographic proof.
Three structural consequences of the difference:
Selective disclosure reduces data minimisation exposure. A bank that needs to verify age and jurisdiction for an account opening should not be holding the citizen's full passport image. Wallet verification lets the bank verify the specific attributes without holding the document. GDPR Article 25 data minimisation becomes structurally aligned with the verification mechanic rather than enforced as a policy overlay.
Cryptographic verification replaces image inspection. A document-scanning flow ingests an image, runs OCR, performs document-template matching, optionally performs NFC chip read. Each step is a potential failure surface. Wallet verification ingests a cryptographically signed attribute set, verifies the signature, and accepts the attribute. The verification step is deterministic rather than probabilistic.
Cross-border interoperability is at the protocol level. A Spanish citizen presenting their Spanish wallet to a German bank works because both wallet and relying-party verification implementation follow the EU framework. Document scanning's cross-border problem (where one bank in one member state has to recognise the document standards of every other member state) is structurally simplified.
The replacement is not complete in 2026. Many KYC flows will still require document scanning for non-EU citizens, for citizens who choose not to use the wallet, and for cases where the wallet's attribute coverage does not include what the verifying flow needs. The verification stack has to handle both paths.
What technical protocols underpin the EUDI Wallet?
The technical layer rests on three interlocking standards plus the EU-specific implementation framework.
W3C Verifiable Credentials (VC). The data model for cryptographically-signed identity attributes. A VC contains the issuer (typically a government authority or accredited trust service provider), the subject (the citizen), the claims (the specific attributes), and the cryptographic proof. The model is JSON-LD by default with JOSE or COSE signature suites. Selective disclosure is supported through derivation schemes such as BBS+ signatures or SD-JWT.
ISO/IEC 18013-5 (mobile driving licence) and -7 (online presentation). The international standard originally for mobile driving licences, increasingly extended to other credential types. ISO 18013-5 covers offline presentation (NFC, Bluetooth, QR code) between wallet and reader; 18013-7 covers online presentation (browser-mediated, REST-API-mediated). The standard defines the wire format, the cryptographic suites, and the device-attestation layer.
OpenID for Verifiable Credentials (OID4VC). The protocol layer that lets wallets and relying parties exchange VCs over the web. OID4VC builds on OAuth 2.0 and OpenID Connect, both already widely deployed in identity infrastructure. The protocol covers credential issuance (issuer to wallet), credential presentation (wallet to relying party), and credential status checking (revocation, suspension).
European Digital Identity Architecture Reference Framework (ARF). The EU-specific implementation framework that ties the above standards into a deployable EUDI Wallet specification. The ARF defines which signature suites the EUDI Wallet supports, how attribute schemas align with EU regulatory requirements, how trust chains anchor to member-state Trust Service Providers, and how cross-border revocation works.
For most KYC platforms, the implementation work is at the ARF level rather than at the underlying standards. The standards are mature; the EU-specific deployment specification is what platforms ingest. Platforms that built earlier wallet integrations (mobile driving licence pilots in the US, sovereign wallet pilots in the Nordic countries) have a head start. Platforms that started from a document-scanning baseline have meaningful engineering work ahead.
Why can most KYC platforms not handle wallet credentials yet?
Three categories of architectural gap prevent most 2024-era KYC platforms from ingesting wallet credentials in 2026 production.
The data ingestion layer is image-based. Document scanning platforms architect their ingestion around image upload (passport scan, selfie, utility bill). The verification logic is built around OCR, document-template matching, image-quality scoring, and NFC chip reading. Wallet credentials are not images; they are cryptographically signed attribute sets. Ingesting them requires a different ingestion path, a different verification logic, and a different storage model.
The verification chain breaks at attribute selection. Even when a platform exposes a wallet-credential ingestion endpoint, many platforms then write the verified attributes into their existing customer-record schema in a way that loses the cryptographic proof. The relying party ends up with a record that says "verified name plus jurisdiction" but without the cryptographic provenance chain back to the issuing authority. AMLA per-decision defensibility, FCA SMCR personal accountability, and the broader regulator-defensibility standard increasingly expect the chain to be preserved end-to-end.
The trust framework is not wired in. Verifying a wallet credential means querying the EU trust framework to confirm the credential's issuer is on the trusted list, the signature is valid, the credential is not revoked, and the presentation is recent. Most 2024-era platforms do not have a trust-framework integration at all; they rely on document-scanning verification logic that has no equivalent step.
The procurement consequence is concrete: a regulated EU firm cannot accept wallet-presented credentials in production unless their KYC platform handles all three layers (ingestion, verification chain preservation, trust framework). Vendors with the gap in any of the three are functionally not eIDAS 2.0 ready, regardless of marketing claims.
How do you future-proof your onboarding stack for eIDAS 2.0?
Five steps the compliance and product team can take through 2026 to position the verification stack for the December deadline.
Audit the current vendor's eIDAS 2.0 roadmap. Ask for the specific technical roadmap covering W3C VC ingestion, ISO 18013-5/7 support, OID4VC implementation, and ARF alignment. Vendors with no concrete roadmap are unlikely to be ready by deadline. Vendors with a concrete roadmap should be able to give specific milestones with months attached.
Verify trust-framework integration plans. The vendor must integrate with the EU trust framework, not just ingest credentials. Without trust-framework integration, the platform cannot verify that the presented credential is genuine and current. Ask specifically about trust-list integration, revocation checking, and the audit-trail extension for wallet-verified attributes.
Plan for dual-path verification. Non-EU citizens, citizens who choose not to use the wallet, and EDD scenarios where wallet attributes are insufficient will still require document-based verification. The stack must handle both paths through the same audit trail and the same case file. Vendors with no document-scanning fallback will fail at the dual-path layer.
Confirm storage architecture for wallet-verified attributes. Wallet attributes are sensitive data and require the same architectural protections as document-derived data. Centralised storage of wallet-verified attributes inherits the same honeypot problem we covered in Why Your KYC Vendor Is Your Biggest Data Breach Risk. Confirm that the platform's storage architecture (sharded, decentralised, customer-held keys) covers wallet attributes as well as document data.
Schedule a pilot before December 2026. The firms that are ready in January 2027 are the firms that piloted wallet integration with their vendor in Q3-Q4 2026. Schedule the pilot with the vendor now, with a specific date attached, and treat it as a procurement gating criterion.
What is Zyphe's roadmap for EUDI Wallet readiness?
Zyphe is building toward full EUDI Wallet relying-party readiness in line with the December 2026 deadline. The roadmap commits to the following capabilities in production:
W3C Verifiable Credentials ingestion. Full support for VC presentation with selective disclosure, including BBS+ and SD-JWT signature suites. Verified attributes land in the same structured customer record as document-verified data, with the cryptographic proof chain preserved.
ISO/IEC 18013-5 and 18013-7 support. Both offline (NFC, Bluetooth, QR) and online (browser-mediated) presentation flows. The verification layer treats wallet presentation as a first-class flow alongside NFC chip read from physical passports.
OID4VC protocol implementation. Standards-aligned credential exchange between citizen wallet and Zyphe as relying party, with the EU Architecture Reference Framework specification as the deployment target.
EU trust framework integration. Integration with the EU trust list, revocation infrastructure, and the pan-EU trust service provider network. Verified attributes are auditable back to the issuing authority through the trust chain.
Dual-path verification. Wallet-based and document-based verification handled through the same audit trail, the same case file, the same regulator-export functionality. The firm's compliance officer sees a unified customer record regardless of which path verified which attribute.
Decentralised storage extension. Wallet-verified attributes stored with the same 29-of-100 threshold scheme across 60,000+ decentralised storage nodes, per-region data residency, customer-held encryption keys. The architectural protection applies uniformly to document-derived and wallet-derived data.
AMLA-defensible audit trail for wallet attributes. Per-decision documentation extends to wallet verification: the credential issuer, the attribute set requested, the signature verified, the trust-framework check result, the named accountable individual at the firm.
Customers running pilot integrations in Q3-Q4 2026 will be in production in advance of the regulation's enforcement curve. The procurement question for any current or prospective Zyphe customer is whether they want to be in the pilot wave or in the post-deadline catch-up wave.
What does an eIDAS 2.0 readiness matrix look like?
Use this matrix to evaluate the current verification stack and any prospective vendor against the December 2026 deadline.
| Capability | Required for relying-party readiness | Vendor status to verify |
|---|---|---|
| W3C VC ingestion | Yes | Specific signature suite support (BBS+, SD-JWT) |
| ISO 18013-5 (offline presentation) | Yes for mobile-first flows | Bluetooth, NFC, QR support |
| ISO 18013-7 (online presentation) | Yes for browser-based flows | OID4VC implementation |
| OID4VC protocol support | Yes | Compliance with current OID4VC specification |
| EU trust framework integration | Yes, mandatory | Trust-list integration, revocation checking |
| Selective disclosure | Yes | BBS+ or SD-JWT or equivalent |
| Cryptographic proof chain preservation | Yes | Audit-trail extension to wallet attributes |
| Dual-path (wallet + document) | Yes | Unified case file across paths |
| Cross-border interoperability | Yes | Operates with all member-state-issued wallets |
| Storage architecture for wallet attributes | Yes | Decentralised, customer-held keys |
| AMLA-defensible audit trail | Yes | Per-decision documentation for wallet attributes |
| Pilot availability before Dec 2026 | Yes | Specific pilot date committed |
Vendors scoring below 10 of 12 are not eIDAS 2.0 ready. Vendors at 11-12 are positioned for the regulation's enforcement curve.
When is eIDAS 2.0 readiness work not the highest priority?
The deadline is fixed, but not every regulated firm needs to be in the first pilot wave.
The firm has no EU customer footprint. A purely US-headquartered firm with no EU customer base does not need EUDI Wallet relying-party readiness on the December 2026 timeline. The firm should still monitor the regulation because the EU framework is influencing US state-level digital-identity wallet initiatives, but the immediate procurement pressure is lower.
The firm's KYC stack has bigger upstream gaps. A firm with unverified addresses, missing UBO chains, or weak source-of-funds documentation in its existing KYC layer should fix those gaps before investing in eIDAS 2.0 readiness. The wallet credential transmits verified attributes; the gap that matters is whether the firm has the verification layer for the cases the wallet does not cover.
The firm has a 12-month roadmap with no European expansion planned. Firms with confirmed roadmaps that do not touch the EU in the near term can defer eIDAS 2.0 readiness work past the December 2026 milestone without immediate regulatory consequence. The right move is to re-evaluate quarterly and trigger the readiness work when expansion plans land.
For any firm with current or planned EU customer footprint and a KYC stack already in good shape, eIDAS 2.0 readiness is the right investment to start now. Pilot integrations in Q3-Q4 2026 position the firm for production before the enforcement curve.
The bottom line
eIDAS 2.0 is the largest single change to EU identity verification in a decade. The December 2026 deadline is fixed. Citizens will start presenting wallet-based credentials in production from that point forward. Verification stacks that cannot ingest, verify, and document wallet credentials will be running manual fallback workflows while citizens with wallets find competitor firms that handle the flow natively. The right procurement move is to evaluate the current vendor against the readiness matrix, confirm a concrete roadmap with months attached, and schedule a pilot integration in Q3-Q4 2026.
Book a call to assess your eIDAS 2.0 readiness, Zyphe compliance team available, and we will walk through the 12-point readiness matrix against your current stack.
Related resources
- KYC API integration, 15-minute integration guide
- Why your KYC vendor is your biggest data breach risk, Architectural exposure
- Decentralised KYC primer, What it is, how it works
- KYC for Crypto Exchanges 2026, Tiered onboarding architecture
- AML transaction monitoring 2026, What the regulations require
- Zyphe MCP launch, Talk to your compliance stack
Cited sources
- European Union, Regulation (EU) 2024/1183 on European Digital Identity
- European Commission, European Digital Identity Architecture Reference Framework
- W3C, Verifiable Credentials Data Model
- ISO, ISO/IEC 18013-5 Mobile Driving Licence
- OpenID Foundation, OpenID for Verifiable Credentials
- ENISA, Digital Identity Solutions guidance
Michelangelo Frigo(Co-Founder at Zyphe)Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.