eIDAS Article 5b EUDI Wallet relying party registration

Article 5b makes registration the entry point for wallet relying parties. The relying party must register in its Member State of establishment before relying on EUDI Wallets for a public or private service delivered through digital interaction.

The minimum registration package is specific. It must include information needed for authentication to EUDI Wallets, including the Member State of establishment, the relying party name, any official registration number and the official-record identification data, contact details, the intended use of the wallet, and an indication of the data the relying party will request from users.

From 24 December 2026, Commission Implementing Regulation (EU) 2025/848 requires the relying party to ensure that registration information is accurate when submitted and to update it without undue delay. A registrar may suspend or cancel a registration after a proportionality assessment when information is inaccurate, outdated, or misleading, when the relying party breaches the registration policy, requests more attributes than it registered, or otherwise breaches applicable Union or national law in its wallet role. Depending on that assessment, the registrar may act with or without prior notice.

After suspension or cancellation, the registrar must notify the relevant access-certificate and registration-certificate providers and the affected relying party without undue delay and no later than 24 hours after the decision. Certificate providers must then revoke the affected access and registration certificates without undue delay where applicable.

The 10-year retention duty in the implementing regulation applies to registrars, which must keep the information supplied by registered wallet-relying parties for monitoring, law-enforcement investigations, and dispute handling. It is not a general instruction for relying parties to retain every wallet transaction or presented attribute for 10 years.

The ARF treats intended use as a practical boundary for attribute requests. During registration, a relying party records which attributes it intends to request from wallet units for each service or intended use. If one organisation has materially different wallet uses, the ARF explains that a single relying party may register multiple times and may receive more than one registration certificate.

A single intended use can cover multiple attributes from multiple attestations, but the request should remain coherent for that use. If a relying party has multiple intended uses in one user journey, the ARF says it needs multiple presentation requests, each tied to the relevant intended use.

The ARF describes two preconditions before relying party authentication starts: the relying party registers and obtains an access certificate for each relying party instance, and the wallet unit obtains the trust anchor of the access certificate authority from the relevant list of trusted entities. In each presentation, the relying party instance includes its access certificate and trust chain, signs request data, and the wallet unit verifies the signature, certificate chain, and revocation status before asking the user for approval.

Registration certificates are a separate concept. Under the harmonised rules applying from 24 December 2026, Member States must ensure that they are issued automatically and without undue delay after registration. A registration certificate can list the attributes registered for a particular intended use, allowing the wallet to compare the requested attributes against what the relying party registered.

The ARF is explicit that user approval in the wallet means the user's decision to present attributes; it should not be treated as the relying party's lawful basis for processing personal data. The relying party still needs its own GDPR analysis for the requested attributes.

Before attributes are presented, the wallet informs the user about the relying party identity, any intermediary, the requested attributes, the relying party's intended use and privacy policy, and the outcome of checks against registered attributes or embedded disclosure policies where those checks are performed.

The EU-level sources do not give one universal public form, fee schedule, portal, evidence pack, or approval service-level agreement for every Member State relying party registration. Article 5b says the relying party registers in its Member State of establishment and that Member States make registration information public online in electronically signed or sealed machine-processable form.

For implementation, treat Member State procedure as a separate source gap until the relevant national registrar, registration portal, access certificate authority, or supervisory body has been identified from country-specific material.

A useful relying party file should let legal, product, engineering, privacy, and security reviewers see the same facts: who is registering, what service will use the wallet, which attributes are requested, how the wallet will authenticate the relying party, and what the user will see before approving presentation.

Keep the file scoped to the establishment Member State and update it whenever the registered information changes.