We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

EU eIDAS wallet guideRelying party onboarding

EUDI Wallet Relying Party Onboarding Workflow

Review this workflow before a public or private service requests person identification data or electronic attestations of attributes from European Digital Identity Wallet users.

Build the onboarding record around the relying-party role, registration information, intended uses, requested data, presentation checks, user approval, validation evidence, and privacy controls.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
5 sections8 primary sources
Overview

An organisation that intends to use EUDI Wallet units to provide a public or private digital service must register as a in its Member State of establishment. Prepare one traceable record for the legal entity, each intended use, the exact attestations and attributes to be requested, any intermediary, and the relying-party instance that will authenticate to wallets. Commission Implementing Regulation (EU) 2025/848 is in force but applies from 24 December 2026; before that date, confirm the operational registration route and timing with the relevant Member State rather than treating a preparation file as an accepted registration.

Section 1

1. Confirm the relying-party role and service boundary

Start by documenting whether the organisation is the service provider that will request wallet attributes or an intermediary acting for another relying party. eIDAS treats the intermediary as a relying party and prohibits it from storing transaction-content data. The ARF uses for the software and hardware that interacts with Wallet Units.

Keep the onboarding record at legal-entity and intended-use level. Regulation 2025/848 requires the register to identify the service type and, for each intended use, list the requested data with user-friendly and technical names, attestation type, machine-readable grouping, and a description of how the data will be used.

  • Actor record: legal name, Member State of establishment, registration number if applicable, contact details, and whether an intermediary is involved.
  • Service record: public or private service, user journey, online or proximity presentation, and the that will send requests to Wallet Units.
  • Boundary check: distinguish the relying-party service from wallet provider, PID provider, QEAA provider, Pub-EAA provider, and non-qualified EAA provider roles.
  • Intermediary check: record the principal relying party, intermediary identity and association, division of validation duties, forwarding path, and the control that prevents storage of transaction-content data. The intermediary must not store transaction-content data.
Section 2

2. Prepare the registration and intended-use evidence

Prepare the registration package for the Member State where the relying party is established. From 24 December 2026, Regulation 2025/848 requires Member States to maintain national registers and publish national registration policies. Those policies may add supporting documentation and verification procedures, so the Annex I fields are a minimum, not a complete substitute for the national policy.

Use one intended-use entry for each service purpose that requests a different data set or uses the data differently. Registered information must remain accurate and be updated without undue delay. When an intended use ends, the relying party must ask the registrar to cancel that registration.

  • Identity and service information: official or user-friendly name as applicable, official identifiers, physical establishment address, website where applicable, Member State, service description, public-sector status, and the entitlement under which the relying party acts.
  • Contact information: at least one helpdesk website, registration phone number, or registration email address, plus internal owners for changes, complaints, erasure requests, and suspicious-request reports.
  • Intended use: a user-facing and technical description of each service purpose, whether the relying party relies on electronic identification of natural persons, and whether identification is required or a pseudonym is sufficient under Union or national law.
  • Requested data: for each intended use, the user-friendly and technical data names, attestation type, machine-readable grouping, selective-disclosure design, and the service decision each item supports.
  • Intermediary and lifecycle information: whether an intermediary is used, its registered association, the owner for updates without undue delay, and the cancellation trigger when the intended use ends.
Section 3

3. Design the wallet data request before building the integration

Translate each registered intended use into a presentation request that a user can understand. prohibits requests for data beyond the registered indication and requires the relying party to identify itself. Use where the attestation and protocol support it, and do not refuse a pseudonym when Union or national law does not require identification.

Keep legal duties separate from ARF design guidance. The ARF describes registration comparisons, user warnings, approval flows, and embedded disclosure policies. Use those mechanisms in the technical design, but verify the production profile against the applicable implementing acts, national registration policy, and wallet-supported protocols.

  • Attribute request matrix: intended-use identifier, requested attribute, attestation type such as PID, QEAA, Pub-EAA, or EAA, and the service decision the attribute supports.
  • Minimisation check: remove attributes that are not required for the service decision, and record why a pseudonym is or is not sufficient.
  • User-facing request text: relying-party identity, purpose, requested attributes, consequences of approval, and any disclosure-policy warning returned by the Wallet Unit.
  • Protocol evidence: whether the request uses a wallet-supported protocol or interface for requesting and validating PID or electronic attestations of attributes.
  • Exception handling: what the service does if the user rejects the request, if the wallet cannot retrieve registration information, or if an attestation policy warns against disclosure.
