In our previous article on wallet-relying party registration, we explained how Member States create national registers of entities authorized to interact with EUDI (European Digital Identity) Wallets, and why this registration framework forms the foundation of user protection in the ecosystem.

Registration answers a fundamental governance question: ‘Is this organization allowed to interact with wallets?’ But registration alone is not enough. A name on a register cannot authenticate a connection.

For wallets to verify (in real time, automatically) that the party they are communicating with is truly the registered organization and not an impersonator, another mechanism is required: certificates. Certificates provide the cryptographic layer that makes the governance framework defined by eIDAS 2.0 and the EUDI Wallet Architecture and Reference Framework (ARF) work.

This article explains the role certificates play in the wallet-relying party trust model, how they are obtained, and what it means for different actors in the ecosystem to hold and issue them.

Key takeaways

• Wallet-relying parties (WRPs) must register with an authority of their Member State before interacting with EUDI Wallets
• Cryptographic certificates authenticate relying parties during wallet interactions
• The EUDI framework currently defines two certificate types: WRP registration certificates and WRP access certificates, with concrete realization and enforcement details potentially varying by Member State implementation
• These certificates are issued by authorized certificate providers operating under ETSI and eIDAS specifications
• Procivis One integrates registration, certificate issuance, and wallet interaction into a unified, EUDI-compliant infrastructure, enabling governments and regulated industries to deploy wallet services without building PKI (Public Key Infrastructure) or onboarding systems from scratch

What problem do certificates solve?

A certificate is a signed data structure that binds a public key to an identity, or more precisely, to a set of verified claims about an entity. The signature is provided by a trusted third party - a certificate authority (CA) - whose role is to verify those claims before signing.

In the EUDI wallet ecosystem, certificates solve a specific and practical problem: when a wallet receives a request for credentials from what claims to be a registered bank, telecom provider, or government portal, how does it know the request originates from that organization?

Checking the register helps, but the register only tells you that an organization with that name exists. It cannot prove that the party sending the request is that organization.

This is where certificates come in.

When the registered organization holds a certificate issued by a trusted authority, and that certificate contains its public key, the wallet can verify a cryptographic signature from the organization against that certificate. If the signature validates and the certificate chains back to a trusted root, the wallet gains strong assurance that the party initiating the interaction is indeed the registered organization.

In short: if WRP registration answers: 'Is entity X allowed to interact with wallets?', WRP certificates answer: 'Is the entity sending the request indeed entity X?'

This combination of governance controls and cryptographic verification is what allows the EUDI Wallet ecosystem to operate securely at scale.

The certificates produced in the EUDI ecosystem

eIDAS 2, CIR 2025/848 and further, ETSI TS 119 475 and the ARF define two distinct certificate types for wallet-relying parties.

A) The WRP access certificate

The WRP Access Certificate is used during wallet interactions to authenticate the relying party.

When a relying party initiates a request - for example when a verifier sends a presentation request via OID4VP (OpenID for Verifiable Presentations) - it presents its access certificate. This certificate contains the relying party’s public key and is signed by an authorized certificate provider trusted within the eIDAS 2 ecosystem via a WRP AC trust list.

The wallet uses the certificate to verify the cryptographic binding: the entity initiating the request controls the private key corresponding to the public key in the certificate.

Access certificates therefore provide the operational authentication mechanism that allows wallets to securely establish connections with relying parties.

B) The WRP registration certificate

The WRP Registration Certificate is used during wallet interactions to convey the relying party's declared identity, entitlements, and intended use - specifically the attestations it has registered to issue, the attributes it will request, and the purpose for which they will be processed

Because each certificate covers one intended use, an organization with multiple use cases holds multiple registration certificates, one per use case.
The separation between access certificates and registration certificates is intentional:

• Access certificates prove the identity of the entity initiating the interaction
• Registration certificates capture what the entity has declared to do

Separating these roles allows the ecosystem to maintain different validity periods, update cycles, and governance controls for registration data and operational authentication.

How organizations obtain certificates: the CSR flow

Certificates are not simply handed out after registration. The organization receiving the certificate must demonstrate that it controls the private key corresponding to the public key the certificate will bind. This is done typically through a Certificate Signing Request (CSR).

The flow is straightforward and follows established PKI practice, common to X.509 certificates:

1. Key generation. The organization (or its system) generates a cryptographic key pair - a private key that stays under its control, and a public key that will be published in the certificate
2. CSR creation. The organization creates a CSR: a structured message containing the public key and some identifying information, all signed with the private key. The signature proves to the CA that the applicant genuinely holds the private key that goes with the public key they are submitting
3. Submission. The CSR is submitted to the designated CA - in the WRP context, typically as part of the onboarding workflow, either alongside the registration application or as a step triggered once registration is approved
4. CA verification and issuance. The CA checks that the CSR is valid, that it matches the registered organization, and issues the signed certificate. The certificate now contains the organization's public key, bound to its identity, under the CA's signature
5. Deployment. The organization installs the certificate in its systems and presents it during wallet interactions

What does it mean to be a certificate authority?

In general terms, a certificate authority vouches for the binding between a public key and an identity by signing a certificate. Within the EUDI wallet ecosystem, however, the role is more specific.

A WRP certificate provider must:

• be authorized or recognized by a Member State
• operate under the policy requirements defined in relevant ETSI technical specifications such as ETSI TS 119-411-8 be included in the national trust framework so wallets know to trust the certificates it issues

Trust is anchored through the certificate chain.

When a wallet validates a WRP access certificate, it verifies that:

• the organization’s certificate was signed by an authorized certificate provider
• that provider’s certificate chains to a trusted root
• the root is listed in the Member State trust framework

This cryptographic chain replaces the need to query the national register during every interaction.

For Member States and infrastructure operators, operating or designating such a certificate authority is a significant undertaking. It involves:

• secure key management
• hardware security modules
• audit and compliance processes
• revocation mechanisms such as CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol)
• long-term operational security

These requirements are why most wallet deployments rely on specialized infrastructure providers rather than building this capability from scratch. Procivis One strengthens the ecosystem by providing an integrated EUDI-compliant platform that manages registration, certificate issuance, and wallet trust infrastructure. Governments and regulated industries can deploy wallet services securely and efficiently without building PKI, onboarding, or operational systems from the ground up.

End-to-end onboarding of a wallet-relying party

Putting everything together, onboarding a new wallet-relying party typically follows this flow:

1. The organization applies to the national registrar, providing its legal identity, intended use, and requested attributes
2. Once registration is approved, the organization generates a key pair and submits a certificate signing request to the authorized certificate provider
3. The certificate provider verifies the request and issues the required certificates
4. The organization installs the certificates within its relying party infrastructure
5. When interacting with wallets, the access certificate is presented and validated through the trusted certificate chain

This architecture allows wallets to authenticate relying parties automatically and securely, enabling scalable trust across the European digital identity ecosystem.

What comes next

Certificates are one of the key technical pillars of the wallet-relying party trust model, alongside the register itself and the revocation mechanisms that keep both up to date when an organization’s status changes.

In upcoming articles, we will explore how trust lists are managed across Member States and how revocation mechanisms ensure that wallet ecosystems remain secure as organizations join or leave the trust framework.

If you want to see how Procivis One handles WRP-registration and certificate issuance integration in practice, explore the documentation or request trial access.