How can businesses accept EUDI Wallets without integrating each national wallet separately?

Businesses can accept EUDI Wallets from any EU Member State through a single integration point, without building separate connections to each national wallet. The interoperability framework built into eIDAS 2.0 means that every certified EUDI Wallet follows the same technical standards, so one integration covers them all. The sections below walk through how this works in practice, what it means for your organisation, and what to do next.

What is a relying party and how does it connect to EUDI Wallets?

A relying party is any organisation that requests and verifies identity data from a user’s EUDI Wallet. When a bank asks a customer to confirm their identity during onboarding, or a government portal requires authentication before granting access, that organisation is acting as a relying party. The term covers both public bodies and private companies across regulated sectors.

To connect to EUDI Wallets, a relying party must first register with a national authority in its Member State of establishment. This obligation follows from CIR (EU) 2025/848 of 6 May 2025. Once registered, the relying party receives access certificates. Every time it sends a data request to a wallet, the wallet checks those certificates before releasing any information.

Registration is not a formality. At the point of registration, a relying party specifies exactly which attributes and attestations it intends to request, per intended use. The wallet enforces this scope on every interaction. Requesting more data than registered is an explicit ground for revocation of the registration, which makes the scope declaration the most consequential practical step in the entire process.

One important distinction: the registration obligation sits with the organisation that delivers the service to the user. A technology supplier that processes wallet data on behalf of a client is a processor under Article 28 GDPR, not itself a relying party. The client organisation carries the registration.

Why would accepting each national EUDI Wallet separately be a problem?

If a business had to integrate with each national wallet individually, it would face a different technical connection, a different trust verification process, and potentially different data formats for every EU Member State. With 27 Member States each issuing at least one certified wallet by 24 December 2026, that would mean up to 27 separate integrations to maintain, test, and keep current as specifications evolve.

The operational cost alone would be significant. Each national wallet may be issued by a different provider, run on different infrastructure, and update on its own schedule. A business serving customers across multiple EU countries would need to track all of these simultaneously. For organisations in financial services, healthcare, or any other regulated sector where identity verification is a core process, that complexity would slow down every cross-border interaction.

There is also a trust management dimension. Verifying that a wallet presentation is genuine involves three checks: the issuer’s signature against the national trusted list, the revocation status of the attestation, and the wallet unit attestation confirming the presenting wallet runs on a certified wallet solution. Replicating that verification logic for each national system separately would multiply the risk of errors and gaps.

How does the EUDI Wallet interoperability framework solve this?

The eIDAS 2.0 regulation and its implementing acts establish a common technical baseline that every certified EUDI Wallet must meet, regardless of which Member State issues it. This means a relying party that connects to one certified wallet can, in principle, accept all of them, because the credential formats, exchange protocols, and trust anchors are standardised across the EU.

The technical foundation is the Architecture and Reference Framework (ARF), currently at version 3.0.0, which defines the formats and protocols all wallet solutions must implement. Two credential formats are mandatory: mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC. The exchange protocols are OID4VCI for credential issuance and OID4VP for presentation. Any certified wallet, from any Member State, uses these same building blocks.

Trust anchors work through national trusted lists (ETSI TS 119 612), which are aggregated into the EU List of Trusted Lists (LOTL). The ARF also introduces Lists of Trusted Entities (LoTE, ETSI TS 119 602) alongside the trusted lists. A relying party that can verify against these lists can validate presentations from any certified wallet without needing a bilateral arrangement with each national issuer.

Selective disclosure is built in. Users share only the attributes a relying party has registered to request. A user can prove they are over 18 without sharing their date of birth, because the issuer includes that derived attribute in the attestation. This works through the SD-JWT VC format without requiring zero-knowledge proofs.

What does a single EUDI Wallet integration actually look like for a business?

In practice, a single EUDI Wallet integration means connecting to one interface that handles the protocol layer, trust verification, and credential validation on your behalf. Your system sends a presentation request, the user approves it in their wallet, and verified identity data arrives in a structured format your application can use directly, whether for onboarding, authentication, or qualified signing.

The integration covers the three verification checks that every wallet presentation requires:

1. The issuer’s signature is validated against the relevant national trusted list.
2. The revocation status of the attestation is checked against the issuer’s published status information.
3. The wallet unit attestation is verified to confirm the presenting wallet runs on a certified wallet solution.

