What should businesses look for in an EUDI Wallet integration provider?

When evaluating an EUDI Wallet integration provider, organizations should look for a provider that handles trust management automatically, supports every certified European wallet regardless of which Member State issued it, and connects to the protocols and formats mandated by the Architecture and Reference Framework. The right integration layer removes the need to build and maintain that infrastructure yourself. The questions below unpack what that means in practice, from compliance knowledge to sector fit to the questions worth asking before you sign anything.

What capabilities should an EUDI Wallet integration provider have?

An EUDI Wallet integration provider should be able to accept every certified European wallet for identification, login, and qualified signing, handle trust verification automatically, and keep your integration current as implementing acts evolve. The core technical capabilities are non-negotiable: support for both credential formats (mdoc and SD-JWT VC), both exchange protocols (OID4VP for presentation and OID4VCI for issuance), and the proximity and online variants of ISO/IEC 18013-5 and 18013-7.

Beyond format support, verification is three separate checks, not one. A capable provider handles all three:

• Validation of the issuer’s signature against the relevant national trusted list (part of the EU List of Trusted Lists, LOTL)
• Checking the revocation status of the attestation, which requires querying status information published by the issuer
• Validation of the wallet unit attestation, which confirms that the presenting wallet runs on a certified wallet solution

Skipping the second check means your system may accept revoked attestations. Skipping the third means you cannot confirm the wallet itself is certified. A provider that describes verification as a single step is leaving gaps.

Equally important is scope enforcement. Under CIR (EU) 2025/848 of 6 May 2025, your registration as a relying party defines exactly which attributes you are permitted to request. The wallet checks every request against that registered scope and aborts the presentation if you exceed it. Requesting more than registered is an explicit ground for revocation of your registration. Your integration provider should enforce that boundary, not leave it to your development team to manage manually.

Finally, look for a provider that handles trust management across Member States. A wallet issued in Denmark is different from one issued in Austria, but your integration should accept both without custom work for each country.

How do you assess a provider’s eIDAS 2.0 compliance expertise?

Assess a provider’s eIDAS 2.0 compliance knowledge by checking whether they work from the actual regulatory texts and technical specifications, not summaries. A provider with genuine expertise will distinguish between the legal framework (Regulation (EU) 2024/1183), the implementing acts, and the Architecture and Reference Framework, and will be clear about what each layer requires.

A few concrete things to verify:

1. Deadline accuracy. The deadline for public sector wallet acceptance is 24 December 2026. The private sector acceptance obligation under Article 5f applies from 24 December 2027. Any provider who says “mid-2026” or “by 2026” for relying party obligations is working from outdated information.
2. Registration knowledge. Relying parties must register with a national authority under CIR (EU) 2025/848 before they can request wallet data. A provider should understand that this registration defines your permitted attribute scope and that exceeding it risks losing your registration.
3. ARF version awareness. The Architecture and Reference Framework is currently at version 3.0.0 and is updated regularly. A provider who cannot tell you which ARF version their implementation targets, or who treats the ARF as a static document, may be behind on technical requirements.
4. Trust infrastructure terminology. There is no single “EU Trusted List.” There are national trusted lists (ETSI TS 119 612) brought together in the LOTL, and ARF v3.0.0 adds Lists of Trusted Entities (LoTE, ETSI TS 119 602) alongside them. Confusing these with the relying party registers under CIR (EU) 2025/848 is a sign of shallow familiarity with the framework.

Also check whether the provider understands the limits of what eIDAS 2.0 covers. The wallet delivers a verified identity; whether a financial institution may rely on that for AML purposes is governed by the AMLR, not eIDAS. A provider who overpromises on regulatory scope is as much a risk as one who underdelivers technically.

What’s the difference between a wallet provider and a relying party integration specialist?

A wallet provider builds and operates the certified wallet application that citizens and businesses use to store and present their identity data. A relying party integration specialist helps organizations connect their services to accept presentations from those wallets. These are fundamentally different roles, and confusing them leads to the wrong procurement conversation.

As a relying party, your organization does not choose a wallet provider. Under eIDAS 2.0, you are required to accept every notified wallet, regardless of which provider issued it or which Member State certified it. What you do choose is the integration layer that sits on your side of that interaction.

That integration layer needs to handle the relying party’s responsibilities: registering the correct attribute scope, validating incoming presentations against the three verification checks described above, enforcing that your requests stay within your registered scope, and managing trust anchors across all certified wallets in the EU.

