Eudi wallet relying party certificates need PKI for trust

At a glance

What this is: This technical guide explains how EUDI wallet relying party certificates work and why registration by itself does not authenticate a wallet request.

Why it matters: It matters because IAM and PKI teams supporting digital identity wallets need both governance registration and cryptographic proof to control who can interact with wallets.

Context

Registration for wallet relying parties tells a Member State that an organisation is authorised to interact with EUDI Wallets, but it does not prove that a live request really came from that organisation. That gap is the core governance problem the article addresses: trust at the register level is not the same as trust at the connection level.

Certificates provide the cryptographic assurance layer that closes that gap by binding a public key to a verified identity and enabling wallets to validate requesters in real time. In practice, this makes the EUDI wallet trust model a combined registration, certificate issuance, and lifecycle control problem.

For identity teams, the relevant question is not whether registration exists, but whether the surrounding PKI, onboarding, revocation, and trust list processes are strong enough to make that registration enforceable at runtime.

Key questions

Q: How should organisations separate registration from runtime authentication in wallet ecosystems?

A: Use registration to confirm that an organisation is allowed to participate, then use certificates to prove that a live request really comes from that organisation. The two controls solve different problems, so they should have separate owners, separate evidence, and separate lifecycle handling. That separation is what makes wallet trust enforceable at runtime.

Q: Why do wallet relying party certificates matter when a national register already exists?

A: Because a register can prove eligibility, but it cannot authenticate the party sending a request. Certificates add the cryptographic proof that the requester controls the private key linked to a trusted identity. Without that proof, the wallet can confirm name and status, but not the authenticity of the session origin.

Q: What breaks if certificate issuance is treated as a one-time onboarding task?

A: The trust chain becomes stale as soon as organisations change status, keys rotate, or revocation is needed. Wallet trust depends on current validation, not historic approval, so onboarding without ongoing lifecycle control leaves a live trust path that no longer matches reality.

Q: How do wallets decide whether to trust a relying party certificate?

A: They validate the certificate chain back to an authorised certificate provider and then to a trusted root in the Member State trust framework. That means trust depends on both cryptographic validity and the operational trust list. If either layer is missing or stale, the wallet should not treat the party as trusted.

Technical breakdown

Why registration cannot authenticate a wallet connection

A national register answers an authorisation question, not an authentication question. It can confirm that an organisation is allowed to participate in the EUDI wallet ecosystem, but it cannot prove that the system sending a request is the same organisation at the moment of interaction. Certificates solve that by giving the wallet a cryptographic way to verify that the requester controls the private key tied to a trusted public key. In identity terms, the register establishes eligibility and the certificate establishes operational proof. Without both, the wallet has policy intent without runtime assurance.

Practical implication: Treat registration and connection authentication as separate controls and design both into the onboarding flow.

How WRP access certificates and registration certificates divide trust

The article describes two certificate types with different jobs. WRP access certificates authenticate the relying party during a wallet interaction, while WRP registration certificates carry declared identity, entitlements, requested attributes, and intended use. That split matters because one certificate type answers who is calling, while the other answers what that party is allowed to do and for which use case. Separating them also allows different validity periods and update cycles, which is a common PKI pattern when governance data changes at a different rate from session authentication.

Practical implication: Model access certificates and registration certificates as distinct lifecycle objects, not interchangeable assets.

Why CSR-based issuance is the control point for certificate trust

The certificate signing request flow is the proof step that binds the private key to the certificate request. The organisation generates a key pair, signs the CSR with the private key, and submits it so the certificate authority can verify that the requester actually controls the key that will be trusted. This is the foundational PKI assurance step, and it is what prevents arbitrary certificate issuance after registration alone. The trust chain then extends through the authorised certificate provider to the root listed in the Member State trust framework. In practice, the security of the wallet ecosystem depends on how carefully that issuance and revocation chain is run.

