An official source readiness guide for organisations preparing to rely on European Digital Identity Wallets for authentication, person identification data, electronic attestations of attributes, pseudonyms, or qualified electronic signatures.
Use it to align legal, product, security, privacy, architecture, and onboarding work around the eIDAS wallet roles, ARF expectations, implementing acts, relying-party registration, and evidence needed for launch review.
readiness covers more than login. Under the amended eIDAS framework, a service provider or wallet-relying party has to understand which wallet role it plays, what attributes it intends to request, how the user will approve presentation, how relying-party authentication works, and what evidence shows that the request is limited to the registered purpose. This page focuses on practical readiness checks supported by the eIDAS text, the EUDI Wallet , Commission wallet guidance, and the cited wallet implementing acts.
1
Section 1
What EUDI Wallet readiness means for a service provider
Start by separating ordinary account login from a wallet-relying-party interaction. eIDAS defines a European Digital Identity Wallet as an electronic identification means that lets the user securely store, manage, validate, and present person identification data and electronic attestations of attributes to relying parties, and also sign or seal by qualified electronic signatures or seals.
For a service provider, the readiness question is whether the service will request wallet data before granting access, verifying eligibility, completing onboarding, accepting a document, applying a pseudonym, or triggering a signature flow. If yes, the integration should be treated as an relying-party capability with a registered purpose, a defined attribute set, wallet-user approval, and a verifiable technical interface.
Member States must provide at least one wallet within 24 months after the relevant implementing acts entered into force, which the Commission describes as an end-of-2026 rollout. That rollout date is not a universal private-service acceptance deadline. Article 5f applies private-sector acceptance only where Union, national, or contractual rules require strong user authentication, excludes microenterprises and small enterprises, and makes use conditional on the user's voluntary request.
Name the wallet use case: authentication, attribute presentation, document verification, pseudonymous access, qualified electronic signature, qualified electronic seal, or another supported wallet interaction.
Identify the actor role used in the ARF: relying party, intermediary, wallet provider, person identification data (PID) provider, electronic attestation of attributes (EAA) provider, qualified electronic attestation of attributes (QEAA) provider, qualified electronic signature (QES) remote-creation provider, registrar, access certificate authority, or provider of registration certificates.
Record the exact attributes requested from the wallet and the service purpose for each attribute.
Keep wallet flows voluntary where the legal source requires user request or user approval, and preserve existing access routes where the service must remain available without wallet use.
Supports the readiness split between wallet ecosystem roles, including relying parties, registrars, access certificate authorities, wallet providers, PID providers, and attestation providers.
Overview of the EUDI Wallet ecosystem roles
2
Section 2
Relying-party and service-provider registration checks
Article 5b requires a wallet-relying party to register in the Member State where it is established. Commission Implementing Regulation (EU) 2025/848 is in force and applies from 24 December 2026. From that date, it requires Member States to maintain national registers, publish national registration policies, and expose registered information through a national website and common API in human- and machine-readable form. The relying party must provide accurate registration information and update it without undue delay.
The ARF explains the operational consequence: a relying party registers the attributes it intends to request from wallet units, and a wallet unit can verify whether the request is within that registered scope. ARF version 2.7.3 describes certificate validation or registrar lookup, but Commission Implementing Regulation (EU) 2026/1730 requires Member States to ensure automatic registration-certificate issuance without undue delay when the harmonised rules apply from 24 December 2026.
Create a relying-party registration inventory with establishment Member State, legal entity, contact details, service name, intended uses, requested attributes, and any intermediary relationship.
Read the establishment Member State's published registration policy for identity checks, business-registration evidence, entitlements, representation evidence, update steps, processing timeframe, and redress route.
For each relying-party instance, record the access certificate expected to authenticate the requesting system to wallet units.
If using an intermediary, document which relying party the intermediary acts for, which attributes the intermediated relying party wants to request, and what evidence proves the intermediary relationship.
Add a change trigger for new attributes, new service purposes, new intermediaries, changed contact details, or changed registration jurisdiction.
Binding rules, applicable from 24 December 2026, for national registers, published registration policies, registration information, updates, common APIs, access certificates, suspension or cancellation, and registrar record retention.
Supports relying-party registration, registrar data, access certificates, registration certificates, and intermediary handling in the wallet ecosystem.
registers which attributes
3
Section 3
ARF and implementing-act alignment
The is the practical reference for wallet ecosystem roles, trust relationships, presentation flows, attestations, and certification concepts. It should be used as implementation architecture guidance, not as a substitute for the binding eIDAS text and implementing acts.
The Commission wallet implementing-regulation page identifies five implementing regulations covering integrity and core functionalities, protocols and interfaces, person identification data and electronic attestations of attributes, certification framework reference standards, and notifications to the Commission concerning the wallet ecosystem. A readiness file should map each wallet integration decision to the relevant source family rather than citing eIDAS in general.
Map wallet-unit, wallet-instance, wallet secure cryptographic application, and wallet secure cryptographic device assumptions to the integrity and core-functionality rules.
Map attribute issuance, PID handling, and electronic attestations of attributes to the person-identification-data and attestation rules.
Map interfaces, presentation requests, and relying-party authentication to the protocols-and-interfaces source family.
Map launch evidence for wallet solutions to certification and notification sources when the organisation provides or procures wallet components, not merely when it acts as a relying party.
Supports readiness checks that depend on wallet certification reference standards, specifications, and procedures.
certification of European Digital Identity Wallets
4
Section 4
Data minimization, selective disclosure, and user control
Readiness should include a privacy review of every requested attribute. eIDAS requires wallet functionality that allows of data, and Implementing Regulation 2024/2979 describes selective disclosure as enabling the owner of data to disclose only parts of a larger data set so the receiver obtains only what is necessary for the requested service.
The ARF treats excessive attribute requests as a specific ecosystem risk. It identifies three practical mitigations: and user control, mandatory relying-party registration of intended requested attributes, and embedded disclosure-policy enforcement by attestation providers. The service design should therefore show the user which data is requested, why it is requested, and whether the request matches registered relying-party scope.
Replace broad identity requests with purpose-specific attributes, such as age-over-threshold, entitlement status, membership status, licence category, or pseudonym where legal identity is not needed.
Do not store unique fixed elements from attestations longer than needed for the transaction or verification purpose, because the ARF identifies relying-party linkability as a privacy threat.
Where pseudonymous access is appropriate, check that the service does not require legal identity by law or service design before requesting person identification data.
Keep a user-facing request catalogue that matches registration scope: attribute, purpose, data-retention decision, fallback route, and owner.
Supports wallet privacy controls including selective disclosure, wallet-relying-party specific pseudonyms, registration-data visibility, and limits on data requested beyond intended wallet use.
Supports the risk controls for excessive attribute requests, relying-party linkability, selective disclosure, user approval, and embedded disclosure-policy enforcement.
Selective Disclosure and User Control
5
Section 5
Evidence to keep before launch review
A useful readiness record should prove more than technical connectivity. It should show that the organisation knows its role, has registered the intended attributes where required, can authenticate its relying-party instance, has limited data requests to the registered purpose, and has tested user approval, logs, fallback routes, and revocation or change handling.
For service-provider integrations, evidence should be reviewable by legal, privacy, security, architecture, product, and operations teams. For wallet providers or component providers, the evidence set is broader and should include certification, wallet-unit integrity, trusted-list or List of Trusted Entities dependencies, and incident or breach handling responsibilities.
Does every service-provider integration need a relying-party registration record?
A service provider that requests data from EU Digital Identity Wallet users should prepare for registration in the Member State where it is established and keep a record of the attributes it intends to request and the purpose for each request. The Commission service-provider guidance states that recognised service providers must register and must not request extra user data beyond what was specified during registration.
What is the main privacy risk in readiness for a relying party?
The main privacy risk is requesting or retaining more wallet data than the service reasonably needs. The ARF calls out excessive attribute requests and relying-party linkability, while eIDAS and the wallet implementing rules support , user control, pseudonyms, and transparency about registered relying-party data.
Can a relying party treat the as just another identity provider?
No. A wallet integration may involve registered requested attributes, user approval, access certificates, registration certificates, pre-harmonised registrar lookups, , pseudonyms, transaction logs, and attestation validation. Readiness work should cover those wallet-specific controls rather than only a standard single sign-on checklist.
Role and scope record: organisation role, service purpose, Member State registration route, relying-party instances, intermediary use, and launch countries.
Attribute request register: each requested wallet attribute, the user-facing purpose, the registered intended use, minimization rationale, fallback route, retention choice, and deletion or erasure handling.
Trust and certificate evidence: access certificate plan, registration certificate handling under the harmonised rules, any pre-harmonised registrar lookup behavior, and trust-anchor validation approach.
User-control evidence: screens or test logs showing the wallet request, requested attributes, approval or denial path, pseudonym handling where used, and transaction-log behavior.
Change and incident evidence: triggers for new attributes or purposes, changed registration data, revoked access certificates, wallet security breach notifications that affect relying parties, and privacy incident escalation.
Supports service-provider readiness evidence for registration information, contact details, requested data, purpose, no extra data requests, and registration-change notification.
Supports evidence for wallet user control, transaction logs, reporting suspicious requests, relying-party authentication, wallet certification, and security-breach handling.
access a log of all transactions
Recommended next step
Prepare registration, attribute requests, privacy controls, and evidence before wallet integration launch
Sorena can help convert the checks on this page into a cited readiness record for relying-party registration, requested attributes, ARF role mapping, selective disclosure, certificate evidence, and launch review.
Supports the readiness split between wallet ecosystem roles, including relying parties, registrars, access certificate authorities, wallet providers, PID providers, and attestation providers.
Supports relying-party registration, registrar data, access certificates, registration certificates, and intermediary handling in the wallet ecosystem.
Show 2 more
Supports the risk controls for excessive attribute requests, relying-party linkability, selective disclosure, user approval, and embedded disclosure-policy enforcement.
Supports evidence needs for relying-party registration, access certificates, registration certificates, registrar verification, and wallet-unit trust interactions.
Binding eIDAS source for European Digital Identity Wallet definitions, wallet functionality, selective disclosure, relying-party authentication, transaction logs, pseudonyms, certification, and security-breach handling.
Supports the legal definition of a European Digital Identity Wallet and the wallet functions that relying parties must design around.
Supports selective disclosure, user control, transaction logs, reporting suspicious requests, and pseudonym functionality in the wallet framework.
Show 1 more
Supports evidence for wallet user control, transaction logs, reporting suspicious requests, relying-party authentication, wallet certification, and security-breach handling.
Binding implementing regulation source for wallet integrity, core functionalities, wallet-unit concepts, wallet-relying-party access certificates, selective disclosure, pseudonyms, and registration-data visibility.
Supports wallet integrity and core-functionality checks, including wallet-unit definitions, wallet-relying-party access certificates, selective disclosure, pseudonyms, logs, and core wallet security concepts.
Supports wallet privacy controls including selective disclosure, wallet-relying-party specific pseudonyms, registration-data visibility, and limits on data requested beyond intended wallet use.
Amending act, entering into force on 11 August 2026, that requires automatic registration-certificate issuance without undue delay when the harmonised rules apply.
Amends the rules before their application date to require automatic registration-certificate issuance without undue delay after registration.
Requires automatic registration-certificate issuance without undue delay when the harmonised rules apply.
Commission guidance source for organisations that request data from wallet users, including service-provider registration and limits on requested data.
Supports the service-provider registration and attribute-request obligations described for organisations that request data from wallet users.
Supports service-provider readiness evidence for registration information, contact details, requested data, purpose, no extra data requests, and registration-change notification.
Binding implementing regulation source for person identification data and electronic attestations of attributes issued to European Digital Identity Wallets.
Supports readiness checks for person identification data and electronic attestations of attributes issued to European Digital Identity Wallets.
Binding implementing regulation source for certification framework reference standards, specifications, and procedures for European Digital Identity Wallets.
Supports readiness checks that depend on wallet certification reference standards, specifications, and procedures.
"certification of European Digital Identity Wallets"
Binding source, applicable from 24 December 2026, for national wallet-relying party registers, registration policies, information and update duties, common APIs, certificates, suspension or cancellation, and 10-year registrar record retention.
Binding rules, applicable from 24 December 2026, for national registers, published registration policies, registration information, updates, common APIs, access certificates, suspension or cancellation, and registrar record retention.
Commission overview source for the five wallet implementing-regulation topic areas: core functionalities, protocols and interfaces, PID and attestations, certification, and notifications.
Supports this page's analysis of list of five wallet implementing-regulation topics adopted under the European Digital Identity Framework.