Section 4

4. Implement relying-party authentication, validation, and logging controls

The onboarding gate should not close until the technical team can prove that each authenticates to Wallet Units and that the relying party validates requested PID or attestations after user approval. Regulation 2025/848 requires Member States to authorise at least one certificate authority to issue exclusively to registered relying parties. Registration certificates are different: Regulation 2026/1730, which enters into force on 11 August 2026, requires Member States to authorise at least one registration-certificate authority and require automated issuance without undue delay after registration.

Keep evidence that explains both sides of the interaction: what the wallet can verify about the relying party before asking the user, and what the relying party verifies about the received PID or attestation before relying on it.

  • Access-certificate evidence: issuing authority, certificate chain, relying-party identity fields, assignment, registration status, expiry, and revocation-check method. Do not treat a registration certificate as the access certificate used to authenticate the relying party.
  • Request-signing evidence: signed request payload, requested attributes, intended-use reference, nonce or replay-protection mechanism where applicable, and protocol version.
  • Wallet-side evidence: test showing that the Wallet Unit can authenticate the relying party and warn when requested attributes exceed registered attributes.
  • Relying-party validation evidence: issuer signature validation, attestation or PID revocation status check, wallet authenticity check, and device-binding or user-binding check where the use case requires it.
  • Operational logs: user approval result, attributes actually received where retention is lawful and necessary, validation result, rejection reason, erasure-request handling path, and suspicious-request escalation path. For an intermediary, exclude transaction-content data and keep only non-content evidence permitted by the role and applicable law.
Section 5

5. Add privacy, security, and review gates before launch

The final onboarding review should test privacy, security, registration accuracy, and failure handling. eIDAS gives wallet users control over wallet data and limits relying parties to the data indicated at registration. Regulation 2025/848 allows registration suspension or cancellation for inaccurate or misleading information, breach of registration policy, over-requesting attributes, or other relevant breaches of Union or national law.

Close the workflow only when the service can show that it requests no more than registered attributes, identifies itself to the user, validates received evidence, accepts pseudonyms where identification is not legally required, and has a change process for registration updates.

  • Data minimisation: the production request does not exceed the data registered for that intended use.
  • User control: the wallet interaction supports user approval or rejection and does not treat wallet approval as a standalone GDPR lawful basis.
  • Pseudonym handling: the service accepts pseudonyms where user identification is not required by Union or national law, and records any reason identity is required.
  • Security controls: mutual authentication, encrypted communication, signed requests or responses, certificate-chain validation, revocation checks, and replay-protection evidence are tested.
  • Linkability controls: avoid unnecessary fixed identifiers and cross-service correlation, apply the wallet and attestation privacy mechanisms, and retain only the data supported by a defined purpose and applicable data-protection rules.
  • Reopen triggers: new intended use, new requested attribute, new , intermediary change, registration-data change, protocol or certificate change, suspicious-request report, or failed validation control.
EU eIDAS wallet next step

This workflow helps prepare wallet data requests and evidence

Sorena can help convert your intended wallet use, requested attributes, registration evidence, validation controls, and privacy gates into a practical onboarding record for eIDAS wallet relying-party work.

Research workflow
Open Research Copilot for EU eIDAS

Ask questions tied to cited sources about EUDI Wallet relying-party registration, attribute requests, ARF controls, and onboarding evidence using the cited sources on this page.

Explore next step
Talk to Sorena
Review a wallet onboarding plan

Check your relying-party role, requested data, registration evidence, validation controls, and privacy gates before launching wallet requests.

Explore next step
Primary sources

References and citations

Commission Implementing Regulation (EU) 2025/848
eur-lex.europa.eu5 citations
Referenced sections
  • Binding registration rules for national registers and policies, minimum information, updates, cancellation, access certificates, registration certificates, suspension, and record keeping; applicable from 24 December 2026.
  • Defines wallet-relying-party, access certificate, registration certificate, registrar, national registers, intended-use data, intermediary associations, and the 24 December 2026 application date.
  • Binding implementing rules for national registration policies, minimum register information, verification, updates, cancellation, access certificates, and registration certificates; applicable from 24 December 2026.
Show 2 more
  • Requires Member States to authorise at least one access-certificate authority and limits access certificates to registered wallet-relying parties; applicable from 24 December 2026.
  • Articles 5, 6, 8, and 9 ground registration accuracy, intended-use scope, registration-certificate controls, updates, cancellation, suspension, and over-requesting controls; the Regulation applies from 24 December 2026.
