EUDI Wallet Relying Party
Before a single attribute can be requested from an EUDI Wallet, the business behind the integration has to be a registered relying party in the Member State where it is established. This is what that registration involves, what it permanently constrains and what happens when it is refused or withdrawn.
14 min read
73 views
- Registration is the gate, not the paperwork Access certificates are issued exclusively to registered relying parties, so an unregistered business has no way to authenticate itself to a wallet at all.
- The declaration caps the request The attributes registered per intended use become the ceiling on what the verifier may ask for, and Annex I wants that list in a machine-readable form.
- The register entry is a public disclosure Member States publish the Annex I information online in human-readable and machine-processable form, so the intended attribute list is readable by anyone.
- Revocation is a production incident Suspension or cancellation can follow a proportionality assessment with or without prior notice, revokes both certificates within a 24-hour notification window and leaves a right of redress but no technical workaround.
- Two dates, and they are not the same The registration regime applies from 24 December 2026 while the Member State wallet obligation is a 24-month period running from the entry into force of implementing acts. Different obligations, different facts.
A wallet integration gets scoped as an engineering problem. Someone reads the presentation flow, sizes the credential verification work and returns a number. The number then moves, because before that code can talk to a real wallet, the business behind it has to appear in a public national register and hold a certificate issued only to entries in that register.
Registration is a separate track with its own refusal path, and the regulation leaves its duration to national law. What follows is what the two governing instruments require.
The duty, and where it lands
Regulation (EU) 2024/1183 inserts a new Article 5b into the eIDAS framework, and its opening paragraph is the whole gate in one sentence. It reads "Where a relying party intends to rely upon European Digital Identity Wallets for the provision of public or private services by means of digital interaction, the relying party shall register in the Member State where it is established." (Regulation (EU) 2024/1183, Article 5b(1))
The trigger is intent, so the obligation attaches while the system is still a design document. Registration follows where the entity is established, not where its users live.
Where possible the registrar runs four automated checks, and the fourth looks past its own borders to verify "the absence of an existing registration in another national register." (CIR (EU) 2025/848, Article 6(3), point (d)) An entry in one Member State is a fact the next registrar looks for.
Article 5b(2) lists three heads a Member State collects, and the third reaches into the codebase. It covers "the intended use of European Digital Identity Wallets, including an indication of the data to be requested by the relying party from users." (Regulation (EU) 2024/1183, Article 5b(2), point (c))
The declaration becomes a hard cap on what you may ask for
The next paragraph turns that declaration into a standing constraint: "Relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, point (c)." (Regulation (EU) 2024/1183, Article 5b(3)) The request your verifier emits has to be derived from the registered attribute set rather than from whatever the wallet can present. A product manager who adds one field to a form has amended a regulatory filing.
The process itself has a standard set on it, and it binds Member States rather than applicants: "The registration process shall be cost-effective and proportionate-to-risk." (Regulation (EU) 2024/1183, Article 5b(2))
How long it takes is left to national law. Registrars act without undue delay and "provide a response to the application for registration to the applicant within the timeframe defined in the applicable registration policy" (CIR (EU) 2025/848, Article 6(2)), so the waiting period comes from the applicable national registration policy. That number comes from the registrar, not from the regulation.
What the register is, and who can read it
Mechanics sit in a second instrument. Commission Implementing Regulation (EU) 2025/848 lays down the rules for registering wallet-relying parties (CIR (EU) 2025/848, Article 1), the businesses that intend to rely on wallet units for public or private services (CIR (EU) 2025/848, Article 2, point (1)).
What each Member State holds is then published. "Member States shall make the information set out in Annex I on registered wallet-relying parties publicly available online, both in human-readable form and in a form suitable for automated processing." (CIR (EU) 2025/848, Article 3(4)) The duty falls on the Member State and covers the whole Annex I set.
Your intended attribute list is a public document
Each Member State exposes its register through a single common application programming interface and a national website (CIR (EU) 2025/848, Article 3(5)), so the contents are built to be pulled programmatically. Anyone can read which attributes your business intends to request, grouped by declared purpose. Competitors and prospective customers get the same view your regulator does, turning data minimization into a published position.
Two certificates, and only one of them is guaranteed
Registration produces two artifacts, both defined in the implementing regulation's definitions article. The access certificate authenticates and validates the relying party (CIR (EU) 2025/848, Article 2, point (12)), and the registration certificate is a data object describing the intended use and listing the attributes registered (CIR (EU) 2025/848, Article 2, point (15)).
Access certificates are what make registration enforceable rather than advisory: "Member States shall ensure that providers of wallet-relying party access certificates issue wallet-relying party access certificates exclusively to registered wallet-relying parties." (CIR (EU) 2025/848, Article 7(2))
Plan for the registration certificate to be absent
The asymmetry lives in a single verb. For access certificates the implementing regulation says "Member States shall authorise at least one certificate authority to issue wallet-relying party access certificates." (CIR (EU) 2025/848, Article 7(1)) For registration certificates it says "Member States may authorise at least one certificate authority to issue wallet-relying party registration certificates." (CIR (EU) 2025/848, Article 8(1)) A relying party operating in several Member States cannot assume one is obtainable in each, so behavior that depends on it has to degrade cleanly.
The general access policy follows the Member State that opted in
Everything that certificate does for a user hangs on that permission being exercised. Article 8(2) opens "Where a Member State authorised the issuance of a wallet-relying party registration certificate, that Member State shall;" (CIR (EU) 2025/848, Article 8(2)) and only then lists the duties. One is to ensure the certificate carries "a general access policy, being syntactically and semantically harmonised across the Union" (CIR (EU) 2025/848, Article 8(2), point (c)), informing users that the relying party may request only the data it specified for the registered intended use. That standard is weaker than identical: syntax and semantics align across Member States without one policy copying another.
The warning a user sees is scoped the same way. Point (d) asks that Member State to "ensure that providers of wallet solutions established in that Member State comply with the general access policy by informing users when a wallet-relying party requests data that is not specified in the registration certificates;" (CIR (EU) 2025/848, Article 8(2), point (d)) So where a Member State authorised registration certificates, over-asking surfaces in the wallet, to the person being asked, at the moment of the request, through wallet providers established there. Where it never authorised them, Article 8(2) does not bind it and neither the policy nor the warning is in play.
Verification, refusal and keeping the entry alive
What you submit is checked before it takes effect. Registrars verify it against supporting documentation or against authentic sources and other official electronic records they can reach in their own Member State (CIR (EU) 2025/848, Article 6(4)). Self-assertion is not the model.
If the check fails, the outcome is stated without a middle state: "Where the registrar cannot verify the information in accordance with paragraphs 3 to 5, the registrar shall reject the registration." (CIR (EU) 2025/848, Article 6(6)) That leaves two outcomes and no third, so a pending application produces nothing a certificate provider could act on. Whether a national process offers a sandbox is a question for the registrar, since these instruments settle only the verified-or-rejected outcome.
Your entry is live state, not a filing
The relying party supplies the content. "Wallet-relying parties shall at least provide the information set out in Annex I to national registers." (CIR (EU) 2025/848, Article 5(1)) Keeping it accurate is a standing duty, and the two instruments phrase that duty differently. The implementing regulation says "Wallet-relying parties shall update any information previously registered in the national register of wallet-relying parties without undue delay." (CIR (EU) 2025/848, Article 5(3))
The amending Regulation puts it as "Relying parties registered in accordance with this Article shall inform Member States without delay about any changes to the information provided in the registration pursuant to paragraph 2." (Regulation (EU) 2024/1183, Article 5b(6)) The two standards are not interchangeable.
Leaving is an action too. A relying party that stops relying on wallet units under a registration has to notify the registrar without undue delay and request cancellation (CIR (EU) 2025/848, Article 6(7)), so a team that quietly disables the integration leaves a live public entry behind.
Losing the registration is an outage
One ground for suspension or cancellation points straight at the request builder. Article 9(2) lists the case where "the wallet-relying party is requesting more attributes than they have registered in accordance with Article 5 and Article 6;" (CIR (EU) 2025/848, Article 9(2), point (c)) Whatever raises a warning in the user's wallet is the same thing that can cost you the entry.
A suspension can arrive with no warning in front of it
The decision carries a weighing step and no notice requirement. Before acting on a paragraph 2 ground the registrar conducts a proportionality assessment covering users' fundamental rights, security and confidentiality, the severity of the disruption and the costs to the relying party and the user. Then "Based on the result of this assessment, the registrar may suspend or cancel the registration with or without prior notice to the affected wallet-relying party." (CIR (EU) 2025/848, Article 9(4)) That is what turns revocation into an availability dependency, because it fires on a timetable you do not control.
Model revocation as an availability event, not a letter
Revocation reaches both certificate providers at once. "The provider of wallet-relying party access certificates and the provider of wallet-relying registration certificates, shall, where applicable, revoke without undue delay the wallet-relying party access certificates, and the wallet-relying party registration certificates, respectively, of the wallet-relying party for which registration has been suspended or cancelled." (CIR (EU) 2025/848, Article 9(6))
Losing the access certificate removes the ability to authenticate to wallets at all, so a wallet presentation on the onboarding or login critical path makes this a production incident. The registrar has to tell you and both certificate providers within 24 hours (CIR (EU) 2025/848, Article 9(5)). A legal remedy is mandated even though a technical one is not: "This notification shall include information on the reasons for the suspension or cancellation and on the available means of redress or appeal." (CIR (EU) 2025/848, Article 9(5)) The notice that takes the service down also names the route to contest it.
Record-keeping outlasts the product. Registrars keep the registered information, the certificate issuance records and every subsequent change for 10 years (CIR (EU) 2025/848, Article 10), longer than most systems survive.
What Annex I actually asks you to produce
Annex I is where the abstraction stops and a deliverable appears. Point 9 carries the engineering weight. It asks for "For each intended use, a list of the data, including attestations and attributes, that the relying party intends to request, a user-friendly name and a technical name, the attestation type and any other syntaxes that the data is grouped under, in a machine-readable format for automated processing." (CIR (EU) 2025/848, Annex I, point 9)
Purpose and status are registered separately. Point 10 wants a description of the intended use of the data (CIR (EU) 2025/848, Annex I, point 10), and point 11 an indication of whether the relying party is a public sector body (CIR (EU) 2025/848, Annex I, point 11).
The registration file is a build artifact, not a form
Point 9's fields are close to what your verifier encodes in its presentation request: a machine-readable name, a type and a grouping syntax. Generating the register entry and the request from one source keeps them in agreement as the product changes, and a reconciliation check that fails the build on divergence does the same job with two sources.
Annex I point 12 sets out ten entitlement values to pick from. An ordinary business registers under the one given at point 12(a) as "‘Service_Provider’ to express the entitlement of the wallet-relying party as a provider of services;" (CIR (EU) 2025/848, Annex I, point 12(a))
Delegation is registered too: point 14 asks for an indication that the relying party relies on an intermediary acting on its behalf (CIR (EU) 2025/848, Annex I, point 14). That pairs with a rule in the amending Regulation: "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction." (Regulation (EU) 2024/1183, Article 5b(10)) A vendor fronting the wallet interaction does not absorb its customer's obligation. It acquires one of its own.
A worked example, constructed here and not taken from the text
The table below is an illustration built for this article. Its column headings are the fields Annex I point 9 asks for; every value in the body is invented. The scenario is a vehicle rental checkout plus an account recovery flow.
| Intended use | User-friendly name | Technical name | Attestation type | Other syntaxes the data is grouped under |
|---|---|---|---|---|
| Vehicle rental checkout | Age over 18 | age_over_18 | Person identification data | mdoc |
| Vehicle rental checkout | Driving categories held | driving_privileges | Mobile driver license | mdoc |
| Account recovery | Family name | family_name | Person identification data | SD-JWT VC |
Three rows, two intended uses. Adding a date-of-birth field to the rental request adds a fourth row, an amendment to a public filing before it is a sprint task. Point 10 wants one description of intended use per purpose, so the two rental rows share one and the recovery row carries its own. Any attribute in your presentation request with no row here is the failure mode this article describes.
Duties a registration does not buy you
Registration buys no anonymity and no entitlement to a legal name. Article 5b(8) runs to one sentence: "Where relying parties intend to rely upon European Digital Identity Wallets, they shall identify themselves to the user." (Regulation (EU) 2024/1183, Article 5b(8))
Article 5b(9) closes with a limit that catches many designs: "Relying parties shall not refuse the use of pseudonyms, where the identification of the user is not required by Union or national law." (Regulation (EU) 2024/1183, Article 5b(9)) A flow that insists on a legal name because the schema has a name column is not rescued by having registered that field.
Verification is still your engineering problem
The same paragraph puts the cryptographic work squarely on the relying party. "Relying parties shall be responsible for carrying out the procedure for authenticating and validating person identification data and electronic attestation of attributes requested from European Digital Identity Wallets." (Regulation (EU) 2024/1183, Article 5b(9)) The wallet presents, and you authenticate and validate what arrives. Registration unlocks that build rather than replacing it, and the build itself is covered in our walkthrough of verifier implementation with OpenID4VP.
That build has a named regulatory input on the certificate side. Article 7(3) sends Member States to one annex for "the certificate policies and certificate practice statements for the wallet-relying party access certificates, in accordance with the requirements set out in Annex IV." (CIR (EU) 2025/848, Article 7(3)) Annex IV is the document to open next to the verifier work, since it governs the access certificate that authenticates your verifier to a wallet.
A wallet request inside a payment or login authentication flow has a second rule set to reconcile, covered in our note on wallets and strong customer authentication.
Two dates that are not the same date
The registration regime carries an application date of its own. Article 11 of the implementing regulation says "It shall apply from the 24 December 2026." (CIR (EU) 2025/848, Article 11)
The wallet obligation is a period, not a calendar date
Compare the obligation on Member States to provide a wallet, which is written in a different shape. Article 5a(1) of Regulation (EU) 2024/1183 closes with the clause "each Member State shall provide at least one European Digital Identity Wallet within 24 months of the date of entry into force of the implementing acts referred to in paragraph 23 of this Article and in Article 5c(6)." (Regulation (EU) 2024/1183, Article 5a(1))
That period runs from the entry into force of implementing acts, so no fixed day appears in the operative text and none should be computed and presented as what the Regulation says. The two facts sit close enough to be conflated, so when a plan cites a single wallet deadline, establish which of the two it means.
What to put in the plan
Registration comes before certificates. Certificates come before any authenticated request, and the registered attribute list keeps constraining that request afterwards.
- Ask the registrar in your Member State of establishment for the timeframe in its registration policy, and schedule against that number.
- Give the Annex I point 9 list one named owner and a reconciliation check against the verifier's presentation request, so a new attribute fails a build before it becomes an unamended filing.
- Write the revocation path into the incident runbook next to the verifier work, with the redress notice as the artifact the response starts from.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 5
No matches
Try a different keyword, change the topic or clear filters
-
The duty is placed in the Member State where the relying party is established, so it follows your corporate footprint rather than your customer map. Each Member State publishes its own register and exposes it through a single common interface alongside a national website.
The instruments do reach the cross-border case in one specific way: under Article 6(3), point (d) of the implementing regulation the registrar verifies, where possible, the absence of an existing registration in another national register, so an entry made in one Member State is a fact the next registrar checks for. What Article 6(3) leaves open is the consequence of finding one, and that is the question to put to each national registrar before assuming a group can hold parallel entries.
-
There is nothing to work against. A registrar that cannot verify the submitted information rejects the registration outright rather than granting a provisional one, and providers of access certificates issue them exclusively to registered relying parties.
Test and development environments sit outside what these two instruments address, so plan the production path as a sequential dependency and confirm any sandbox arrangement with the national registrar directly.
-
Three things move at once. The registered attribute list has to be updated without undue delay.
In a Member State that authorised registration certificates, wallet providers established there inform the user that you are asking for data outside your registration certificate. And requesting more attributes than you registered is itself a listed ground for suspending or canceling the entry, which applies in every Member State whether or not that wallet warning exists. In practice the register entry belongs in your release process, not in a filing cabinet.
-
Not necessarily. The implementing regulation obliges Member States to authorise at least one authority to issue access certificates, but only permits them to authorise one for registration certificates.
A relying party operating in several countries should design for the case where no registration certificate exists, which also means no general access policy is presented to the user in that country.
-
No. An intermediary acting on behalf of a relying party is itself treated as a relying party and may not store data about the content of the transaction. Before you rely on one, read its own register entry: its Annex I point 9 list should already cover every attribute it will request on your behalf, and its point 12 entitlement value should match the role it actually plays for you.
Your own entry then carries the point 14 indication that you rely on an intermediary and the point 15 association naming which one.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