Only the first check works fully offline. Skipping the second means accepting potentially revoked attestations, which is a compliance risk in any regulated context. A well-built integration handles all three automatically.

Verified identity data can be reused across interactions within the same session or service flow, so a user who has already presented their identity for onboarding does not need to repeat the process for a subsequent signing step. The integration also needs to stay within the attribute scope registered with the national authority. If a request exceeds that scope, the wallet will abort the presentation.

Which sectors and use cases benefit most from EUDI Wallet acceptance?

The sectors that benefit most are those where identity verification is already a legal or contractual requirement, because EUDI Wallet acceptance replaces or supplements existing verification processes with a standardised, high-assurance mechanism. The wallet is issued at assurance level high, a level that most existing verification methods do not reach by default.

The regulation itself names the sectors subject to the private acceptance obligation under Article 5f, which takes effect on 24 December 2027:

• Financial services and banking: customer onboarding, KYC processes, account opening, and transaction authentication. The new AML Regulation (AMLR) applies from July 2027, five months before the acceptance deadline, which makes wallet-based identity verification directly relevant to AML compliance workflows.
• Healthcare and pharmaceuticals: patient identification, prescription handling, and access to health records across borders.
• Telecom, energy, and transport: SIM registration, contract signing, and service access where strong authentication is required.
• Government and public services: public bodies must accept certified wallets for online services requiring electronic identification from 24 December 2026, one year ahead of the private sector deadline.
• Education and social security: credential verification, benefit access, and cross-border recognition of qualifications (noting that recognition of professional qualifications remains governed by Directive 2005/36/EC, with the wallet serving as the carrier, not the recognition basis).

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 are exempt: organisations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros are not covered by the private acceptance obligation.

What should businesses do now to prepare for EUDI Wallet acceptance?

The most important step right now is registration. Under CIR (EU) 2025/848, relying parties must register with a national authority in their Member State of establishment before they can request wallet data. Registration requires specifying, per intended use, exactly which attributes and attestations the organisation will request. That scope declaration shapes every subsequent wallet interaction, so it deserves careful preparation.

Beyond registration, the practical preparation steps are:

1. Map your identity touchpoints. Identify every process in your organisation where identity verification, authentication, or signing occurs. These are the integration points where wallet acceptance will apply.
2. Review your attribute needs per use case. For each touchpoint, determine which attributes you actually need. The wallet enforces the registered scope strictly, so requesting more than necessary is both a compliance risk and a ground for revocation.
3. Check your logging practices. Record that you stayed within your registered attribute scope, not the full set of presented attributes. Logging everything would undermine the selective disclosure the wallet provides at the front end.
4. Do not tie customer records to a wallet unit identifier. When a user changes device, their attestations are reissued by the original issuer, not transferred. The same person will return with a different wallet unit and new attestations.
5. Assess your AMLR timeline alongside eIDAS. If your organisation is in financial services, the AMLR applies from July 2027, five months before the private acceptance deadline. Aligning both timelines now avoids parallel compliance projects later.

The deadline for public sector acceptance is 24 December 2026. For regulated private relying parties, the deadline is 24 December 2027. A legal deadline is the latest permissible date, not a target launch date. Organisations that start integration work in 2026 give themselves time to test, register, and iterate before the obligation takes effect.

How the ID Connector helps with EUDI Wallet acceptance

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.

For the specific challenge this article addresses, the ID Connector does the following:

• Validates issuer signatures against the relevant national trusted lists and the EU List of Trusted Lists, so your system does not need to maintain connections to each Member State’s trust infrastructure separately.
• Checks revocation status and wallet unit attestations on every presentation, covering all three verification steps automatically.
• Enforces the registered attribute scope per request, so presentations that exceed the registered scope are rejected before data reaches your application.
• Makes verified identity data reusable across interactions within the same service flow, reducing friction for users in onboarding, authentication, and signing sequences.
• Connects qualified signing to a qualified trust service provider (QTSP), so the signature itself is issued by the appropriate trust service. TrustTech does not issue qualified electronic signatures directly.

The ID Connector is relevant for organisations in financial services, healthcare and pharma, and government that are preparing for the 24 December 2027 private acceptance deadline or the earlier 24 December 2026 public sector obligation. To discuss what a single integration looks like for your organisation, get in touch with TrustTech.