TRUSTTECH / BLOG

Who is required to accept the EUDI Wallet in 2026?

European passport and bank card on a government office desk beside a smartphone displaying a digital wallet interface.

Under eIDAS 2.0, which amends Regulation (EU) 910/2014, certain categories of organisations are legally required to accept the European Digital Identity Wallet. Public sector bodies must comply by 24 December 2026, while regulated private sector service providers have until 24 December 2027. This article breaks down exactly who must accept the EUDI Wallet, what that acceptance means in practice, and how organisations can start preparing today.

Which sectors are legally required to accept the EUDI Wallet?

Public sector bodies across all EU Member States are required to accept the EUDI Wallet for digital services that already require identity verification, with that obligation applying from 24 December 2026. Beyond government services, eIDAS 2.0 extends mandatory acceptance to specific private sector categories from 24 December 2027, including banking and financial services, telecoms, transport, energy, healthcare, education, social security, drinking water, postal services, digital infrastructure and digital services, and very large online platforms (VLOPs) with more than 45 million users in the EU.

The logic behind this scope is straightforward: the regulation targets sectors where identity verification is already a standard part of the service. If a bank must verify a customer’s identity to open an account, or a healthcare provider must confirm a patient’s identity before sharing medical records, those same interactions must be able to accept the EUDI Wallet as a valid identity instrument once the relevant deadline applies.

More specifically, the sectors covered under the mandatory acceptance rules include:

  • Government and public administration — any public service that currently requires identification online (deadline: 24 December 2026)
  • Banking and financial services — for customer onboarding, account access, and regulated transactions
  • Telecommunications — for SIM registration and identity-verified services
  • Healthcare — for patient identification and access to health records
  • Transport — for ticketing, licensing, and identity-dependent services
  • Energy utilities — for customer account services that require verified identity
  • Education — for identity-verified access to educational services
  • Social security — for benefit access and identity-dependent administrative services
  • Drinking water — for customer account services requiring verified identity
  • Postal services — for identity-verified service interactions
  • Digital infrastructure and digital services — where strong user authentication is legally or contractually required
  • Very large online platforms — those with more than 45 million users in the EU, as defined under the Digital Services Act, where users request authentication on a voluntary basis and for the minimum necessary data

For private sector organisations in the sectors listed above, the mandatory acceptance deadline is 24 December 2027, which is twelve months after the legal deadline for wallet issuance and public sector acceptance. Organisations operating in financial services and government are among those with the most immediate obligations, given that identity verification is already deeply embedded in their operations.

It is also worth noting that micro and small enterprises are excluded from the mandatory acceptance obligation. The exemption applies to organisations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros.

What does ‘required to accept’ actually mean under eIDAS 2.0?

Being required to accept the EUDI Wallet means that an organisation must technically support the wallet as a valid means of identity verification when a user presents it. In practice, this means building or integrating the technical infrastructure to receive, validate, and process identity attributes and credentials presented through a EUDI Wallet.

Acceptance does not mean the wallet becomes the only accepted method. Organisations are not required to abandon existing login or verification methods. What the regulation requires is that the EUDI Wallet is a supported and recognised option alongside whatever else the organisation currently uses.

In technical terms, this involves connecting to the EUDI Wallet ecosystem as a relying party. A relying party is any service provider that requests and receives identity data from a wallet holder. Under CIR (EU) 2025/848, adopted on 6 May 2025, a relying party must register with the national competent authority of its Member State of establishment before it can request wallet data. Registration is done per intended use, specifying which attributes and attestations will be requested. The wallet checks each presentation request against this registered scope.

Importantly, a relying party does not choose a wallet provider. The organisation must be able to accept every relevant notified wallet, regardless of which provider issued it or in which Member State. A relying party does not automatically require a qualified trust service provider (QTSP) for wallet acceptance. A QTSP becomes relevant in specific contexts, such as qualified signing or the issuance of qualified electronic attestations of attributes (QEAAs).

The legally binding requirements for how wallets and relying parties communicate are set out in the implementing acts adopted under eIDAS 2.0. The Architecture and Reference Framework (ARF) provides the technical elaboration of those requirements. Organisations must align their implementations accordingly. The obligation for regulated private sector organisations applies from 24 December 2027, but the technical integration timeline is not short, and preparation should begin well in advance.

Are private companies also required to accept the EUDI Wallet?

Yes, certain private companies are required to accept the EUDI Wallet, but not all of them. The obligation applies to private sector organisations in the sectors listed under eIDAS 2.0 where strong user authentication is legally or contractually required. The mandatory acceptance deadline for these private sector parties is 24 December 2027, as set out in Article 5f of the regulation.

The regulation specifically targets very large online platforms with more than 45 million users in the EU, and private service providers in regulated sectors. For VLOPs, the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data. For example, a large bank offering digital account opening is required to accept the wallet. A small independent web shop is not, and micro and small enterprises are explicitly excluded.

