Learn
If you are asking who must comply with eIDAS 2.0, the honest answer is that scope is set by the role you play and by a specific legal trigger, not by a list of company types. Regulation (EU) 2024/1183 amends the original eIDAS Regulation and builds the framework for the EU Digital Identity Wallet. It entered into force on 20 May 2024. Whether it reaches your organisation depends on what you do with identity data and, for a private relying party, on the strong user authentication trigger in Article 5f, not on whether you happen to work in a named industry.
This guide answers the scope question with a role-based decision tree. It covers the trigger in Article 5f, why the sectors named there are illustrative examples rather than a closed list, the micro and small enterprise exemption, the wider matrix of regulated eIDAS roles, and what an in scope relying party actually has to do.
Corrected on 13 July 2026: clarified that the sectors named in Article 5f are illustrative examples ('including in the areas of'), not a closed list; the operative trigger is a legal or contractual requirement to use strong user authentication.
The eIDAS 2.0 scope decision tree
Work through these questions in order. They move from the role you play, to the legal trigger, to the exemptions and the wider roles that can still catch you. Many organisations answer yes to more than one.
- Are you acting as a private relying party? A relying party requests identity data or attributes from users in order to provide a service online. If you never request identity data from users, the Article 5f acceptance duty does not reach you, although another eIDAS role further down this page still might.
- Are you required to use strong user authentication for online identification? This is the operative trigger. Article 5f applies when a requirement to use strong user authentication for online identification is imposed on you by Union law, national law, or a contractual obligation. If that requirement applies, the duty to accept the EU Digital Identity Wallet can arise. If no law and no contract imposes it, Article 5f does not compel you to accept the wallet.
- Does the micro or small enterprise exemption apply? Article 5f(2) exempts micro and small enterprises from the acceptance duty. Count your group and partner structure, not just your own entity, before you rely on this.
- Are you requesting wallet use voluntarily? You may choose to accept the wallet even where no law or contract forces you to. If you do, you take on the relying party obligations for that use, including registration and data minimisation.
- Does a sector-specific or national rule change the result? The sectors named in Article 5f, for example banking, healthcare, or transport, are areas where strong authentication requirements are common, so national or sector rules may create or sharpen the trigger. Being in a named sector does not by itself create the duty, and being outside the named sectors does not by itself remove it.
- Are you performing another regulated eIDAS role? Even if the private relying party duty does not apply, you may still carry obligations as a Member State, a wallet provider, a trust service provider, a web-browser provider, and so on. The role matrix below sets these out.
The Article 5f trigger: strong authentication, not sector
The core of the private sector duty is Article 5f. It applies to a private relying party when that party is required, by Union or national law, or by a contractual obligation, to use strong user authentication for online identification. That requirement is the trigger, and it is what pulls a relying party into scope.
Article 5f introduces its list of sectors with wording equivalent to 'including in the areas of'. That phrasing is illustrative. It points to areas where strong user authentication requirements are common, not to a closed or exhaustive list of who is caught. So being in a named sector does not, on its own, create the duty, and operating outside those sectors does not, on its own, put you beyond it. Test for the strong authentication requirement first.
The sectors named in Article 5f as examples are banking, financial services, transport, energy, healthcare, telecommunications, postal services, digital infrastructure, education, drinking water, and social security. Treat them as a prompt to check whether a strong authentication requirement applies to your online identification, not as the test itself.
The micro and small enterprise exemption
Article 5f(2) carves out the smallest organisations from the acceptance duty. Micro and small enterprises are exempt. The definitions follow the standard EU sizing. A micro enterprise has fewer than 10 employees and a turnover or balance sheet total up to EUR 2m. A small enterprise has fewer than 50 employees and a turnover or balance sheet total up to EUR 10m. The headcount test and the financial test must both be met to qualify.
One trap catches groups. Linked and partner enterprises are counted toward the totals. If you are a small subsidiary of a large group, the group headcount and turnover apply, and the exemption may not be available to you. Check the consolidated figures, not just your own entity, before you conclude that you are exempt.
The full eIDAS 2.0 role matrix
Article 5f is only one part of the Regulation. eIDAS 2.0 assigns duties across a set of roles in the identity ecosystem. The figure below shows the core roles most organisations recognise. The table that follows widens the picture to the fuller set of regulated roles. Find every role you occupy, because many organisations sit in more than one.
| Role | What triggers the obligation | What they must do |
|---|---|---|
| Member States | The Regulation applies to every Member State. | Provide at least one EU Digital Identity Wallet to citizens and residents (Article 5a), set up and supervise the national ecosystem, and notify the wallet. First wallets are due by the end of 2026. |
| EU Digital Identity Wallet providers | Issuing or operating a wallet recognised by a Member State. | Build and run the wallet to the certified technical and security specifications, keep it free for natural persons, and support the required attributes (Article 5a; see the consolidated Regulation). |
| Public-sector relying parties | Providing a public service that requires electronic identification. | Accept the EU Digital Identity Wallet for that service and follow the relying party rules on attributes and data minimisation. |
| Private relying parties | Required by EU law, national law, or contract to use strong user authentication for online identification (Article 5f). | Accept the wallet, register with the Member State, and declare and request only the necessary attributes. Micro and small enterprises are exempt (Article 5f(2)). |
| Very Large Online Platforms (DSA) | Designation as a Very Large Online Platform under the Digital Services Act. | Accept the wallet for authentication when a user voluntarily asks to use it, without forcing it or profiling the user. |
| Trust service providers | Providing trust services such as electronic signatures, seals, timestamps, or website authentication certificates. | Meet the qualified or non-qualified requirements, pass conformity assessment where required, report incidents, and operate under supervision (see the consolidated Regulation). |
| Web-browser providers | Providing widely used web browsers. | Recognise and display qualified certificates for website authentication so users can verify a site, subject to the safeguards in the Regulation (see the consolidated Regulation for the current text). |
| Conformity assessment bodies | Accreditation to assess wallets or trust services. | Certify and assess wallets, trust service providers, and their services against the applicable schemes and standards. |
| Voluntary wallet-relying parties | Choosing to accept the wallet with no legal duty to do so. | Once relying on the wallet, register and follow the same relying party obligations on attribute declaration and data minimisation. |
| Intermediaries acting for relying parties | Handling the wallet interaction on behalf of another relying party, for example an identity broker or payment service provider. | Meet the relying party obligations for the party they serve, stay transparent about their role, and request only the necessary attributes. |
What an in scope relying party must actually do
If you land in scope, the duty is not simply to switch on a button. A relying party has to register with its Member State before relying on the wallet, declare in advance which attributes it will request, and then request only the attributes necessary for the service. Data minimisation is built into the model. You accept the wallet as a valid means of identification and authentication, and you do not refuse valid attributes or combine the data beyond the stated purpose.
The technical deadline to be ready is 24 December 2027. That is when in scope relying parties must accept the EU Digital Identity Wallet. Member State wallets arrive earlier, by the end of 2026, which gives organisations a real window to pilot acceptance before the duty bites.
Working out your scope with Venvera
Scope is the first thing to get right, because everything downstream depends on it. The Venvera eIDAS 2.0 module maps the Article 5f trigger, the role matrix, and the SME test into a structured gap assessment, so you can see in one place whether the Regulation may apply to you and what you would need to accept the wallet. Because eIDAS 2.0 overlaps with obligations you may already meet, the crosswalk engine lets you reuse evidence from DORA, NIS2, and ISO 27001 instead of starting from zero.
If you want a fast read on where you stand, run a free compliance check and use the decision tree above as your starting point for readiness. eIDAS 2.0 amends rather than replaces the original eIDAS Regulation, so the trust services you already rely on stay in place while the wallet obligations are added on top.
