- Insights
How to be eIDAS 2.0 ready in 2026
ㅣ
Thomas Galvaing
Halfway through 2026, eIDAS 2.0 has stopped being a regulation to watch and become a deadline to meet. By December 2026, every EU Member State must offer at least one certified EU Digital Identity (EUDI) Wallet. Roughly twelve months later, a long list of organizations will be legally required to accept it.
But "being eIDAS 2.0 ready" means two very different things depending on where you sit in the trust chain:
Qualified Trust Service Providers (QTSPs) — the certified entities that issue qualified certificates for electronic signatures and seals — face a re-certification and re-engineering challenge: new technical standards, new identity proofing rules, and a wallet that changes how signatures get created.
Relying parties — banks, platforms, and regulated enterprises that verify identities — face an integration and acceptance challenge: registering as wallet-relying parties and plugging wallet verification into their user journeys before acceptance becomes mandatory.
Different obligations, different problems, different clocks. This article separates the two, so you can find your track and act on it.
Where eIDAS 2.0 stands in mid-2026
Since the regulation entered into force in May 2024, the technical rulebook has filled in fast. The core wallet implementing acts (integrity, protocols and interfaces, certification, relying party registration, trust framework) were adopted in late 2024, starting the 24-month clock to the December 2026 wallet deadline. Through 2025, the Commission adopted the trust service implementing acts — covering qualified certificates, validation, remote signature creation devices, identity verification for certificate issuance, timestamps, preservation, and new services like qualified archiving and electronic ledgers. Several acts are already being amended to track the evolving Architecture Reference Framework.
Member State readiness is uneven: fewer than a third currently meet readiness benchmarks. Germany has scheduled its state wallet for early January 2027 after its January 2026 sandbox; France plans public testing in the second half of 2026; Poland is integrating the wallet into mObywatel. Expect some wallets in December 2026 and a wave through 2027.
The uncertainty phase is over. What remains — for both tracks — is execution.
Track 1: QTSPs issuing qualified certificates for e-signatures
The regulatory requirements
QTSPs are the trust anchor of the eIDAS ecosystem, and eIDAS 2.0 tightens nearly every bolt:
New reference standards for your core services. The 2025 implementing acts set binding reference standards for qualified certificates for e-signatures and seals (IR 2025/1943), validation services (IR 2025/1942), preservation (IR 2025/1946), remote QSCD management as a qualified trust service in its own right (IR 2025/1567), and timestamps (IR 2025/1929). Services built under eIDAS 1.0 profiles must be reviewed against these standards.
Stricter identity verification at certificate issuance. IR 2025/1566 defines exactly how you must verify the identity of natural and legal persons before issuing a qualified certificate or attestation. Since May 2026, remote identity proofing must comply with the new certified requirements — the days of loosely harmonized national practices are over. The EUDI Wallet itself becomes a recognized (and eventually preferred) identification means for certificate issuance.
Harmonized conformity assessment and heavier oversight. Accreditation rules for conformity assessment bodies (IR 2025/2162), harmonized audit schemes, mandatory incident reporting aligned with NIS2, and annual supervisory reporting replace the patchwork of national approaches. Your next audit will not look like your last one.
The wallet as a signing channel. From December 2027, EUDI Wallets must let citizens create qualified electronic signatures free of charge (for non-professional use). Wallet-based signing turns the wallet into both a distribution channel and a competitive constraint for QTSPs: identification happens in the wallet, and the QES creation flow must connect to it.
The problematics
The hard part for QTSPs isn't understanding the rules — it's sequencing. Re-certification against new ETSI-referenced standards must happen while some of those standards are still being amended. Conformity assessment capacity is a real bottleneck: few accredited CABs, and everyone's audit is due in the same window. Remote identity proofing certification (mandatory since May 2026) caught providers mid-cycle — the first movers, like Namirial, certified early and are now marketing that head start. And architecturally, wallet-based signing forces a rethink of remote signing platforms: where does the key live, how does the wallet authenticate the signer, and does your remote QSCD management comply with IR 2025/1567?
There's also a business-model problem hiding in the compliance problem: when the wallet handles identification and offers free QES to citizens, QTSPs must reposition — toward B2B signing volume, qualified attestations of attributes, and value-added services — before 2027 makes that repositioning urgent.
The timeline
Date | What it means for QTSPs |
|---|---|
May–Dec 2025 | Trust service implementing acts adopted; transition windows open |
May 2026 | Certified remote identity proofing becomes binding for qualified services |
2026–2027 | Re-audits under harmonized conformity assessment; alignment with new reference standards |
Dec 2026 | Wallets arrive — wallet-based identification for certificate issuance becomes real |
2027 | Transition periods on trust service acts close; wallet QES (free for citizens) must be supported by Dec 2027 |
For a deeper dive on what's falling through the cracks, see our recent piece: 3 things slipping under QTSPs' radar before the 2027 eIDAS deadlines.
Track 2: Relying parties — enterprises that verify identities
The regulatory requirements
If you consume identities rather than certify them, your obligations are fewer but blunter:
Mandatory acceptance by late 2027. Private relying parties required to use strong user identification — banking and financial services, telecoms, energy, transport, healthcare — and very large online platforms must accept the EUDI Wallet where they perform strong customer authentication or identity verification. Public services must accept it too. Thirty-six months after the core implementing acts puts this around December 2027.
Registration before integration. To request data from a wallet, you must register as a wallet-relying party in the national register of the Member State where you're established (IR 2025/848, currently being updated), declaring what data you'll request and why. Registers are coming online through 2026. Over-asking is a compliance risk under both eIDAS 2.0 and GDPR.
A new technical stack. Wallet interactions rely on OpenID4VP, mDoc and SD-JWT VC credential formats, relying party access certificates, and trust list validation — with selective disclosure by design. Users will share attributes ("over 18", "resident of France"), not document photos.
The problematics
The relying-party problem is less about certification and more about fragmentation and funnel design. Twenty-seven Member States, multiple wallets per country, evolving specifications, and per-country trust infrastructure make direct integration a moving target — which is why the build-vs-partner question matters (we've covered it in The build vs. partner decision). Registration is administrative lead time most teams underestimate. And through 2027–2028 you'll run a dual-track journey: wallet-first for users who have one, traditional IDV as fallback — a UX and orchestration problem, not just an API integration.
This is exactly the problem the intermediary model was designed to solve — and eIDAS 2.0 explicitly recognizes it. Instead of every enterprise registering, integrating, and maintaining trust infrastructure against every wallet in every Member State, an intermediary does it once, on behalf of many relying parties: one registration burden absorbed, one API exposed, one compliance surface maintained as the specifications evolve. The relying party keeps control of its user journey and data purposes; the intermediary carries the fragmentation. We've made the full case in Why the intermediary is the way forward for trusted and compliant digital identity — in 2026, it moves from "a sensible option" to the default architecture for wallet acceptance.
The upside is equally concrete: verification that took minutes (and lost 20–40% of users) becomes a two-tap consent flow at Level of Assurance High. Early movers convert wallet holders while competitors still ask for selfies.
The timeline
Date | What it means for relying parties |
|---|---|
Through 2026 | National relying-party registers open — register early |
Dec 2026 | Wallets become available; early acceptance = conversion advantage |
H1 2027 | Integration and pilots against live national wallets |
Dec 2027 | Acceptance becomes mandatory for obliged sectors and VLOPs |
A realistic enterprise plan working backwards from December 2027: legal scoping in Q3 2026, registration and vendor selection in Q4 2026, integration and pilot in H1 2027, production rollout with fallback flows in H2 2027. "We'll look at it in 2027" is, in practice, a decision to be late.
Two tracks, one ecosystem
QTSPs (qualified certificates for e-signatures) | Relying parties (enterprises) | |
|---|---|---|
Core obligation | Re-certify services against new standards; comply with new identity proofing rules; support wallet-based QES | Register as wallet-relying party; accept the wallet where strong identification is required |
Binding since | May 2026 (remote identity proofing) | — (registration opening through 2026) |
Hard deadline | 2027 (transition periods close; wallet QES by Dec 2027) | Dec 2027 (mandatory acceptance) |
Main problematic | Audit sequencing, CAB capacity, signing-platform re-architecture, business-model shift | Fragmented integration across 27 states, registration lead time, dual-track UX |
Strategic upside | Wallet as distribution channel for QES and attestations | Cheaper, faster, high-assurance onboarding at scale |
The two tracks meet in the middle: relying parties will need qualified signatures in their flows, and QTSPs will need relying-party-grade wallet integration to deliver them. The organizations that understand both sides of the trust chain will move fastest.
Think bigger than the EUDI Wallet
Here's the reframe worth making before you scope your project: an EUDI Wallet readiness project is really a digital identity project — and digital identity doesn't stop at the EU border.
The EUDI Wallet is one instance of a global movement. India's Aadhaar-based stack, Singapore's Singpass, the Nordic BankIDs, Belgium's itsme, mobile driver's licenses across US states, and dozens of other government-backed eID schemes are all converging on the same promise: verified, reusable, high-assurance identity in the user's hands. If you serve users beyond one market — and most digital businesses do — designing your architecture around a single European wallet is solving 2027's compliance problem while ignoring the larger opportunity.
Because the benefits you're chasing are universal, and available now:
Better UX — government-backed eIDs turn minutes of document capture and selfie checks into a few taps of consent, at a higher level of assurance. Users who already hold an eID don't need to prove who they are from scratch, ever again.
Fraud reduction — cryptographically verified, government-issued identity is structurally harder to forge than document photos, at a time when generative AI is making document and biometric fraud cheap.
Cost savings — eID verification costs a fraction of manual review and legacy IDV per check, and eliminates the re-verification loops that inflate KYC operations.
The strategic move in 2026 is not "add EUDI Wallet support." It's "adopt an identity acceptance layer that treats the EUDI Wallet as one of many eIDs" — so every benefit lands as soon as your users hold any digital identity, not only when the European rollout completes. Waiting for December 2026 to capture these gains means leaving conversion, fraud losses, and verification costs on the table for every non-EU user and every EU user who already has a national eID today.
One integration, the whole identity universe
This is precisely how we built Hopae Connect — and why it will be certified in the first group of eIDAS 2.0 intermediaries. Being in the first certification wave means our customers get compliant EUDI Wallet acceptance from day one of the rollout, without carrying the registration, trust infrastructure, or per-country integration burden themselves.
And the economics are the point: for the same cost and the same level of resource engagement as an EUDI Wallet integration, Hopae Connect gives you access to the EUDI Wallet and every other eID in the world — European national schemes, Asian identity stacks, mobile driver's licenses, and the wallets still to come. One project, one API, one compliance relationship; global coverage from the start, with new schemes added without another line of your code.
Ready to start? Whether you're a QTSP connecting qualified signatures to the wallet or an enterprise preparing for mandatory acceptance, talk to an identity expert.
Timeline diagram