"It shall apply from the 24 December 2026."
More quoted passages
"registration of wallet-relying parties"
"issue wallet-relying party access certificates exclusively to registered wallet-relying parties"
"requesting more attributes than they have registered"
EUDI Wallet Architecture and Reference Framework
eu-digital-identity-wallet.github.io5 citations
Referenced sections
  • Technical architecture source for relying-party role definitions, Relying Party Instances, registration certificates, access certificates, presentation flow, validation checks, disclosure policies, and risk controls.
  • The ARF defines the service-provider-focused Relying Party role, Relying Party Instances, and the wallet presentation trust relationships.
  • The ARF describes the registration-attribute comparison, disclosure-policy evaluation, and user approval steps for PID or attestation presentation to a relying party.
Show 2 more
  • The ARF presentation lifecycle defines relying-party authentication, registered-attribute verification, user approval, issuer-signature validation, revocation checks, and binding checks.
  • The ARF risk discussion supports the security and privacy controls for relying-party requests, including selective disclosure, registered requested attributes, disclosure policies, and linkability mitigation.
"Architecture and Reference Framework"
More quoted passages
"A Relying Party is a service provider requesting attributes"
"The User approves or rejects the presentation"
"PID or attestation presentation to a Relying Party"
"Relying Party linkability"
Regulation (EU) No 910/2014, consolidated eIDAS text
eur-lex.europa.eu5 citations
Referenced sections
  • Primary legal source for Article 5a wallet controls and Article 5b wallet relying-party registration, data-request, pseudonym, validation, and intermediary rules.
  • Article 5b sets the registration and responsibility baseline for European Digital Identity Wallet relying parties, including intermediaries acting on their behalf.
  • Article 5b lists the minimum relying-party registration information and bars requests for data outside the registered indication.
Show 2 more
  • Article 5a requires wallet support for selective disclosure, user control, relying-party authentication, erasure requests, suspicious-request reporting, and privacy-preserving techniques.
  • Article 5a and Article 5b ground the wallet user-control, privacy, registration, data-request, pseudonym, validation, and change-notification controls used in this launch gate.
"European Digital Identity Wallet‑Relying Parties"
More quoted passages
"Intermediaries acting on behalf of relying parties shall be deemed to be relying parties"
"the intended use of European Digital Identity Wallets"
"while ensuring that selective disclosure of data is possible"
"Users shall have full control"
Commission Implementing Regulation (EU) 2026/1730
eur-lex.europa.eu4 citations
Referenced sections
  • Adopted amendment requiring registration-certificate authorities, automated issuance, harmonised certificate policies, and wallet warnings for requests outside the registration certificate; it enters into force on 11 August 2026.
  • Amends the future registration-certificate rules to require at least one registration-certificate authority per Member State and automated issuance without undue delay after registration; it enters into force on 11 August 2026.
  • Amends the registration-certificate rules to require an authority and automated issuance; it enters into force on 11 August 2026.
Show 1 more
  • Requires registration certificates to carry a general access policy and wallet providers to inform users when requested data are outside the registered certificate scope; it enters into force on 11 August 2026.
"Member States shall authorise at least one certificate authority to issue wallet relying party registration certificates."
More quoted passages
"issue wallet-relying party registration certificates in an automated manner and without undue delay after the registration"
"informing users when a wallet-relying party requests data that is not specified in the registration certificates"
European Commission - Wallet for service providers
ec.europa.eu3 citations
Referenced sections
  • Commission-facing guidance for service providers that request data from wallet users, including examples, requested data types, registration requirements, operational requirements, and change obligations.
  • Commission service-provider guidance summarises the registration, intended-use, requested-data, identification, validation, pseudonym, and change-notification expectations for organisations requesting wallet data.
  • Commission service-provider guidance lists operational obligations such as not requesting extra data, identifying to users, validating PID and EAA data, accepting pseudonyms where appropriate, and notifying Member States about registration changes.
"Learn how organisations can request data from wallet users"
More quoted passages
"specifying the data to be requested from users"
"Not request any extra user data"
Commission Implementing Regulation (EU) 2024/2979
eur-lex.europa.eu2 citations
Referenced sections
  • Wallet integrity and core-functionality implementing regulation referenced for wallet controls that affect relying-party presentation requests and disclosure-policy handling.
  • The ARF ties embedded disclosure-policy support for electronic attestations of attributes to the wallet integrity and core-functionality implementing rules.