The distinction matters because many organisations are unsure whether they fall within scope. A useful way to assess this is to ask two questions:

  1. Does your service require users to verify their identity as part of accessing or using it, in a context where strong authentication is legally or contractually required?
  2. Is your organisation operating in one of the regulated sectors covered by eIDAS 2.0, or classified as a very large online platform under the Digital Services Act?

If the answer to both is yes, mandatory acceptance almost certainly applies. If you are uncertain, this is exactly the kind of question a structured compliance assessment can help resolve.

Private healthcare providers, insurers, and pharmaceutical companies with digital patient or customer-facing services should also pay close attention. The healthcare sector is explicitly within scope, and the line between optional and mandatory acceptance can be narrow depending on the nature of the service.

What happens if an organisation doesn’t comply by the applicable deadline?

Organisations that fall within the mandatory acceptance scope and fail to comply by the applicable deadline risk enforcement action from national supervisory authorities. Under eIDAS 2.0, supervision and enforcement are carried out at national level by the competent authorities designated by each Member State. The severity of any penalties will depend on national implementation choices and the applicable national legal framework.

Beyond formal penalties, non-compliance carries real operational and reputational risks. As EUDI Wallet adoption grows among citizens and businesses, organisations that cannot accept wallet-based credentials will face friction in their customer journeys. Users who expect to verify their identity using their national digital wallet will encounter a dead end, which damages trust and can drive them to competitors who have completed the integration.

There is also a procurement and partnership dimension. Public sector contracts and cross-border business relationships increasingly require demonstrated compliance with EU digital identity standards. Organisations that lag behind may find themselves excluded from tender processes or unable to meet the identity assurance requirements of their partners.

The practical advice is not to wait for enforcement. The technical integration timeline for becoming a compliant relying party is not short. Public sector bodies face a legal deadline of 24 December 2026, and regulated private sector organisations must comply by 24 December 2027. Organisations that have not started should prioritise a readiness assessment now.

How should organisations start preparing for EUDI Wallet acceptance?

Preparing for EUDI Wallet acceptance starts with understanding whether your organisation falls within scope, followed by a structured technical and compliance assessment of what changes are needed. The earlier this process begins, the more manageable the implementation becomes.

A practical starting path looks like this:

  1. Determine your scope: Identify which of your services require identity verification and whether they fall under the regulated sectors covered by eIDAS 2.0, and which deadline applies to your organisation.
  2. Map your current identity infrastructure: Understand how you currently verify user identity and where EUDI Wallet acceptance needs to be integrated.
  3. Register as a relying party: Engage with your national competent authority to understand the registration requirements under CIR (EU) 2025/848 applicable in your jurisdiction and begin that process. As part of registration, you will need to specify per intended use which attributes and attestations your service will request. Requirements may vary between Member States.
  4. Implement the required technical standards: Align your systems with the protocols and interfaces defined in the implementing acts adopted under eIDAS 2.0, using the Architecture and Reference Framework as the technical reference for that work.
  5. Test and validate: Use available reference implementations and pilot environments to validate your integration before go-live. The period following 24 December 2026, when Member States are legally required to make wallets available, provides an important window for private sector organisations to test acceptance ahead of their own 2027 deadline. Keep in mind that national wallet rollouts and practical interoperability may develop in phases, so testing should account for the specific wallet solutions and use cases relevant to your services.

When validating credentials received from a wallet, organisations should be aware that verification involves more than a single cryptographic check. A complete verification process covers three distinct steps: checking the issuer’s signature against the relevant national trusted list (which is part of the EU List of Trusted Lists); checking the revocation status using the issuer’s status information; and checking the wallet unit attestation to confirm that the presenting wallet is running on a certified wallet solution. Only the first of these checks can be performed fully offline.

Organisations should also monitor the implementing acts being adopted under eIDAS 2.0, as these contain the legally binding technical and procedural requirements for relying parties. The European Digital Identity Cooperation Group supports cross-border alignment and cooperation between Member States during this process. Staying current with both European-level developments and national implementation progress is essential for getting the integration right the first time.

You can find additional guidance and practical resources on the TrustTech resources page to support your preparation process.

How TrustTech supports 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 organisations preparing for the mandatory acceptance deadlines under eIDAS 2.0, the ID Connector handles the technical complexity of connecting to the EUDI Wallet ecosystem as a relying party. Concretely, this includes:

  • Wallet acceptance across Member States — accepting every notified EUDI Wallet regardless of the issuing provider or country
  • Trust management and verification — checking issuer signatures against national trusted lists, verifying revocation status, and validating wallet unit attestations
  • Attribute scope enforcement — ensuring that each presentation request stays within the attributes and attestations registered with the national competent authority
  • Qualified signing — supporting qualified electronic signatures via a connected QTSP, where this is required by the service
  • Identity data handling — processing verified identity attributes for identification and login flows across regulated sectors including financial services, healthcare, pharma, and government

The deadlines under eIDAS 2.0 are fixed: 24 December 2026 for public sector bodies, and 24 December 2027 for regulated private sector organisations. Contact TrustTech to find out how the ID Connector fits your services and what your next steps should be.