.svg)
.svg)
.png)
Most guides to EUDI Wallets are catalogues of things you could do. Open an account in minutes. Verify a driving licence. Check an age without seeing a birth date.
They rarely explain what a company has to do to be allowed to do any of it.
Here is the honest summary. Getting started is not primarily an integration project. It is a registration project. And the registration decides what your product is allowed to ask for, before you write any code.
This guide sets out what registration involves, what differs between issuing and accepting credentials, and what you can usefully do while the registers are still closed. It is current as of August 2026.
The ecosystem splits into two jobs. Most businesses need one of them. Some need both, and they are not interchangeable.
Issuing. You put credentials into a customer's wallet. A university issues a diploma. An insurer issues a policy attestation. A bank issues proof of an account relationship. In the framework's language you are an attestation provider, and you register the attestation types you intend to issue.
Accepting. You ask a customer to present something from their wallet. You verify it and act on the result. Here you are a wallet-relying party, and you register the attributes you intend to request and the purpose you will use them for.
One point that catches businesses out. If you plan to work through a third party that talks to wallets for you, that intermediary counts as a relying party in its own right under the framework, and it may not store the data passing between the user and you.
Commission Implementing Regulation (EU) 2025/848, adopted on 6 May 2025, sets the rules. Every Member State must establish at least one national register, designate a registrar to run it, and publish the contents online in both human-readable and machine-readable form.
You register in the Member State where your organisation is established, under Article 5b of the amended eIDAS Regulation. Where a Member State runs more than one register, you appear in one of them only.
The information required is set out in Annex I. In practice it covers four things.
Who you are. Legal name as it appears in an official record, an identifier such as a European Unique Identifier, the physical address where you are established, and contact details a wallet user can actually reach.
What you are entitled to do. Your entitlements, whether you are a public sector body, and whether you intend to rely on electronic identification of natural persons.
What you intend to use wallets for. Each intended use, the data you will request for it, and a privacy policy URL for that use.
Whether someone acts for you. If you use an intermediary, you declare it and the association is recorded.
Registrars must run online and, where possible, automated processes, and respond to an application within five working days. They verify your information against supporting documents or authentic sources, and reject the application if they cannot.
Registration produces two artefacts. Businesses routinely conflate them, and they do different work.
A wallet-relying party access certificate authenticates you to a wallet unit. It is what proves to the wallet that it is talking to a registered entity. Access certificates follow common requirements so that wallets can authenticate you regardless of which Member State you are established in.
A registration certificate carries your intended use. It states what you registered to ask for, and it includes a general access policy, harmonised across the Union, that tells the user you are only allowed to request that data for that purpose.
The second one is the one to think about early, because it is visible to your customer at the moment they decide whether to share.
This is the part that changes how you plan the work.
Under Article 5b, a relying party may not request data other than what it has registered. Asking for more than you registered is listed as grounds for suspending or cancelling your registration, alongside inaccurate information and breaches of the registration policy.
So the data your product asks for is fixed at registration, not at build time.
That inverts the usual order of work. Teams normally build a flow, then handle compliance around it. Here you settle your data model and your stated purpose first, because that declaration becomes a certificate the wallet shows to the user and enforces against.
The practical consequence is that scope creep has a paperwork cost. Adding one attribute to an onboarding flow is not a sprint task. It is a change to a registration.
You register in one Member State, and access certificates are built so that wallets across the Union can authenticate you. Registers are also expected to check that an entity is not already registered elsewhere, so the design discourages duplicate registrations.
That is not the same as a settled cross-border regime. The Architecture and Reference Framework's own working documents note that policies for multi-registration, whether per intended use or per Member State, and for cross-border registration, still need to be specified.
If you operate through several legal entities in several countries, treat this as an open question rather than a solved one, and one worth raising with your registrar early.
The amended eIDAS Regulation has been in force since 2024. What arrives on 24 December 2026 is the registration regime itself. Commission Implementing Regulation (EU) 2025/848 applies from that date, which is also the date by which Member States must make wallets available.
That is a legal date, not a date on which 27 registration desks open. Each Member State writes its own registration policy and runs its own registrar, so when a register actually starts accepting applications will differ from country to country. We set out what varies in access certificates, registration and scope.
As things stand, live relying party registration portals have not opened, and the EU trusted lists for these certificates have not been published. Reporting through the first half of 2026 consistently described the infrastructure as still to come.
The technical layer, though, has settled. The Architecture and Reference Framework reached version 2.9.0 on 21 May 2026, with the relying party registration topic marked final, and ETSI has published TS 119 475 covering relying party attributes and the certificate model.
So the specification you would build against exists. The counter you would queue at does not.
Decide first whether you register directly or work through an intermediary. Registering directly means a policy to read and a registrar to satisfy in every market you operate in. An intermediary files on your behalf and carries those differences for you. It is a registered relying party in its own right, and it may not store the data passing through. Which suits you depends on how many Member States you serve. Hovi can act as your intermediary, and we covered the trade-offs either way in EUDI intermediaries: what they are and why they matter.
Write down your data request before anything else. For each customer journey, list the exact attributes and the purpose. That list is what you will register, and what you will be held to.
Work out which entity registers. Registration follows establishment, not customers. A group with entities in four countries needs to decide which one registers for what, and that is a legal question before it is a technical one.
Build against the schemes that are open. France Identité, EUDI Wallet Deutschland, IT-Wallet and AltID have environments you can work against today. The formats and protocols do not change when registers open, so the work carries over. We set out what varies and what does not in 27 member states, 27 wallets.
Hovi works as an intermediary across the EU, and already operates inside current active EUDI ecosystems..
In the France Identité EUDI ecosystem and the German EUDI Wallet Deutschland ecosystem, we can help you integrate and verify against these and other EUDI wallets. You can build user onboarding and KYC identity verification flows using Person Identification Data and age verification credentials, and issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle.
See our live presentation from Paris at the France Identité event EUDIW Unfold #3, running verification demos with the France Identité digital wallet, built on the Hovi platform. Watch the full demo.
We have tested against ETSI TS 119 472-1 at the ETSI EAA Plugtests, covering SD-JWT VC and ISO/IEC 18013-5 across several government and private wallet providers.
Hovi gives you the orchestration layer to integrate with EUDI schemes and build your use cases at scale and connect with all 27 member state EUDI Wallets Book a demo with us today.
.svg)