Practical implication: Put certificate issuance, root trust, and revocation under explicit operational governance, not ad hoc onboarding.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate trust is the runtime control that makes wallet registration enforceable. Registration creates permission to participate, but certificates create the ability to prove participation at the moment of interaction. That distinction is central to any digital identity ecosystem that must make policy decisions automatically. For practitioners, the lesson is that governance without cryptographic proof remains advisory, not enforceable.

Separate identity declaration from operational authentication. The article’s split between WRP registration certificates and WRP access certificates reflects a clean governance model: one object describes declared use, the other proves the active caller. That separation reduces ambiguity in lifecycle management because entitlements, intent, and request authentication can change on different schedules. The practitioner implication is to preserve that separation rather than collapsing it into one certificate class.

PKI becomes a trust orchestration problem, not just a certificate problem. The article shows that wallet trust depends on authorised certificate providers, trust lists, root chains, revocation, and operational security around issuance. This is not a narrow cryptography exercise. It is an identity operations discipline that spans policy, onboarding, revocation, and assurance. The practical conclusion is that EUDI deployments need governance over the full trust chain, not only certificate generation.

Identity wallets push IGA thinking deeper into machine-verifiable trust. The moment a wallet must verify a relying party automatically, registration data becomes part of a runtime control path rather than static compliance evidence. That changes how teams should think about identity assurance in regulated ecosystems. The takeaway for architects is that the trust model now sits at the boundary between IAM, PKI, and federation.

Machine-verifiable trust depends on lifecycle discipline as much as initial issuance. The article notes that trust lists and revocation mechanisms keep the ecosystem current when organisations join or leave the framework. That means certificate validity alone is never enough. Practitioners should treat offboarding and revocation as first-class trust controls, because stale trust is still trust from the wallet’s perspective.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.

What this signals

Certificate trust becomes a governance boundary: once wallets validate relying parties cryptographically, the real control point moves from static registration to certificate lifecycle management. That means onboarding, key generation, issuance, revocation, and trust list maintenance all sit inside the identity control plane rather than around it.

Runtime assurance depends on the trust chain, not the application claim: wallets should trust a relying party only when the certificate chain resolves to an authorised issuer and a current trust framework. Identity programmes that stop at registration will miss the point where authentication actually happens.

For practitioners

• Define separate lifecycle owners for registration and access certificates Assign one governance path for declared identity and entitlements, and a different one for the certificate used to authenticate live wallet requests.
• Tie issuance to CSR proof of key possession Require a signed certificate signing request before issuance so the requester proves control of the private key that will anchor trust.
• Operationalise revocation and trust list monitoring Monitor certificate revocation lists, OCSP responses, and trust framework updates so removed parties stop being trusted when status changes.
• Separate onboarding evidence from runtime authentication evidence Keep registration approval records distinct from the certificate chain and validation logs used during wallet interactions.

Key takeaways

• EUDI wallet trust depends on more than registration because a register cannot prove the caller behind a live request.
• WRP access certificates and registration certificates serve different roles, so they should be governed as separate lifecycle objects.
• Certificate issuance, revocation, and trust list maintenance are the controls that make wallet trust enforceable in practice.

Key terms

• Wallet-Relying Party: A Wallet-Relying Party is a service that requests and verifies credentials or claims from a digital wallet before granting access or completing a transaction. It depends on the wallet’s presentation, proofs, and issuer trust. Practitioners check request scope, verifier policy, replay resistance, and whether the relying party asks for only the minimum required data.
• Certificate Signing Request: A Certificate Signing Request is a structured request sent to a certificate authority to obtain a certificate. It contains the public key and identity details the CA will validate before issuing trust. The private key remains on the requester’s system, which is why CSR quality matters before issuance, not after.
• Trust Chain: The trust chain is the set of delegated relationships that lets one system, token, or integration act on behalf of another. In NHI security, it is often the real attack surface because compromise travels through legitimate permissions instead of obvious malware.
• Revocation Mechanism: A revocation mechanism is the process and supporting infrastructure used to mark a certificate as no longer trusted before its expiry. In EUDI wallet deployments, revocation matters because trust can change after issuance, and a valid-looking certificate is still unsafe if its status is not current.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.