Learn
A relying party that wants to accept the European Digital Identity Wallet has seven obligations under the amended eIDAS Regulation. It must register in the Member State where it is established, declaring the data it will request for each intended use. It must never request more than it registered. It must keep the registration current, identify itself to the user, authenticate and validate what the wallet presents, and not refuse a pseudonym where no law requires the user to be identified. And it must keep another way in, because using the wallet is voluntary. Most of this sits in Article 5b of Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, with the registration detail in Commission Implementing Regulation (EU) 2025/848.
This guide covers what you do once you are a relying party. Whether you are obliged to accept the wallet at all is a separate question, answered in our guide to who must accept the EUDI Wallet, and the dates are set out in the eIDAS 2.0 deadline guide. One point bridges the two: the registration duty in Article 5b applies to any relying party that intends to rely on the wallet, including one that does so voluntarily. The micro and small enterprise exception in Article 5f(2) takes you out of the duty to accept, not out of the rules for accepting.
| Obligation | What it means in practice | Where it says so |
|---|---|---|
| Register | Register in the Member State where you are established before relying on the wallet. | Art. 5b(1) |
| Declare your data | State the intended use and the data you will request from users, per intended use. | Art. 5b(2)(c); IR 2025/848 Annex I |
| Request nothing more | No data other than what the registration declares. | Art. 5b(3) |
| Keep it current | Tell the Member State without delay when registered information changes. | Art. 5b(6); IR 2025/848 Art. 5(3) |
| Identify yourself | Identify yourself to the user whenever you rely on the wallet. | Art. 5b(8) |
| Validate, allow pseudonyms | Authenticate and validate what you request; do not refuse pseudonyms where identification is not legally required. | Art. 5b(9) |
| Keep another route | Wallet use is voluntary, and other identification means must remain possible. | Art. 5a(15) |
What does registration involve?
Article 5b(1) is the starting point: where a relying party intends to rely upon European Digital Identity Wallets to provide public or private services by digital interaction, it shall register in the Member State where it is established. Article 5b(2) requires the process to be cost effective and proportionate to risk, and sets the minimum you provide: the information needed to authenticate to wallets, meaning your Member State of establishment, your name and, where applicable, your registration number in an official record; your contact details; and the intended use of the wallet, including an indication of the data you will request from users.
Implementing Regulation (EU) 2025/848 turns that into a form. Its Annex I lists what a relying party gives the national register, including official identifiers such as a business register number, LEI, VAT number or EUID, an address and contact details, a description of the type of services, and, for each intended use, a list of the data it intends to request, attestations and attributes included, in a machine readable format. It also asks whether you rely on an intermediary. Article 5 of the Implementing Regulation requires the information to be accurate at the time of registration and updated without undue delay. The Implementing Regulation applies from 24 December 2026.
Registration is public. Under Article 5b(5), Member States publish the registered information online, electronically signed or sealed and suitable for automated processing. Treat the declaration of intended use as something your customers, competitors and data protection authority can read.
What are access and registration certificates?
Two certificates come out of registration, and they do different jobs. An access certificate, defined in Article 2(12) of Implementing Regulation 2025/848, is a certificate for electronic seals or signatures that authenticates and validates the relying party; Article 7(2) says these are issued exclusively to registered relying parties. It is how a wallet knows it is talking to you. A registration certificate, defined in Article 2(15), is a data object that describes your intended use and the attributes you registered to request. It is how a wallet can show the user what you said you would ask for.
The second one changed this summer. As adopted in May 2025, Article 8 said Member States may authorise a certificate authority to issue registration certificates. Commission Implementing Regulation (EU) 2026/1730 of 15 July 2026 replaced that: Member States shall authorise at least one certificate authority to issue registration certificates, in an automated manner and without undue delay after registration. The same amendment says registrars collect your contact details, service description, requested data and intended use in an automated manner, for transparency, and shall not apply any preauthorisation process to that information. That is without prejudice to Article 5b(4), which keeps Union and national rules for specific services intact; subject to that, registration is a declaration you are held to, not an approval you wait for.
What data can a relying party ask for?
Only what it registered. Article 5b(3) says relying parties shall not request users to provide any data other than that indicated in the registration, and the Implementing Regulation gives the registrar teeth: Article 9(2)(c) of 2025/848 lets a registrar suspend or cancel a registration where the relying party is requesting more attributes than it registered. At the supervisory level, Article 46a(4)(f) of the amended Regulation lets a supervisory body suspend or cancel a registration in the case of illegal or fraudulent use of the wallet.
The wallet is built to make over asking visible. Under Article 5a(4), it lets the user present data with selective disclosure, generate pseudonyms, view an up to date list of the relying parties they have connected to and the data exchanged, request erasure of their personal data by a relying party under Article 17 GDPR, and report a relying party to the national data protection authority where a request for data looks unlawful or suspicious. Your data request is therefore logged on the user's side and one tap away from a complaint.
What must a relying party do at the moment of use?
Identify yourself to the user
Article 5b(8): where relying parties intend to rely upon wallets, they shall identify themselves to the user. The wallet side is covered by Article 5a(8)(b), under which Member States provide free validation mechanisms that let users verify the authenticity and validity of the identity of registered relying parties.
Authenticate and validate what you receive
Article 5b(9) makes relying parties responsible for carrying out the procedure for authenticating and validating the person identification data and electronic attestations of attributes they request. The wallet presents; you verify. Build that into your integration, not into a later audit.
Do not refuse pseudonyms
The same paragraph says relying parties shall not refuse the use of pseudonyms where the identification of the user is not required by Union or national law. An age check, a loyalty programme or a gated download rarely needs a legal name. Where a law does require identification, record which one on the intended use.
Keep a route that is not the wallet
Article 5a(15) says the use of the wallet shall be voluntary, that access to public and private services shall not be restricted or made disadvantageous for people who do not use it, and that it shall remain possible to access those services by other existing identification and authentication means. Accepting the wallet adds a route; it does not let you retire the others.
What if a vendor integrates the wallet for you?
Article 5b(10) says intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction. Your registration discloses the intermediary, under Annex I of 2025/848. Two things follow for procurement: the vendor carries relying party obligations of its own, and a contract that lets it keep transaction content is asking it to breach Article 5b(10).
Which relying parties must accept the wallet?
Three provisions create an acceptance duty. Under Article 5f(2), private relying parties that are required by Union or national law, or by contractual obligation, to use strong user authentication for online identification must accept the wallet upon the voluntary request of the user, no later than 36 months from the entry into force of the implementing acts referred to in Articles 5a(23) and 5c(6). Micro and small enterprises are excepted. The first of those implementing acts entered into force on 24 December 2024, which is why 24 December 2027 is the date usually calculated from it. Under Article 5f(3), very large online platforms designated under the Digital Services Act that require user authentication must accept and facilitate the wallet on the user's voluntary request, in respect of the minimum data necessary for the specific service. Finally, where a Member State requires electronic identification to access a public sector body's online service, Article 5f(1) requires the wallet to be accepted there too.
What happens if a relying party gets it wrong?
The fixed EUR 5 million or 1% floor in Article 16(2) applies to trust service providers, qualified and non qualified. For a relying party, Article 16(1) leaves penalties to each Member State, which must make them effective, proportionate and dissuasive. The sanction more likely to bite is operational: a registrar suspending or cancelling your registration under 2025/848, or a supervisory body doing so under Article 46a(4)(f), which switches off wallet acceptance until it is restored. The full picture is in our guide to eIDAS 2.0 fines and penalties.
What the other results get wrong
The relying party guides we read on page one date from February 2026, and they are good on the basics: register, declare, minimise. Three points are easy to miss. The first is age. Anything written before 15 July 2026 predates Implementing Regulation 2026/1730, so it cannot tell you that registration certificates are now mandatory for Member States to provide, or that registrars may not preauthorise your declared data.
The second is folding registration into acceptance. The Article 5f(2) exception for micro and small enterprises is an exception from the duty to accept. A small company that chooses to accept the wallet is still a relying party under Article 5b, and registers like everyone else.
The third is treating the wallet as a replacement for your existing login. Article 5a(15) keeps other identification routes open and bars making non wallet users worse off. Plan the wallet as an additional front door.
Where does your organisation stand?
Fill this in per service that will accept the wallet. A blank cell is the next piece of work.
| Question | Your answer | Why it matters |
|---|---|---|
| Which Member State will you register in, and under which official identifier? | Article 5b(1) and Annex I fix where and how you register. | |
| For each intended use, what exact attributes will you request? | The registered list is the ceiling for every request, under Article 5b(3). | |
| Which of those uses legally require the user to be identified? | Where none does, Article 5b(9) bars you from refusing a pseudonym. | |
| Who validates presentations, and where is that evidenced? | Validation is the relying party's responsibility under Article 5b(9). | |
| Does an intermediary sit in the flow, and does its contract bar storing transaction content? | Article 5b(10) makes it a relying party with that prohibition. | |
| What is the non wallet route for each service? | Article 5a(15) requires one to remain. | |
| Who owns updating the registration when a form or use changes? | Changes go to the register without delay, under Article 5b(6). |
If you want the whole eIDAS 2.0 picture scored first, the free compliance check gives you a baseline, and the eIDAS 2.0 framework page shows how these obligations are held as controls with evidence.
Frequently asked questions
Do we need approval before accepting the wallet?
You need to be registered, not approved. As amended in July 2026, Implementing Regulation 2025/848 bars registrars from applying a preauthorisation process to the contact, service, data and intended use information you declare. That is without prejudice to Article 5b(4), so Union or national rules that govern your specific service still apply.
Can we register once for the whole EU?
Article 5b(1) requires registration in the Member State where you are established. Member States then operate a common mechanism for identifying and authenticating relying parties under Article 5b(7).
Can we ask for a user's full identity to be safe?
No. You may only request what you registered for the intended use, and you may not refuse a pseudonym where no law requires identification.
When do the registration rules apply?
Article 5b entered into force with the amending Regulation on 20 May 2024. Implementing Regulation 2025/848, which sets out the registration mechanics, applies from 24 December 2026.
Are we still a relying party if a vendor handles the wallet integration?
Yes, and so is the vendor. Article 5b(10) deems intermediaries acting on your behalf to be relying parties and forbids them from storing data about the content of the transaction.
Primary sources
Obligations above are taken from Articles 5, 5a, 5b, 5f, 16 and 46a of Regulation (EU) No 910/2014, read in the consolidated text, as amended by Regulation (EU) 2024/1183; from Articles 2, 5, 6, 7, 8, 9, 10 and 11 and Annex I of Commission Implementing Regulation (EU) 2025/848; and from Commission Implementing Regulation (EU) 2026/1730, which amends it. The 24 December 2027 date is calculated from Article 5f(2), not stated in it. Consolidated texts are documentation tools; the Official Journal versions are authentic. Confirm the current text before relying on a specific provision.
