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, PID provider, EAA provider, QEAA provider, 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.
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.
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.
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.
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.
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 wallet privacy controls including selective disclosure, wallet-relying-party specific pseudonyms, registration-data visibility, and limits on data requested beyond intended wallet use.
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 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.