ARF 2.9.0 Finalizes Relying Party Registration (Topic X): What Changed for WRPAC

If you have been tracking the WRPAC obligation through the lens of legal text alone, you have been reading only half of the specification. The Implementing Regulation tells you that you must register. It does not tell you how a wallet will recognise your registration at the moment of a transaction. That second half lives in the Architecture and Reference Framework (ARF), and on 21 May 2026 it moved a significant step closer to being settled: ARF version 2.9.0 marked Topic X — Relying Party Registration as Final.

For a relying party planning an EUDI Wallet integration, this is the most consequential ARF release in months. Here is what actually changed and why it matters for your WRPAC strategy.

What the ARF is, and why "Final" is a meaningful word

The ARF is the European Commission's living technical companion to the eIDAS 2.0 Regulation. Where the legal acts state obligations, the ARF expresses them as High-Level Requirements (HLRs) — numbered, testable statements that implementers (wallet providers, issuers, and verifiers) build against. Each functional area is organised as a "Topic," and Topics progress through draft and discussion states before being declared Final.

A Topic moving to Final does not freeze it forever — the ARF still revises — but it signals that the working group considers the area stable enough to implement against without expecting the ground to shift underneath you. Topic X covering Relying Party Registration reaching that state means the registration data model and authentication mechanics are now a deliberate target, not a moving one.

That is exactly the assurance a relying party needs before committing engineering time. It is the difference we drew in Production WRPAC vs. Sandbox Certificate: building against a stable specification versus building against a draft you will have to rebuild.

Topic X in plain terms: three things you must declare

Relying Party Registration, as finalized in 2.9.0, formalises the chain that runs from who you are to what a wallet will let you ask for. Three categories of high-level requirement anchor it:

1. Relying party authentication. The wallet — and the user behind it — must be able to cryptographically verify that the party requesting attributes is the party that registered. This is the role a Wallet-Relying Party Access Certificate (WRPAC) plays in practice: it binds your registered identity to the keys that sign your presentation requests.

2. Contact and identification details. The registration record must carry verifiable information about the legal entity behind the relying party — the data a national register holds and that a wallet can surface to the user so they know who is asking.

3. Intended use (the requested attributes). A relying party declares, at registration time, which attributes it intends to request and for what purpose. A wallet can then check a live request against that declared scope. Ask for more than you registered for, and a conformant wallet can refuse.

That third point is the one most teams underestimate. Registration is not a one-time bureaucratic gate — it defines a scope envelope that constrains every transaction you will ever run. For an age-verification use case this is liberating: a relying party that registers only for a proof-of-age attribute is visibly, provably unable to request a date of birth or a full identity, which is precisely the data-minimisation story regulators want to hear. We explored that same principle from the data-protection angle in GDPR Compliance: How eIDAS Minimises Data Collection.

How Topic X connects to WRPAC and WRPRC

The ARF distinguishes two certificate types that sit on top of registration, and 2.9.0's Topic X is the connective tissue between them:

• WRPAC — Wallet-Relying Party Access Certificate. Authenticates the relying party to the wallet when it makes an access (presentation) request. This is the certificate most merchants and verifiers care about.
• WRPRC — Wallet-Relying Party Registration Certificate. Attests to the registration itself — the entitlements and intended-use scope recorded in the national register.

Topic X is what makes these two coherent: it defines the data captured at registration (the WRPRC's content) and the authentication requirements the access certificate (WRPAC) must satisfy. If you have read our complete guide to relying party registration, Topic X is the HLR-level expression of the process described there.

The legal half: Implementing Regulation 2025/848

The ARF does not stand alone. The legal basis for relying party registration is Commission Implementing Regulation (EU) 2025/848, adopted under Article 5b(11) of the eIDAS Regulation. Two dates matter:

• It entered into force in mid-2025 (shortly after adoption on 6 May 2025).
• Its substantive obligations apply from 24 December 2026.

That second date is the one to circle. As we documented in the EU-27 WRPAC status snapshot, no Member State currently operates a publicly verifiable production WRPAC path, and the EU-wide trusted-list endpoint on the eIDAS Dashboard is not yet published. That is not a failure — the application date simply has not arrived. ARF 2.9.0 finalizing Topic X before the legal obligation applies is the system working in the right order: stabilise the specification, then open the registers.

A note on what we cannot yet confirm. The exact set of information a relying party must submit under Annex I of 2025/848 — and whether the March 2026 discussion around the registration act (raised by industry bodies such as Bitkom, who argue technical detail belongs in standards rather than statute) will reshape that set — remains in motion. Treat the Annex I field list as stable in structure but verify the specifics against the official text before you build a registration form.

What this means for your roadmap

The practical takeaway is one of sequencing. Topic X being Final lets you do real work now, ahead of the 24 December 2026 application date:

For a relying party whose use case is age verification specifically, the sequencing is even cleaner, because the EU Age Verification reference implementation already exercises the verifier side of these requirements in a test environment — see our forthcoming companion piece on validating proof-of-age against the EU Trusted List, and on the DC API / OpenID4VP request flow that a registered relying party uses to make those requests.

The bottom line

ARF 2.9.0 did not change the WRPAC deadline — that remains 24 December 2026 under Implementing Regulation 2025/848. What it changed is your confidence: the registration data model and the authentication mechanics underneath WRPAC are now a Final Topic. You can architect against them without expecting them to move.

The relying parties that will be ready on day one are not the ones waiting for the registers to open. They are the ones who, today, have already decided their intended-use scope, built their request-signing flow against the stable Topic X model, and tested it end to end. ARF 2.9.0 is the green light to be one of them.

This post reflects the ARF as of version 2.9.0 (21 May 2026) and the regulatory position as of June 2026. Both are on an active 2026 cadence — verify dates and Annex specifics against the official ARF repository and EUR-Lex before relying on them.