The pressure behind the question "how to become an EUDI Wallet Relying Party?" is building up. With EU member states still at widely different points of implementation, and all still in very early stages of certification, information for relying parties is seemingly less of a priority for governments. However, even though the operational details will still depend on Member State implementation, the legal and technical shape is much clearer than it was a year ago.
In May 2025, the European Commission adopted the implementing regulation on the registration of wallet-relying parties. It applies from 24 December 2026, and it requires Member States to establish national registers for wallet-relying parties. ETSI has also published TS 119 475, which describes the relying party attributes and certificate model that supports wallet users in understanding who is asking for data and why.
The end-goal is clear: to become a registered Relying Party, an organisation will have to register with the relevant national register, declare who they are, what service they provide, what data they intend to request, and under which entitlement they are acting. After registration, they need the technical certificates that let wallets authenticate them and, where used, display their registered purpose and data request to the user.
That sounds simple, but there are still important open questions around how smooth this will be in practice, especially for organisations operating across borders. In this article we go into what we know for sure, and what we're expecting in terms of relying party registration.
What the Relying Party provides to the National Registrar
The implementing regulation is explicit about the baseline. Member States must establish and maintain at least one national register of wallet-relying parties for organisations established in their territory. Those registers must be available through a national website and a common API, and the public register information must be available in both human-readable and machine-readable form.
The regulation also tells us what kind of information Relying Parties should expect to provide. At minimum, this includes:
- A legal name or a recognisable service name
- Official identifiers such as a business registration number, VAT number, EORI, LEI or national identifier
- The address where the party is established
- A service URL
- Contact information
- A description of the service
- The intended use of the wallet data
- The attributes or attestations the party intends to request
- A URL to the Relying Party's privacy policy
- The lawful basis for processing the data, in order to comply with GDPR
The most operationally important part is the intended use. Relying Parties are not supposed to ask wallets for "whatever data might be useful later". They need to register the data they intend to request and explain why. The registration model is closely connected to data minimisation and user transparency: the wallet should be able to help the user understand whether a request matches the Relying Party's registered purpose.
It is worth stressing that, next to your eIDAS 2.0 responsibilities as a Relying Party, you still have to comply with other regulations that apply to your service, like GDPR. In practice this means defining the lawful basis for processing the wallet data you request, and being able to point to it as part of your registration.
Registrars, the National entities that will manage this system, must provide electronic registration processes that are easy to use and, where possible, automated. They also need to verify the registration information, including the Relying Party's identity, representative authority where relevant, entitlement, and whether the party is already registered elsewhere.
What certificates the Relying Party needs
Registration is only one part of the work. To interact with wallets, Relying Parties also need technical certificates.
The first is the Wallet Relying Party Access Certificate, or WRPAC. Under the implementing regulation, Member States must authorise at least one certificate authority to issue WRPACs, and those certificates may only be issued to registered wallet-relying parties. In practice, the WRPAC is what allows the wallet to authenticate the Relying Party during an interaction.
The second is the Wallet Relying Party Registration Certificate, or WRPRC. A WRPRC allows a Relying Party to provide proof to the wallet that it is allowed to request the data along with proof of its intended use. Usage of WRPRC is optional and determined by the member state. If WRPRCs are not used, the Wallet must dynamically retrieve the registration data from the country's registry.
ETSI TS 119 475 describes WRPACs and WRPRCs as complementary: the WRPAC authenticates the Relying Party, while the WRPRC communicates purpose, entitlements, and data access policy to the wallet and the user.
This WRPAC and WRPRC broadly tackle the two different trust questions that are relevant for the user:
- Is this really the party making the request?
- Is this party asking for data that fits its registered purpose?
Where the Relying party gets these certificates from, is dependent on National implementation. In the EU model, the registrar registers the wallet-relying party, but the WRPAC and WRPRC are issued by authorised certificate authorities / providers. Those roles can be connected in one onboarding route, but they do not have to be the same organisation.
ETSI TS 119 475 allows for multiple operational models: the registrar can be involved directly in certificate issuance, the relying party can request certificates after registration, or a certificate/provider service can assist with both registration and certificate issuance. So in practice, some countries may make it feel like one flow, while others may split it into separate registration and certificate steps.
How do you register as a Relying Party in practice?
Although national routes will differ, the preparation work for a Relying Party is already fairly clear.
⭐️ First, define the service. Describe the user journey, the countries involved, the user groups, and the decision the wallet result will support.
⭐️ Second, define the data request. Decide which attributes or attestations are genuinely needed, document the purpose, and map each requested data point to the service decision it supports.
⭐️ Third, prepare the registration package. Expect to collect legal entity details, official identifiers, contact information, a service URL, privacy policy URL, representative details where needed, the intended uses, and the list of requested attributes. If a sectoral entitlement applies, prepare the evidence for that as well.
⭐️ Fourth, complete the national route. The application will go through the registrar designated by the Member State. Depending on the national implementation, this may be a direct registrar portal, an automated API-backed process, or a process supported by an authorised certificate or service provider.
⭐️ Fifth, obtain and activate the relying party credentials. At minimum, that means a WRPAC. Where the Member State uses WRPRCs, it may also mean obtaining a registration certificate that expresses the intended use and registered data request. Operationally, this is where key management becomes important for a Relying Party: someone needs to control the private key, handle certificate activation, monitor expiry and revocation, and make sure production wallet requests are signed correctly.
With Paradym, we intend to integrate with National Registrars wherever possible, to enable registration, as well as any updates to the registration through the Parady platform.
Will there be an EU gateway for Relying Party registration?
There may be EU-level or ecosystem-level tooling that makes registration feel more centralised over time, especially because the regulation requires national registers to expose information for reading purposes through a common API. However, the legal model is national: Member States establish the registers, designate registrars, define registration policies, and manage the registration process.
While the interface for reading data from the registry cross-border is standardized and required, it seems the API for registration might be optional and allow for country-specific extensions.
What we expect to see in the coming years:
- Some countries will provide strong direct national portals and APIs.
- Some certificate providers may offer a one-stop-shop onboarding route.
- Some verifier platforms may support provider-assisted registration and certificate management (this is Paradym's intention).
- Cross-border Relying Parties may prefer a gateway-like abstraction if it becomes reliable and widely accepted.
Adoption will decide which path becomes normal. If national portals are easy, fast, and interoperable enough, many Relying Parties may register directly. If they are fragmented, slow, or difficult to combine with production certificate operations, gateway and provider-assisted models will become much more attractive.
How can Relying Parties prepare for EUDI Wallet registration?
Relying Parties do not need to wait until every national portal is live to prepare. The hardest parts of registration will not be clicking "submit" in a future register. The hard parts are defining the use case, reducing the data request, documenting the purpose, mapping the wallet response into the business process, and setting up the certificate and trust infrastructure needed to interact with wallets. All of which can already be started right now, including the technical integration into existing software systems.
Paradym can make sure you are ready to become a Relying Party. We support EUDI-aligned verification flows, presentation templates, trusted entities, X.509 certificate handling, and the operational work around wallet-based verification, including the technical integration with the relevant ETSI Technical Specifications (such as ETSI TS 119 475) that underpin the Relying Party trust infrastructure. When national registration routes become available, the Relying Parties that already know their intended use, requested attributes, legal basis, and technical architecture will be able to register through Paradym directly or in collaboration with Paradym.
In short: the registration process is becoming real. The exact route will differ by country and provider model, but the direction is clear. Register the service, declare the data request, obtain the relying party credentials, and make sure your verification infrastructure can keep up with the trust framework around it.
To discuss your Relying Party use case or prepare for EUDI Wallet registration, reach out to our team.
