As the EU Digital Identity Wallet moves closer to rollout, the questions are getting more practical.
Not just: what is EUDIW?
But:
Where does a Relying Party register?
Does a business need to register in more than one country?
What does an intermediary do?
Who needs an access certificate?
And how does this work when a company uses a Wallet Hub instead of connecting to every wallet directly?
This FAQ breaks down the main registration questions we’re hearing from customers, partners, and teams preparing for wallet-based identity flows.
Quick answers
Where does a Relying Party register for EUDIW?
The basic rule is that a wallet Relying Party registers in the Member State where it is established.
The EUDIW trust framework is designed so a Relying Party can register once and authenticate wallet users from across the EU.
Does a Relying Party ever need to register in multiple countries?
Yes, sometimes.
Multiple registrations may be needed when a company operates through separate legal entities, holds different national regulated entitlements, runs different services through different country operations, or wants early access in countries where wallet readiness is moving faster.
Does an intermediary need to register in every country where its customers are based?
No.
Under the ARF model, the intermediary registers once as a Relying Party with its own Registrar and obtains access certificates in its own name. It can then help register intermediated Relying Parties in the Member States where those Relying Parties are established.
Does an intermediated Relying Party need its own access certificate?
No.
An intermediated Relying Party can rely on the intermediary’s access certificate for the wallet-facing interaction. But it still needs to be registered, and the wallet request should identify the underlying Relying Party and intended use.
Key terms
Before getting into the registration process, it helps to separate three terms that often get mixed together.
Access certificate
An access certificate is a cryptographically verifiable certificate used by Relying Parties to let a wallet verify who is connecting to it.
In simple terms: it helps the wallet know who is making the request.
Registration certificate
A registration certificate describes which information a Relying Party is registered or authorised to request, based on the intended use case or service.
In simple terms: it helps show what data the Relying Party is allowed to ask for.
Registrar
A Registrar is a body appointed by each Member State to maintain the list of wallet Relying Parties established in that country.
In simple terms: this is the national body responsible for registering Relying Parties.
1. When would a Relying Party need to register in multiple countries?
The simple rule is:
A wallet Relying Party registers in the Member State where it is established.
The goal of the EUDIW trust framework is that a Relying Party can register once and authenticate wallet users from across the EU.
But in practice, there are several situations where multiple registrations may be relevant.
Separate legal entities in different Member States
If a company group operates through separate national entities, each entity may need to register in its own Member State.
For example, if the Belgian, French, and German entities are each the actual service provider or Relying Party for their local service, each may need its own registration with the relevant national Registrar.
Different national regulated entitlements
Some wallet use cases depend on national authorisations.
This could apply to licensed banks, healthcare providers, professional bodies, education providers, or other regulated services.
If different national entities hold different local entitlements, each entity may need to register separately so the relevant Registrar can see who is requesting data, for what purpose, and under which authorisation.
Different services or intended uses
A Relying Party may register several services with different intended uses.
Each service may require a different set of attributes. In some cases, this may lead to more than one registration certificate.
If those services are operated by different legal entities in different countries, the registration picture becomes more country-specific.
Phased rollout and national readiness differences
This may become one of the more practical reasons.
Member States are not all moving at the same speed. Some countries may be ready to register Relying Parties earlier than others. Some may have stricter registration processes. Some may have production-ready national wallets before the full EUDIW certification and cross-border registration model is mature.
That could lead some organisations to look for the fastest or most practical route to access.
But this is still an evolving area, and national procedures will matter.
2. Does an intermediary need to register in the country of every Relying Party it supports?
No.
The ARF model says that an intermediary registers once as a Relying Party with a Registrar and obtains access certificates in its own name.
Separately, the intermediary registers each intermediated Relying Party using its services. Each intermediated Relying Party is registered in the Member State where it is established.
That means the intermediary may interact with different national Registrars, but it does not necessarily need to register as a separate Relying Party in every country where its customers are based.
What does the intermediary actually do?
In practice, the intermediary helps the Relying Party with the registration and wallet interaction layer.
That can include helping the Relying Party:
- register with the relevant national Registrar
- obtain the relevant registration certificate
- define the intended use
- define which attributes need to be requested
- prove the commercial or technical relationship between the Relying Party and the intermediary
- connect to wallets through the intermediary’s infrastructure
The registration record should show the relationship between the intermediary and the intermediated Relying Party.
The ARF also says the intermediary may need to provide evidence to the Registrar, such as a contract, proving that the intermediated Relying Party uses the intermediary’s services.
What does the wallet see in an intermediated flow?
In an intermediated wallet flow, the intermediary uses its own access certificate.
The request should also identify the underlying Relying Party, the Relying Party’s Registrar URL, and the intended use.
This means the wallet can show the user both:
- the intermediary handling the technical wallet connection
- the underlying Relying Party requesting the data
That distinction matters for transparency.
The user should understand who is technically processing the request and who will actually receive and use the data.
The big unknown: national procedure
The model is clear enough at a framework level.
The practical challenge is national procedure.
A national Registrar may require the intermediary to submit supporting documentation, authorisation, a mandate, a power of attorney, or other evidence before registering the intermediated Relying Party relationship.
If these procedures differ widely across Member States, they could create friction for intermediaries and Relying Parties.
This may become especially relevant in countries where a wallet is already in production, but not yet certified as a full EUDI Wallet.
.png)
3. Does an intermediated Relying Party need its own access certificate?
No.
Under the ARF model, an intermediated Relying Party does not need its own wallet-facing access certificate when it uses an intermediary.
It can rely on the intermediary’s access certificate for the wallet-facing interaction.
But this does not mean the Relying Party is invisible.
The intermediated Relying Party still needs to be registered. The intermediary separately registers each intermediated Relying Party, including the attributes that Relying Party wants to request for each intended use.
Where available, the wallet request can include the registration certificate of the intermediated Relying Party.
So the simple version is:
The intermediary handles the wallet-facing access certificate.
The Relying Party still needs to be registered for the data it wants to request.
What does this mean for businesses preparing for EUDIW?
For businesses, EUDIW registration is not only a technical question.
It is also about legal entities, regulated services, intended use, requested attributes, national procedures, certificates, and the relationship between the Relying Party and any intermediary it uses.
Before production wallet access becomes urgent, Relying Parties should start mapping:
- which legal entity provides the service
- which country that entity is established in
- what wallet data is actually needed
- which attributes are mandatory for the use case
- whether the use case depends on a national authorisation
- whether the business wants to connect directly or through an intermediary
- what fallback identity methods are needed while wallet adoption grows
This is also where a Wallet Hub approach can help.
Instead of every Relying Party building and maintaining separate wallet connections country by country, an intermediary can handle the wallet-facing infrastructure and help customers navigate the registration and trust layer around it.
eID Easy’s role
eID Easy already aggregates national eIDs, Bank IDs, and digital signature services through one integration.
As EUDIW develops, we are building the eID Easy Wallet Hub to help Relying Parties interact with digital wallets through an intermediary model.
The goal is simple:
Help businesses access wallet-based identity flows without having to manage every wallet, certificate, registration path, and national implementation detail alone.
Got more questions about EUDIW Relying Party registration, intermediaries, or Wallet Hub access?
