How to Tell a Real Production WRPAC From a Sandbox Certificate

The WRPAC — the Wallet-Relying Party Access Certificate — sits at the centre of every technical integration under Regulation (EU) 2025/848. Without it, your application cannot authenticate itself to an EUDI Wallet. With the wrong kind, you have a certificate that looks the part but cannot be publicly verified as chaining to any mandated, published provider. That distinction matters — and right now, in May 2026, it matters more than most vendors will tell you.

Why This Matters Now

There is no public list of authorised WRPAC providers yet. As of late May 2026, the eIDAS Dashboard reports the WRPAC providers list as not published. That is not a delay, an oversight, or anyone's failure — the regulation applies from 24 December 2026, and the ecosystem is still assembling the infrastructure that will support it. But it does create a specific, concrete risk for relying parties evaluating offers in the market.

Because the list is not publicly served, there is no way for a buyer — or any third party — to confirm that a certificate offered as a "production WRPAC" actually chains to a provider mandated by a Member State. The chain either terminates at a listed, mandated certificate authority or it does not. At present, that check cannot be completed against a published source. Anyone marketing a production WRPAC today is asking you to accept their word for a fact that cannot yet be independently verified.

We covered the current state of this gap in detail in No Published WRPAC Provider List Yet — What That Means Before December 2026. This post is about how you will verify a WRPAC when that list does exist — and why the same logic exposes every claim being made today.

The Verification Chain That Defines a Real WRPAC

A production WRPAC is not simply any X.509 certificate issued by a party that claims to be authorised. Three conditions must hold simultaneously, and each is independently checkable.

First: the certificate must chain to a published EU or national trusted list. Regulation (EU) 2025/848 establishes the technical format of the WRPAC through Article 7 and Annex IV, while Article 7(1) requires each Member State to authorise at least one certificate authority to issue WRPACs. A certificate that terminates at a root CA not present in the relevant published trusted-list infrastructure cannot be treated as a production WRPAC regardless of what the issuer claims.

Second: the eIDAS Dashboard must report the WRPAC providers list as published. The publication flag on the dashboard is the authoritative signal that the list of mandated providers is live and verifiable. Until that flag reads as published, the chain cannot be verified end-to-end. There is no workaround for this: a certificate may exist and may even be technically well-formed, but the connection between that certificate's issuer and a Member State's mandate cannot be confirmed.

Third: the issuer must be a provider mandated by a Member State. Article 2(11) of Regulation (EU) 2025/848 defines a provider of WRPACs as a natural or legal person mandated by a Member State to issue WRPACs to relying parties. Article 2(12) defines the WRPAC itself. The Article 7(1) Member State authorisation is the legal basis for why the certificate can be trusted in the first place. A provider that has not been mandated by any Member State is not within the scope of that definition, regardless of any self-certification or commercial claim.

All three conditions form a single chain. Break any link and the certificate cannot be treated as a production WRPAC.

How to Check It Yourself

When the providers list is published, the verification procedure is straightforward. Start with the eIDAS Dashboard and check the publication status of the WRPAC list. The dashboard aggregates trust list data from Member States; when the flag moves from "not published" to published, you have confirmation that the infrastructure is live.

Next, query the WRPAC providers endpoint directly. This endpoint will serve the list of authorised, mandated providers once publication is active. You are looking for your certificate issuer's CA to appear in that list.

Finally, verify the certificate chain itself. Using standard PKI tooling (OpenSSL or equivalent), trace the chain from your WRPAC up through any intermediates to the root CA. That root must correspond to a CA in the published providers list. If the chain terminates anywhere else — at a private root, at a CA absent from the list, or at anything other than a mandated provider's root — the certificate does not qualify as a production WRPAC under the regulation.

Document this check and retain the output. When supervisory bodies begin enforcing the framework after December 2026, demonstrating that you performed due diligence on your WRPAC source will matter.

Red Flags

A vendor claiming a production WRPAC before the list is published. This is the central red flag. The claim may not be dishonest — the provider may genuinely believe their CA will eventually be mandated — but it is unverifiable today. Buying on that basis means accepting an unverifiable assurance. The regulatory risk sits with you, the relying party.

