Yes, a single identity verification solution can support both EUDI Wallets and traditional ID documents, provided it is built on a unified integration layer that handles the different technical protocols, trust frameworks, and data formats each channel requires. As eIDAS 2.0 reshapes how identity is exchanged across Europe, organisations in regulated sectors need to handle both channels simultaneously rather than choosing between them. The sections below unpack the key questions that come with that challenge.
What makes EUDI Wallet verification different from traditional ID checks?
EUDI Wallet verification and traditional ID document checks differ fundamentally in how trust is established, what data is shared, and how that sharing is controlled. With a traditional ID document, a relying party reads data from a physical or scanned document and applies its own checks to assess authenticity. With an EUDI Wallet, the trust chain is built into the protocol itself.
When a user presents an attestation from their EUDI Wallet, a relying party performs three distinct checks. First, it verifies the issuer’s signature against the national trusted list of the relevant Member State, which is part of the EU List of Trusted Lists (LOTL) under ETSI TS 119 612. Second, it checks the revocation status of the attestation, because the issuer publishes separate status information for this purpose and skipping this step means accepting potentially revoked credentials. Third, it validates the wallet unit attestation, which confirms that the presenting wallet is running on a certified wallet solution. Only the first of these three checks works fully offline.
The EUDI Wallet also operates at assurance level high, the top tier under eIDAS 2.0. Traditional verification methods rarely reach that level without additional steps. Beyond assurance level, the wallet introduces selective disclosure: a user can share a single attribute, such as proof of being over 18, without revealing their full date of birth or any other personal data. This is built into the credential formats supported by the Architecture and Reference Framework (ARF v3.0.0): mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC.
Traditional ID checks do not offer this granularity by default. A passport scan shares everything on the data page. A chip read via NFC gives structured data but still requires the relying party to extract only what it needs. The wallet shifts that control to the user, and the regulation enforces it: under Article 5a of eIDAS 2.0, a relying party that requests more attributes than it has registered under CIR (EU) 2025/848 of 6 May 2025 will have the presentation aborted by the wallet, and repeated overreach is an explicit ground for revocation of the registration.
Can a single identity verification solution handle both methods?
Yes, a single identity verification solution can handle both EUDI Wallet presentations and traditional ID document checks, but only if it abstracts the differences in protocol, format, and trust management behind one integration point. The two channels use different technical stacks, and a solution that handles only one of them forces organisations to maintain parallel systems.
For EUDI Wallet acceptance, the solution needs to support OID4VP as the presentation protocol, validate mdoc and SD-JWT VC credential formats, check issuer signatures against national trusted lists and the LOTL, verify revocation status, and validate wallet unit attestations. For traditional ID documents, it needs to handle optical character recognition, NFC chip reading, document authenticity checks, and liveness or biometric matching where required.
The practical argument for a unified solution is straightforward. During the transition period, many users will not yet have an active EUDI Wallet. The public sector deadline for wallet issuance and acceptance is 24 December 2026. The private sector acceptance obligation under Article 5f of eIDAS 2.0 applies from 24 December 2027, twelve months later. Between now and those dates, and for some time after, organisations will encounter users arriving with wallets, national eIDs, bank IDs, and physical documents. A solution that routes all of these through a single API removes the need to build and maintain separate verification flows for each channel.
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU. Verified identity data is reusable across interactions, and trust management behind wallet acceptance is handled within the connector.
What are the compliance implications of supporting both channels?
Supporting both EUDI Wallet and traditional ID document verification brings distinct compliance obligations for each channel, and organisations need to manage both sets simultaneously. The most immediate obligation for the wallet channel is registration under CIR (EU) 2025/848 of 6 May 2025.
Before a relying party can request data from an EUDI Wallet, it must register with a national authority in its Member State of establishment. Registration is not a formality. At registration, the relying party specifies exactly which attributes and attestations it will request, per intended use. The wallet checks every data request against that registered scope and aborts the presentation if the request exceeds it. Requesting more than registered is an explicit ground for revocation of the registration. Registered parties receive access certificates that wallets verify at each data request.
It is also worth noting the distinction between the relying party and any technology supplier it uses. The registration obligation sits with the organisation delivering the service to the user. A supplier that processes wallet data on behalf of a client is a processor under Article 28 of the GDPR, not itself a relying party. The client organisation remains responsible for registration.
For traditional ID document checks, the compliance picture is different. There is no wallet registration equivalent, but obligations under anti-money laundering rules, GDPR, and sector-specific regulations still apply. One important boundary: the EUDI Wallet provides the mechanism for identity sharing, but whether an organisation may rely on a verification performed elsewhere is governed by the Anti-Money Laundering Regulation (AMLR), which applies from July 2027, and by sector-specific rules, not by eIDAS 2.0 itself.
Organisations also need to be careful about logging. For the wallet channel, relying parties should record that they stayed within their registered attribute scope, not log the full set of presented attributes. Doing otherwise undermines the selective disclosure that the wallet provides at the front end.
Which sectors benefit most from a dual-channel identity approach?
The sectors that benefit most from supporting both EUDI Wallet and traditional ID document verification are those where strong user authentication is already legally or contractually required, and where the private sector acceptance obligation under Article 5f of eIDAS 2.0 will apply from 24 December 2027.
The regulation names these sectors explicitly:
- Financial services and banking: Customer onboarding, account opening, and transaction authentication all require verified identity. The EUDI Wallet delivers assurance level high, which satisfies strong customer authentication requirements. The AMLR, applying from July 2027, adds further pressure to have robust identity verification in place before the wallet acceptance deadline.
- Healthcare and pharmaceuticals: Patient identification, prescription handling, and access to health records require reliable identity checks across borders. The wallet can carry health attestations, including the European Health Insurance Card, while traditional document checks remain relevant for in-person or legacy system interactions.
- Government and public services: Public sector organisations face the earlier deadline of 24 December 2026 for accepting notified wallets for online services that require electronic identification. Many will also continue to serve users with traditional documents for some time.
- Telecoms, energy, transport, and education: All named in Article 5f as sectors subject to the private acceptance obligation where strong authentication is legally or contractually required.
Very large online platforms (VLOPs) designated under the Digital Services Act, with more than 45 million EU users, are also subject to the acceptance obligation from 24 December 2027, where users voluntarily request wallet-based authentication. Micro and small enterprises, defined as organisations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros, are exempt from the private acceptance obligation.
How should organisations evaluate identity verification vendors for EUDI Wallet readiness?
When evaluating identity verification vendors for EUDI Wallet readiness, organisations should focus on whether the vendor’s solution covers the full verification chain, handles both wallet and traditional document channels, and keeps pace with the evolving technical specifications. A vendor that supports only part of the chain or only one channel creates gaps that the organisation will have to fill elsewhere.
A structured evaluation should work through the following questions:
- Does the solution perform all three verification checks? Issuer signature validation against national trusted lists and the LOTL, revocation status checking, and wallet unit attestation validation. A solution that skips revocation checking accepts potentially invalid credentials.
- Which credential formats and protocols are supported? The ARF v3.0.0 requires mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC, with OID4VP as the presentation protocol. Vendors should also reference the High Assurance Interoperability Profile (HAIP) for high-assurance use cases.
- Does the solution handle traditional ID documents through the same integration? Organisations that need to verify passports, national ID cards, and other physical documents alongside wallet presentations benefit from a single API rather than separate integrations.
- How does the vendor handle trust management? Checking issuer trust against national trusted lists and the LOTL, and staying current as those lists are updated, is an ongoing operational requirement, not a one-time setup.
- Is the solution compatible with the registration obligations under CIR (EU) 2025/848? The vendor should support the access certificate flow that wallets use to verify registered relying parties at each data request.
- Does the vendor track ARF updates? The ARF is currently at version 3.0.0 and continues to evolve. A vendor whose implementation lags behind the current ARF version may create interoperability issues as certified wallets are updated.
Organisations should also verify that the vendor clearly separates the relying party role from the processor role. If the vendor processes wallet data on behalf of the organisation, the organisation remains the registered relying party and retains responsibility for staying within the registered attribute scope.
How TrustTech’s ID Connector supports dual-channel identity verification
The ID Connector from TrustTech is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
For organisations managing both wallet and traditional document verification, the ID Connector handles the following through a single connection:
- Issuer signature validation against national trusted lists and the EU List of Trusted Lists
- Revocation status checking for presented attestations
- Wallet unit attestation validation to confirm the presenting wallet runs on a certified wallet solution
- Enforcement of the registered attribute scope, so data requests stay within what the organisation has registered under CIR (EU) 2025/848
- Reuse of verified identity data across interactions, reducing repeated verification steps
- Support for traditional identity documents alongside wallet presentations through the same API
The ID Connector is built for organisations in financial services, healthcare and pharma, and government, where the combination of regulatory pressure and user diversity makes a dual-channel approach essential. To see how the ID Connector fits your organisation’s identity verification setup, get in touch with TrustTech.