"integrity and core functionalities"
More quoted passages
"rules for the integrity and core functionalities"
Commission Implementing Regulation (EU) 2024/2982
eur-lex.europa.eu2 citations
Referenced sections
  • Wallet protocols and interfaces implementing regulation referenced for relying-party request and validation integrations.
  • Commission implementing rules identify protocols and interfaces for wallet solutions, including relying-party request and validation interfaces referenced by the Commission implementing-regulation page.
"protocols and interfaces"
More quoted passages
"protocols and interfaces of eID Wallets solutions"
European Commission - Implementing regulation for European Digital Identity Wallets
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission overview of the adopted EUDI Wallet implementing regulations covering core functionality, protocols and interfaces, PID and EAA, certification, and ecosystem notifications.
  • Commission overview page links the five wallet implementing regulations, including core functionality, protocol/interface, PID/EAA, certification, and ecosystem-notification measures.
"five implementing regulations"

Related guides

eIDAS 2 deadlines and compliance calendar for EUDI Wallet and trust services

eIDAS 2 calendar separating binding EUDI Wallet, reporting, and trust-service dates from implementation milestones and technical programme updates.

eIDAS 2.0 vs eIDAS: EUDI Wallet and trust-service changes

Compare the original eIDAS electronic identification and trust-service framework with the eIDAS 2.0 amendments for EUDI Wallets, relying parties, attestations, QWACs, and supervision.

eIDAS Certificates and Authentication: qualified certificates, QWACs, and validation checks

Official source guide to eIDAS qualified certificates, website authentication certificates, trusted lists, relying-party checks, and validation evidence.

eIDAS checklist and evidence pack for trust services, signatures, and EUDI Wallet relying parties

Build an eIDAS evidence pack for qualified trust services, electronic signatures, trusted-list checks, certificate validation, supervisory records, and EUDI Wallet relying-party controls.

eIDAS compliance guide for trust services, QTSPs, signatures, and EUDI Wallet relying parties

Official source eIDAS compliance guide for trust-service classification, QTSP supervision evidence, qualified signatures, seals, time stamps, certificates, trusted-list validation, and EUDI Wallet relying-party records.

eIDAS electronic signatures: SES, AES, QES legal effect and evidence

An official source guide to eIDAS electronic-signature legal effect: SES, AES, QES, qualified certificates, QTSP trusted-list checks, validation, recognition, and evidence records.

Show all related guides (35)

eIDAS penalties and fines for trust service providers

Guide to eIDAS Article 16 fine floors, national penalty rules, supervisory action, qualified-status withdrawal, and trusted-list evidence.

eIDAS QES validation checks for relying parties

How to validate a qualified electronic signature under eIDAS: certificate, QTSP, trusted-list, QSCD, integrity, validation result, and evidence records.

eIDAS Qualified Trust Services: QTSP Selection

How to select an EU eIDAS qualified trust service provider: identify the qualified service type, verify trusted-list status, review supervision evidence, and retain certificate-policy records.

eIDAS remote signature and cloud HSM controls for QTSPs

Source-grounded guide to eIDAS remote signature controls: remote QSCD scope, server-side signing, QTSP evidence, signer authentication, certificate validation, and trusted-list checks.

eIDAS signature legal effect selector: SES, AES, AES-QC, or QES

Compare eIDAS signature levels by legal effect, governing form rules, qualified certificate status, QTSP evidence, QSCD use, validation, and public-service recognition.

eIDAS trust service role scoping workflow: TSP, QTSP, validator, relying party, or QTSP customer

Classify an eIDAS role by evidence: trust service provider, qualified trust service provider, signature or seal validator, EUDI Wallet relying party, relying party, or customer of a QTSP.

eIDAS trusted list validation: LOTL, QTSP status, and evidence

How to validate EU eIDAS trusted-list evidence: start from the Commission LOTL, confirm QTSP and qualified-service status, check certificate path and revocation data, and retain validation reports.

eIDAS vs ESIGN and UETA: EU qualified signatures vs U.S. e-signature laws

Compare eIDAS with ESIGN and UETA for electronic signatures, qualified certificates, trust services, cross-border recognition, validation evidence, and source gaps.

eIDAS vs ETSI EN 319 401: legal supervision and TSP policy requirements

Compare eIDAS and ETSI EN 319 401 for trust services: legal scope, QTSP supervision, conformity assessment, audits, incident evidence, and operational controls.

eIDAS vs GDPR for identity data: wallet, trust-service, and privacy obligations

