eIDAS 2.0 splits wallet readiness into two governance tracks

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Hopae's blog post: eIDAS 2.0 readiness now splits into a QTSP certification track and a relying-party acceptance track, each with different deadlines and technical obligations.

Why it matters: Identity teams, trust service providers, and regulated enterprises need to separate certification work from integration work so wallet acceptance does not become a late compliance scramble.

By the numbers:

• By December 2026, every EU Member State must offer at least one certified EU Digital Identity Wallet.

Context

eIDAS 2.0 is no longer a policy horizon item. The practical question in 2026 is how trust services, relying parties, and wallet ecosystems align before mandatory acceptance and certification deadlines arrive.

The governance gap is structural: one side of the ecosystem must prove and re-certify trust services, while the other must prepare to accept wallet-based identity flows without breaking existing onboarding and assurance models.

Key questions

Q: What should teams do first when eIDAS 2.0 deadlines approach?

A: Start by mapping which services must recognise qualified electronic signatures, seals or identity assertions under the new rule set, then check whether your trust service, proofing and certificate processes can support them. That usually means aligning assurance levels, wallet acceptance, revocation handling and audit evidence across enrolment, issuance and verification workflows.

Q: Why does wallet-based identity force changes in certificate issuance?

A: wallet-supported identity proofing changes certificate issuance because the proofing event and the credential lifecycle must be linked to a wallet-held identity assertion, not just a standalone certificate request. Issuers need stronger binding, revocation paths, and policy checks so certificates are issued only after the wallet identity claim and subject control are established.

Q: What happens when regulated services must accept EUDI Wallets?

A: Regulated services must accept EUDI Wallets by adding verification flows that trust wallet-presented identity data, signatures and proofs while still enforcing their own policy, assurance and consent checks. That typically affects onboarding, authentication, attribute verification, certificate acceptance and revocation handling, because the wallet becomes part of the trust chain.

Technical breakdown

Why eIDAS 2.0 creates two separate readiness paths

The regulation creates different obligations for different actors in the trust chain. QTSPs must align signature, validation, preservation, timestamping, and remote signing services to new implementing acts, while relying parties must register and prepare to consume wallet-based identity and attributes. That split matters because certification work and acceptance work have different ownership, timelines, and control points. One track is about how trust is issued and maintained; the other is about how identity is consumed inside a business process. See the eIDAS 2.0 and the European Digital Identity Framework Guide.

Practical implication: Separate compliance planning for certificate providers and relying parties instead of treating wallet readiness as one programme.

How wallet-based identification changes certificate issuance

EUDI Wallets alter certificate issuance because identification can move into the wallet flow itself. That changes the assurance model for qualified certificates, especially where remote identity proofing, signer authentication, and qualified signature creation now depend on wallet-supported trust mechanisms. In practice, the technical issue is not only a new interface. It is a shift in where identity evidence is asserted, validated, and reused across the lifecycle of the signature service. See the Wallet Unit Attestation and Device-Bound Keys Guide.

Practical implication: Review issuance architecture, signer verification, and trust list handling as a single control chain.

Why relying-party acceptance is an orchestration problem

For enterprises that verify identity, wallet adoption is less about cryptography alone and more about orchestration. Registration, trust-list validation, selective disclosure, fallback flows, and user-journey design all have to work together across different national implementations. The wallet becomes a governed input to onboarding and authentication, not a bolt-on document replacement. That means the integration challenge sits at the boundary between legal purpose, identity assurance, and front-end workflow design. See the Identity Proofing and KYC Guide.

Practical implication: Design wallet acceptance as a controlled identity journey with fallback paths, not as a simple API connection.

NHI Mgmt Group analysis

eIDAS 2.0 readiness is now a split governance problem, not a single compliance programme. QTSPs and relying parties face different obligations, different evidence, and different clocks. That means one team may be re-certifying trust services while another is only beginning acceptance design. Practitioners should stop treating wallet readiness as a single workstream and map it to the actual identity role they perform.

Wallet acceptance changes the control boundary for identity assurance. Once identification is embedded in the wallet, assurance no longer sits only in the onboarding form or document check. It moves into trust registration, selective disclosure, and wallet-supported credential handling. The implication is that identity governance must follow the assurance path, not just the user interface.

Remote identity proofing becomes a lifecycle control, not a point-in-time check. The article shows that certified proofing requirements now sit inside a larger issuance and re-certification cycle. That makes proofing evidence, audit timing, and service certification interdependent rather than separate administrative tasks. Organisations should treat proofing as part of the certificate lifecycle, not a one-off validation event.

Selective disclosure will force a rethink of data minimisation in enterprise journeys. Wallet flows are designed to share attributes, not full document images, which alters how relying parties ask for, receive, and retain identity data. This creates a governance opportunity as well as a compliance constraint. Practitioners should redesign purpose statements and data requests around the minimum attributes actually needed.

Trust-chain sequencing: the core failure mode is not wallet support itself but the assumption that certification, registration, and acceptance can be sequenced lazily. That assumption breaks when one population is under re-certification pressure and another must accept wallet flows on a fixed deadline. The implication is that identity programmes need explicit dependency mapping across trust services and relying-party journeys, not just a single roadmap.

What this signals

Wallet readiness now looks like an orchestration programme as much as a compliance one. The hard part is sequencing trust service certification, relying-party registration, and production integration so the ecosystem can absorb the deadline without breaking identity assurance.

Trust-chain sequencing: the most important planning concept is to treat certification, registration, and acceptance as dependent controls rather than independent milestones. Once that is clear, wallet projects can be governed as lifecycle changes instead of one-off integrations.

For practitioners

• Map obligations by actor role Separate QTSP, relying-party, and public-sector obligations into distinct delivery tracks with separate owners, deadlines, and approval gates.
• Rework certificate issuance architecture Review how identity proofing, signer authentication, remote QSCD handling, and trust-list validation connect in the qualified certificate lifecycle.
• Register relying parties early Prepare national registration details, requested data purposes, and fallback onboarding logic before wallet acceptance becomes mandatory.
• Redesign user journeys for selective disclosure Reduce data requests to the minimum attributes needed and keep non-wallet fallback flows available while national implementations mature.

Key takeaways

• eIDAS 2.0 readiness now splits across two governance tracks, with QTSPs and relying parties facing different obligations and clocks.
• Wallet-based identity changes where assurance lives, moving part of the control boundary from document handling to trust registration and credential presentation.
• Teams that separate certification work from integration work will have a better chance of meeting mandatory acceptance timelines without destabilising onboarding.

Related NHI Mgmt Group resources: eIDAS 2.0 and the European Digital Identity Framework Guide · Wallet Unit Attestation and Device-Bound Keys Guide · Identity Proofing and KYC Guide · Digital Identity, eID and Identity Wallets Guide

Key terms

• Eudi Wallet: A digital identity wallet is a user-controlled container for identity credentials, attributes, and presentation proofs. In regulated environments, it becomes part of the trust chain because relying parties may accept its claims for authentication, onboarding, or transaction approval.
• Remote QSCD: A Remote QSCD is a qualified signature creation device that operates off the user’s local hardware and is accessed over a network. It performs signature creation in a controlled remote environment, with keys protected under qualified trust service rules and subject to stronger assurance, access control and audit requirements.
• Qualified Trust Service Provider: A qualified trust service provider is an organisation authorised to deliver trust services such as digital signatures, seals, timestamps, or certificates under EU trust rules. In practice, it must prove strong governance, resilience, and accountability because its services underpin digital trust for regulated transactions.
• Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.