A certificate that does not chain to any published trusted list. This is a PKI failure before it is a regulatory one. A certificate from a CA with no presence in the relevant trusted-list infrastructure cannot establish the chain required for a production WRPAC. Check the chain before accepting any certificate for integration use.

"Mandated" asserted without a Member State source you can check. Ask any vendor for the Member State that mandated them and the legal basis — the national act, ministerial decision, or supervisory notice — that establishes the mandate. If they cannot point to a public, traceable source, the claim is not verifiable. "We are in discussions with Member States" and "we expect to be mandated" are not the same as "we are mandated by [Member State] under [legal act]."

Pricing and packaging that implies production-readiness without substantiating it. Sandbox certificates are legitimate and useful products. They become a problem only when they are sold — or positioned — as production WRPACs. If a vendor is packaging a certificate with production-level service-level agreements and production-level pricing but cannot substantiate the three conditions above, treat it as a sandbox certificate until verified.

What Sandbox Certificates Are Legitimately For

Sandbox certificates serve an important and legitimate purpose. The pre-publication window — the period between now and the December 2026 application date — is exactly when relying parties should be integrating, testing, and qualifying their implementations. Doing that work without any certificate infrastructure would be impractical.

Germany's official EUDI Wallet sandbox, run by SPRIND since December 2025, provides a reference environment for precisely this kind of integration testing. The France Identité playground offers a similar function for French wallet implementations. These are not workarounds; they are the intended testing path during the period before production infrastructure is live.

A sandbox certificate lets you build your WRPAC request flows, validate your OpenID4VP implementation against wallet reference implementations, test your attribute handling logic, and prepare your registration filing — all before a single production WRPAC has been issued to anyone. That is valuable work, and the certificate that supports it is a legitimate product.

The problem is specific: a sandbox certificate mislabelled as a production WRPAC. A certificate issued within a sandbox environment, by a CA that is not mandated under Article 2(11), cannot authenticate your application to a production EUDI Wallet. It is not designed to. Using a sandbox certificate in production is a technical failure; buying one while believing it to be production-grade is a procurement failure. Both are avoidable.

The Rule

Do not buy or market a current certificate as a production WRPAC unless it chains to a published, mandated provider — and that chain can be independently verified against the published providers list.

That rule is not a technicality. It is the substance of what the regulation requires. Article 7(1) of Regulation (EU) 2025/848 places the authorisation obligation on Member States, while Article 7 and Annex IV define the WRPAC issuance requirements. The relying party still bears the operational risk of using a non-conformant certificate. If your WRPAC does not satisfy the three-condition chain described above, your wallet integration does not have a compliant authentication mechanism.

Until the providers list is published, the correct position is: there is no public/verifiable production WRPAC path. Plan accordingly — use sandbox environments for integration work, but do not treat sandbox certificates as production assets, and do not accept vendor claims of production readiness that cannot be verified against a public source.

What to Watch

Two events will change the picture.

The eIDAS Dashboard publication flag. When the dashboard moves from reporting the WRPAC list as not published to reporting it as published, the first half of the verification chain becomes possible. Set a check on the eIDAS Dashboard and on the providers endpoint. These are the authoritative signals, not vendor announcements.

A Member State naming a mandated WRPAC-issuing CA. The mandate under Article 2(11) flows from a Member State decision. When any Member State publicly designates a certificate authority or other provider as mandated to issue WRPACs, that is the moment the second half of the chain becomes checkable. Watch national supervisory body announcements and national trust list updates — those are the upstream sources that feed the eIDAS Dashboard and the providers endpoint.

Neither event has occurred as of this writing. When both have, the verification procedure described in this post becomes executable. Until then, it serves as the framework for evaluating any certificate that is offered to you — and for understanding exactly what is missing from any claim of production readiness you encounter in the market.

Related Articles

No EU Country Has a Published WRPAC Provider List Yet — What It Means for Your December 2026 Deadline

As of late May 2026 the official EU trusted-entity lists are not published: the eIDAS Dashboard reports WRPAC as unpublished and the providers list is not publicly served. Here is why that is by design, and what it changes for your December 2026 planning.

8 min read

eIDAS 2.0 Relying Party Registration: The Complete Guide

Everything you need to know about registering as a Relying Party under Article 5b of eIDAS Regulation 2024/1183.

12 min read