The finding, stated plainly
Checked on 28 May 2026: the eIDAS Dashboard shows the WRPAC trusted-entity indicator as unpublished across all Member States. The WRPAC providers list endpoint is not publicly served — at time of writing it returns an access-denied response without presenting a providers file.
A note on what that access-denied response can and cannot tell us. An S3-style 403 response does not prove the list does not exist in any form; it proves only that the resource is not publicly accessible at that URL. The list may be served to authorised parties through a separate channel, maintained internally by the Commission for preparatory purposes, or simply not yet populated. What we can say precisely is that no publicly verifiable WRPAC provider list is available: there is no path by which a relying party, a developer, or a conformity assessor could independently confirm that a given certificate authority is authorised to issue WRPACs under an Article 7(1) mandate. That is the material fact for planning purposes.
For merchants and integrators who have been tracking the December 2026 deadline, this status raises an obvious question: is something broken, or is this exactly what the regulation requires right now? The answer is the latter. The absence of a published list today is not a failure of any Member State or of the Commission. It is the predictable consequence of a regulation whose operative obligations do not yet bind.
Why this is by design, not a delay
Regulation (EU) 2025/848 — the implementing regulation governing Wallet-Relying-Party Access Certificates — entered into force in late May 2025 as one of the key implementing acts under the amended eIDAS 2 framework. But entry into force is not the same as application. Article 11 of Reg (EU) 2025/848 specifies that the regulation applies from 24 December 2026. That single article explains everything that follows.
The core issuer obligation sits in Article 7(1). Under that provision, each Member State is required to authorise at least one certificate authority to issue WRPACs to relying parties established or operating in that state. Article 7(1) does not bind until the regulation applies — that is, until 24 December 2026. A Member State that has not yet designated a WRPAC-issuing certificate authority today is not late, not non-compliant, and not subject to any enforcement mechanism. It is simply operating within the timeline the regulation deliberately chose.
The same logic applies to the trusted-entity list. The list is the downstream product of Article 7(1) mandates: once Member States designate CAs, those CAs appear on the list. Before Article 7(1) binds, there are no mandated CAs to list. The unpublished status of the WRPAC indicator in the eIDAS Dashboard is therefore a structural consequence of the regulation's application timeline, not evidence of implementation lag.
This distinction matters enormously for how you communicate about WRPAC internally and with clients. You cannot describe any Member State as "behind" on WRPAC. You cannot describe the EU as "failing to publish" the list. What you can describe, accurately, is a regulation that has been carefully staged so that its operational infrastructure — the CA mandates, the trust list, the certificate issuance paths — comes online contemporaneously with the deadline rather than months or years in advance.
Whether that staging is the right policy choice is a separate debate. For planning, it is simply the legal reality.
What a WRPAC actually is
For readers encountering the term for the first time: a Wallet-Relying-Party Access Certificate is the access credential a relying party must hold in order to request attribute presentations from an EUDI Wallet under the production-mode flow. Article 2(12) of Reg (EU) 2025/848 defines it as the certificate used to authenticate a relying party to a wallet unit. Article 2(11) defines the provider of such a certificate as a person mandated by a Member State to issue WRPACs — the "person" in this context being a certificate authority operating under an Article 7(1) authorisation.
The practical implication is that WRPAC issuance is not a market the Commission controls directly. Each Member State authorises its own issuing CA or CAs. A relying party established in Germany will eventually obtain a WRPAC from a CA authorised by Germany; a relying party established in France from a CA authorised by France. Cross-border relying parties will need to understand whether their principal establishment governs or whether they need WRPAC coverage in each operational jurisdiction — a question the implementing regulation addresses but that many integrators have not yet fully worked through.
For a fuller treatment of what WRPACs do, how they fit into the wallet interaction protocol, and why relying parties cannot operate in production without one, see our companion post: What Is a WRPAC and Why Every Business Needs One by December 2026.
Two different clocks
One of the most common sources of confusion in merchant WRPAC planning is conflating two deadlines that share an approximate date but measure different obligations.
Clock one: the wallet-availability deadline. Regulation (EU) 2024/1183, which amended Regulation (EU) 910/2014, requires each Member State to make at least one EUDI Wallet available to natural and legal persons by approximately 24 December 2026. This is the clock that has been driving headlines about national wallet launches — and about national rollout plans that may land close to, or just after, that legal date. Article 5a of the amended regulation is the operative provision. The wallet-availability obligation falls on Member States, not on merchants.
Clock two: the WRPAC-issuance application date. The obligation for Member States to authorise at least one WRPAC-issuing CA also falls in the December 2026 window under Reg (EU) 2025/848 Art. 11. Production-mode relying parties will then need a WRPAC that can be validated against the mandated provider infrastructure. But this clock has a practical asymmetry: Member States have from now until December 2026 to designate CAs and publish their mandates. Those CAs then need to stand up issuance processes. Relying parties then need to apply, complete any required registration steps, and receive their certificates. None of that happens on a single day.
The conflation problem runs like this: a merchant hears "December 2026 deadline" in the context of wallet availability and assumes that is also when WRPACs become available to apply for. They are then surprised — either pleasantly or unpleasantly — when they discover that the WRPAC path may open earlier or later depending on when each Member State completes its Article 7(1) designation, and that some states may offer voluntary or pilot issuance paths before the formal mandate kicks in. Planning against a single December 2026 date for both obligations misses this sequencing entirely.
The practical consequence: relying parties should be monitoring the trust list and Member State CA announcements continuously through H2 2026, not waiting for a single go-live event that triggers everything at once. The first states to publish mandated CAs will give early-mover relying parties several weeks of runway before December 2026 to complete their WRPAC applications under a real production path.
What to do now — and what not to do
The absence of a publicly verifiable production WRPAC path today creates a planning vacuum that vendors have moved to fill. Some of what is being marketed as WRPAC infrastructure is legitimate; some is not. The distinction is testable: a WRPAC that cannot be publicly verified as chaining to a published, mandated CA under Article 7(1) is not a production WRPAC, regardless of what the vendor calls it or what the certificate's subject field claims.
What to do now
Build and test against sandbox and open-wallet flows. The EUDI Wallet Reference Implementation, Germany's official EUDI Wallet sandbox (run by SPRIND), and several Member State pilot environments are producing real presentation flows over OpenID4VP. These flows are technically representative of the production protocol even though the trust infrastructure — the CA mandates, the trust list, the WRPAC chain — is not yet in place. Time spent building a conformant OpenID4VP verifier now is time you will not need to spend in Q4 2026.
Track the eIDAS Dashboard WRPAC indicator. The dashboard at eidas.ec.europa.eu/efda/ is the canonical signal. When Member States begin designating WRPAC-issuing CAs and those CAs begin publishing their mandates, the WRPAC flag will flip from unpublished to published. That flip is your trigger to begin the application process in the affected Member State.
Track the providers list endpoint. The endpoint at trust.tech.ec.europa.eu/lists/eudiw/wrpac-providers.json will eventually serve a machine-readable file listing authorised CAs. Monitoring this endpoint — and building the validation logic to consume it once it goes live — is low-cost infrastructure work that pays off immediately when the list publishes.
Understand the application process for your jurisdiction. Article 7(1) designations are Member State decisions. Some states may publish detailed application procedures months before December 2026; others may not. The earlier you identify which CA will serve your jurisdiction and what the application process looks like, the less exposure you carry to a late-breaking queue problem in November and December 2026.
What not to do
Do not buy anything marketed as a "production WRPAC" that cannot be publicly verified. Until a CA's mandate is published on the trust list and visible through the eIDAS Dashboard, there is no independent basis on which to confirm that any certificate issued by that CA qualifies as an Article 2(12) WRPAC under an Article 7(1) authorisation. A certificate may be technically valid, conformant to the certificate profile, and issued by a reputable CA — and still not be a legally operative WRPAC if the CA has not received and published a Member State mandate. The risk is not that the certificate is fraudulent; the risk is that it will not be accepted by wallet implementations that validate the trust chain against the published list.
Do not treat sandbox certificates as production-ready. Sandbox WRPACs issued for developer and testing environments serve a legitimate purpose and should be used heavily right now. They do not carry the same trust chain as production certificates. Plan accordingly when communicating with business stakeholders about timeline to live deployment.
Do not assume your vendor's timeline is the regulation's timeline. Several conformity assessment bodies and certificate authorities have published roadmaps for WRPAC services that imply readiness well ahead of December 2026. Those roadmaps reflect the vendor's preparation; they are not commitments by Member States to complete their Article 7(1) designations on any particular date. The vendor can be ready before the regulation binds and still have no mandated certificates to issue.
For a closer look at how to evaluate what is on the market and what distinguishes genuine production paths from premature offerings, see our companion post: Real Production WRPACs vs Sandbox Certificates — How to Tell the Difference.
What to watch
Three signals will mark the transition from the current static state to an active WRPAC infrastructure market.
The dashboard WRPAC flag flipping to published. This is the first-order signal. When any Member State completes an Article 7(1) designation and that designation propagates to the eIDAS Dashboard, the WRPAC indicator for that state will change. A smaller, digitally advanced Member State with mature CA infrastructure could move quickly, but the first published mandate is still an open question. Any flip before September 2026 would give relying parties meaningful runway.
The providers list going live. When the endpoint at trust.tech.ec.europa.eu/lists/eudiw/wrpac-providers.json begins returning a populated JSON file rather than an access-denied response, that file will constitute the machine-readable source of truth for authorised CAs. The moment this list becomes publicly accessible, the "cannot be publicly verified" constraint lifts for any CA that appears on it. Build the list-consumption logic now; it is the same pattern as consuming the EU trusted lists for qualified trust service providers, and the code is portable.
Member State announcements of voluntary or pilot WRPAC issuance. Some Member States may choose to run voluntary or pilot WRPAC issuance ahead of the formal December 2026 mandate. Regulators have historically run pilot phases before binding dates in related identity schemes. A voluntary path can be useful preparation, but it should still be treated as non-production unless the mandate and trust anchor can be publicly verified. Watch for CA announcements from the national trust service supervisory bodies of the Member States whose wallet timelines are most advanced.
Any Commission clarification on cross-border WRPAC coverage. The current text of Reg (EU) 2025/848 leaves some ambiguity about whether a relying party established in one Member State needs a separate WRPAC for each Member State in which it operates or whether a single WRPAC covers EU-wide operations. Commission guidance on this point — whether through a formal notice, a Q&A document, or an update to the EUDI Wallet Architecture and Reference Framework — would materially affect how many separate CA relationships relying parties need to maintain. This is the most operationally consequential open question remaining in the WRPAC framework.
The EUDI Regulation overview page at the Commission's digital strategy portal is the first place formal clarifications tend to surface before they reach EUR-Lex. Add it to your monitoring list alongside the trust list endpoint and the eIDAS Dashboard.
The shape of the next seven months
To summarise where things stand and what the sequence looks like from here: Reg (EU) 2025/848 is in force and valid law, but it does not bind until 24 December 2026. The absence of a published WRPAC provider list reflects this staging, not any implementation failure. No Member State is "late" on WRPAC because no Member State is yet obligated. The eIDAS Dashboard's unpublished status and the inaccessible providers list endpoint are both predictable and correct readings of the current regulatory moment.
Between now and December 2026, the sequence runs: Member States designate CAs under Article 7(1), those CAs publish their mandates and stand up issuance processes, the trust list populates, and relying parties apply for and receive WRPACs. Some of that sequence may begin as early as Q3 2026 in the states moving fastest; some may not complete until December 2026 itself in states with more complex CA procurement timelines.
The appropriate response for a relying party is not to wait for December to act, and not to buy prematurely into offerings that cannot yet be publicly verified. It is to build the technical integration now against open-wallet flows and sandbox certificates, monitor the trust list endpoint and the Dashboard for the first published mandates, and be ready to move through the application process quickly once a verifiable path opens in your jurisdiction. The merchant that arrives at Q4 2026 with a working OpenID4VP verifier, a clear understanding of the WRPAC application process in its principal jurisdiction, and monitoring infrastructure watching the trust list will be in a substantially better position than the merchant that conflated the wallet-availability deadline with a WRPAC-availability deadline and is discovering the queue dynamics for the first time in November.
The list is not published yet. That is the right answer for right now.
Related Articles
How to Tell a Real Production WRPAC From a Sandbox Certificate
Because the official WRPAC provider list is not yet published, anything sold today as a production WRPAC cannot be publicly verified as chaining to a mandated provider. Here is the verification chain that defines a real one, the red flags, and what sandbox certificates are legitimately for.
7 min read
What is WRPAC and Why Every Online Business Will Need One by December 2026
The December 2026 deadline is approaching. Understand what WRPAC certificates are and why your business needs compliance now.
8 min read
Share this article
Help others learn about eIDAS verification