One important distinction for organizations using third-party technology: a vendor that processes wallet data on your behalf is a processor under Article 28 GDPR, not a relying party. The registration obligation under CIR (EU) 2025/848 stays with your organization, the party delivering the service to the user. Make sure any provider you work with is clear about where that line sits, particularly if you are using a platform or cloud-based solution.

For organizations in financial services or other regulated sectors, this distinction also matters for audit trails: your logs should record that you stayed within your registered attribute scope, not the full set of attributes presented.

Which sectors require sector-specific EUDI Wallet integration expertise?

The sectors named in Article 5f of eIDAS 2.0 as subject to the private acceptance obligation from 24 December 2027 are the ones where integration expertise matters most: banking and financial services, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services. Very large online platforms (VLOPs) designated under the DSA with more than 45 million EU users are also included.

Within those sectors, the integration requirements are shaped by additional regulatory layers that sit alongside eIDAS:

Financial services and banking face the intersection of eIDAS 2.0 with the new Anti-Money Laundering Regulation (AMLR), which applies from July 2027, five months before the private acceptance deadline. Whether a bank can rely on wallet-verified identity for KYC purposes is determined by the AMLR and sector-specific rules, not by eIDAS itself. The wallet provides the mechanism; AML law governs whether that mechanism satisfies the due diligence obligation. Organizations in this sector can explore how wallet acceptance fits into financial onboarding as part of their planning.

Healthcare and pharmaceuticals handle special category data under Article 9 GDPR. The legal basis for processing health data is usually the exception for care provision, not explicit consent, which means the wallet’s approval mechanism and GDPR consent are two different things. Integration in this sector needs to account for that distinction from the start.

Government faces the earlier deadline: public services must accept notified wallets from 24 December 2026. Cross-border identity matching is primarily a requirement for public bodies acting as relying parties, and the integration needs to handle wallet unit attestation validation and trust anchor management across Member States. Organizations working on government digital services should be planning for this now.

Micro and small enterprises are exempt from the Article 5f obligation: fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros. For everyone else in the listed sectors, the deadline is firm.

What questions should organizations ask a potential EUDI Wallet provider?

Before selecting an EUDI Wallet integration provider, organizations should ask questions that test both technical depth and regulatory accuracy. The goal is to surface gaps before they become integration problems or compliance risks.

Here are the questions worth putting to any provider you are evaluating:

• Which credential formats and exchange protocols do you support? The answer should include mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC, with OID4VP for presentation and OID4VCI for issuance. If a provider mentions W3C Verifiable Credentials as a supported EUDI Wallet format, that is a red flag: W3C VC DM is not listed as a recognized format in the current implementing acts.
• How do you handle the three verification checks? Signature validation against the national trusted list, revocation status checking, and wallet unit attestation validation should all be described as separate, active steps.
• How do you enforce registered attribute scope? The provider should be able to explain how their integration prevents your system from requesting attributes outside your CIR (EU) 2025/848 registration.
• Which ARF version does your implementation target, and how do you handle updates? The ARF is at version 3.0.0 and changes regularly. You need a clear answer on how the provider tracks and implements revisions.
• How do you handle wallet unit identifier changes? When a user switches devices, attestations are reissued by the original issuer rather than copied. Your customer records should never be tied to a wallet unit identifier. Ask how the provider’s integration handles returning users with new wallet units.
• Who holds the relying party registration? If the provider processes wallet data on your behalf, the registration obligation stays with your organization. Confirm this explicitly and ask how the provider supports you in maintaining compliance with your registered scope.

The answers to these questions will quickly distinguish providers who have built against the actual specifications from those working from high-level summaries. For organizations in healthcare or other regulated sectors, also ask how the provider handles the interaction between wallet-verified data and your sector’s specific legal requirements.

How TrustTech helps with EUDI Wallet integration

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 organizations working through the questions above, the ID Connector handles the following directly:

• Signature validation against national trusted lists and the LOTL, including Lists of Trusted Entities (LoTE) as specified in ARF v3.0.0
• Revocation status checking for incoming attestations
• Wallet unit attestation validation to confirm the presenting wallet runs on a certified wallet solution
• Enforcement of your registered attribute scope, so requests stay within what you declared under CIR (EU) 2025/848
• Reuse of verified identity data across interactions, without requiring the user to re-present for every session
• Qualified signing via a connected qualified trust service provider, for use cases that require a QES

The ID Connector is built for organizations in financial services, healthcare, pharmaceuticals, and government, where the combination of regulatory deadlines, sector-specific rules, and cross-border wallet acceptance creates the most complex integration requirements. Contact TrustTech to discuss what EUDI Wallet acceptance looks like for your organization.