Compare eIDAS identity, trust-service, and EUDI Wallet rules with GDPR duties for personal-data processing, minimisation, lawful basis, evidence, security, and user rights.

eIDAS vs NIS2 for trust service providers: QTSP and cybersecurity obligations

Compare eIDAS trust-service and QTSP duties with NIS2 cybersecurity risk-management, incident reporting, supervision, and evidence duties for trust service providers.

Electronic Attestations of Attributes under EU eIDAS: EAA, QEAA, issuers, wallets, and validation

Official source guide to electronic attestations of attributes under amended EU eIDAS: EAA, QEAA, public-sector authentic-source attestations, wallet use, issuer checks, relying-party validation, revocation, and legal effect.

EU eIDAS Applicability Test for Trust Services, Wallets, and Certificates

An official source eIDAS scope test for QTSPs, trust services, electronic signatures, seals, timestamps, QWACs, EUDI Wallet relying parties, and cross-border recognition evidence.

EU eIDAS checklist for signatures, trust services, and wallets

Checklist for eIDAS trust-service and EUDI Wallet controls: qualified status, trusted lists, certificates, signatures, seals, timestamps, validation evidence, and relying-party records.

EU eIDAS FAQ: signatures, QTSPs, trusted lists, QWACs, wallets, and validation

FAQ on eIDAS trust services and the European Digital Identity framework, covering advanced and qualified electronic signatures, QTSP status, trusted lists, QWACs, EUDI Wallet relying parties, attestations of attributes, and validation evidence.

EU eIDAS QTSP authorization and supervision guide

How qualified trust service providers obtain and keep qualified status under eIDAS, including conformity assessment reports, supervision, trusted lists, incidents, and evidence.

EU eIDAS QTSP Due Diligence Workflow for Trusted Lists, Certificates, and Evidence

Check a qualified trust service provider under eIDAS by validating trusted-list status, qualified service scope, certificates, policies, supervision, audits, and retained evidence.

EU eIDAS Requirements for Trust Services, Signatures, Seals, Wallets, and Evidence

Official source guide to core eIDAS requirements for trust service providers, qualified trust services, electronic signatures, seals, time stamps, trusted lists, and EUDI Wallet relying parties.

EUDI Wallet readiness for service providers under eIDAS

Readiness guide for organisations preparing to request or verify data from European Digital Identity Wallets: roles, registration, ARF alignment, selective disclosure, implementing acts, and evidence.

EUDI Wallet Relying Party Registration Under eIDAS

What eIDAS Article 5b and the EUDI Wallet ARF say about wallet relying party registration, intended uses, attribute requests, certificates, evidence, and Member State gaps.

EUDI Wallet Technical Architecture Guide under eIDAS

Technical guide to the EUDI Wallet architecture: ARF roles, wallet units, PID and attestations, relying parties, trust model, certificates, protocols, privacy, and security controls.

QWACs under eIDAS: website authentication certificates

A source-grounded guide to qualified website authentication certificates under eIDAS, covering Annex IV data, trusted lists, browser recognition, validation evidence, and QTSP checks.

What eIDAS Covers: eID, Trust Services, EUDI Wallet, and QWACs

A source-grounded guide to the systems and services covered by EU eIDAS: notified electronic identification, trust services, signatures, seals, time stamps, registered delivery, website authentication, trusted lists, the EUDI Wallet, and attribute attestations.

EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks

What electronic attestations of attributes mean under eIDAS, how QEAAs differ from public-sector and non-qualified attestations, and what issuers, wallets, and relying parties should verify.

EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence

How EU eIDAS Trusted Lists and the Commission LOTL support QTSP and qualified trust-service validation, with practical evidence checks for relying parties.

EUDI Wallet Relying Parties under eIDAS

What EUDI Wallet relying parties must do under eIDAS, when the harmonised registration rules apply, and how to control requested data, identification, validation, and evidence.

QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence

Compare qualified electronic signatures (QES) and advanced electronic signatures (AdES) under EU eIDAS, including legal effect, qualified certificates, QTSP status, QSCDs, and validation evidence.

What is a qualified trust service provider under eIDAS?

How to verify QTSP status under eIDAS using the qualified service, supervisory body decision, trusted list entry, conformity assessment evidence, and service-specific records.

What is a QWAC under the EU eIDAS Regulation?

Plain-language FAQ on qualified website authentication certificates under eIDAS, including website identity, QTSP trusted-list checks, browser recognition, and validation evidence.