The eIDAS 2 regulation entered into force in May 2024. The European Digital Identity Wallet (EUDIW) is being deployed across all Member States. For organisations operating identification, signing or regulated service access journeys, this change is structurally significant, and the timeline is short.
What eIDAS 2 changes compared to eIDAS 1
eIDAS 1 (2014) laid the foundations: mutual recognition of electronic identification means, framework for qualified signatures. It worked, but with major limitations: fragmented adoption, weak cross-border interoperability, no solution for the end user.
eIDAS 2 addresses this with three major developments:
- The e-wallet obligation: each Member State must provide its citizens with a digital identity wallet (EUDIW) by the end of December 2026
- Verifiable attestations: beyond basic identity (PID), the wallet can contain qualified attributes such as diplomas, licences, professional certificates
- The acceptance obligation: online public services must accept the EUDIW; large private platforms (>50M users) will also be required to do so
For a CIO, the question is not “should we prepare?” but “how quickly?”
The technical standards behind the wallet
The EUDIW is built on an open technical stack, constructed around W3C and IETF standards:
OpenID for Verifiable Credentials (OpenID4VC)
The protocol for issuing and presenting attestations. It breaks down into two flows:
- OpenID4VCI (Verifiable Credential Issuance): how an authority issues an attestation to the wallet
- OpenID4VP (Verifiable Presentations): how the wallet presents proofs to a third-party service (the relying party)
SD-JWT and mdoc
Two credential formats coexist within the EUDIW framework:
- SD-JWT (Selective Disclosure JWT): JSON format, close to existing OAuth tokens, suited to web flows
- ISO 18013-5 / mdoc: binary format, optimised for offline use cases and proximity presentation (NFC, Bluetooth)
The choice of format directly impacts your integration architecture.
Relying Party: your role in the ecosystem
If your service consumes attestations from the wallet (identity verification, age verification, qualification verification), you are a relying party. This involves:
- Being registered with a trust authority
- Implementing OpenID4VP to receive and verify presentations
- Managing the selection of required attributes (principle of minimum disclosure)
- Tracing consents in accordance with GDPR
What will change in your journeys
Identification and KYC
Today, your E-KYC journeys probably rely on a combination: identity document + liveness detection + scoring. With the EUDIW, the State-verified identity (PID, Person Identification Data) is directly presentable from the wallet.
Practical consequences:
- Reduced abandonment rate (the journey is more fluid)
- Guaranteed assurance level of “High” (LoA High per eIDAS)
- Facilitated AML/CFT compliance if the identification vector is qualified
- But: an alternative path must be maintained for users without a wallet (at minimum during the transition period)
Electronic signature
eIDAS 2 clarifies and strengthens the framework for remote qualified electronic signatures (QES). The wallet can embed a qualified certificate enabling signature without a physical device (certified software QSCD).
For your signing journeys for contracts, regulated instruments or mandates, this means:
- QES accessible on mobile without a physical token or in-person visit
- Pan-European interoperability (a French signature recognised in Germany, Spain, etc.)
- Archiving with evidential value to be reassessed in light of new traceability requirements
Strong authentication (SCA / FIDO2)
The EUDIW can serve as a strong second authentication factor in PSD2 journeys. Convergence with already-deployed FIDO2 standards remains to be specified in the ARF (Architecture Reference Framework), but OpenID4VP flows are compatible with existing OAuth/OIDC architectures.
Pitfalls to avoid in the compliance process
Waiting for full standard stabilisation. The Large Scale Pilots (LSP), namely POTENTIAL, DC4EU and EWC, are underway. Specifications are evolving, but the high-level framework is stable. Waiting until 2026 to start means finding yourself in emergency mode.
Treating the EUDIW as just another authentication method. It is a rethinking of the trust model. It affects data governance, your contracts with your current KYC providers, and compliance documentation.
Ignoring user experience. The wallet is a mobile application. If your relying party journey is poorly designed (too many attributes requested, unclear flow), the user will abandon, even if the technology works.
Underestimating the registry workload. Your registration as a relying party requires validation by a competent authority. The process takes time. Start early.
Our recommendation: 3 levels of preparation
Level 1: Understand (now)
Map your existing journeys that will be impacted: identification, KYC, signing, access to regulated services. Identify your current providers and their EUDIW roadmap.
Level 2: Experiment (Q1-Q2 2026)
Set up a test environment based on the ARFs and implementing acts published in December 2024. Reference wallets (developed within the Large Scale Pilots) are available in test versions. Now is the time to validate your OpenID4VP flows before the first national production deployments.
Level 3: Integrate (Q3-Q4 2026)
Adapt your production journeys to accept the first EUDIW attestations before the December 2026 deadline. Maintain coexistence with your current mechanisms during the transition period, the broader private sector only being required from December 2027.
Conclusion
eIDAS 2 and the EUDIW are not just another regulatory constraint. They represent a paradigm shift in digital trust across Europe. Organisations that correctly anticipate the compliance of their relying party journeys will be positioned to offer smoother, safer experiences with an unprecedented level of identity assurance.
The complexity lies not in the standards themselves, but in how they articulate with your existing architectures. That is precisely where our expertise makes the difference.
Do you have identification or signing journeys to evolve within this framework? Let’s talk.