EUDI Wallet Compliance Checklist 2026

This EUDI Wallet compliance checklist 2026 is for regulated European businesses that need a practical answer to one high-intent question: what must be in place before you accept EU Digital Identity Wallet evidence? It is written from WalletFit's proprietary ARF↔eIDAS database by a founder who advised the Dutch government on EUDI/eIDAS, and it turns the free guide into the first screen before buying the €29 readiness kit.

Turn this into action

Get the checklist, scorecard, and prioritised action list in one €29 kit.

Built from WalletFit's ARF↔eIDAS cross-reference database and Dutch-government EUDI/eIDAS advisory experience, so your team can move from reading to a concrete readiness backlog.

Get the EUDI Wallet Readiness Kit — €29, instant download

Instant download. No account required.

1. Start with the real scope, not the headlines

eIDAS 2.0 creates a European Digital Identity Wallet framework that lets citizens, residents, and businesses receive, store, and present person identification data, electronic attestations of attributes, and signature capabilities under common EU rules. Member States must make at least one wallet available, while wallet providers, PID providers, attribute issuers, relying parties, registrars, trust services, and supervisory bodies each sit in a regulated trust ecosystem.

That does not mean every small merchant becomes a mandated wallet relying party overnight. The private-sector acceptance rule is targeted. WalletFit's ARF↔eIDAS mapping treats Article 5f as an applicability screen: first identify whether the organisation is excluded as a microenterprise or small enterprise; then check whether the service already requires strong user authentication for online identification under EU law, national law, or a contractual obligation; then confirm whether the use case falls in a relevant high-assurance sector.

The sectors most likely to need early attention are banking, financial services, transport, energy, social security, health, drinking water, postal services, digital infrastructure, education, and telecommunications. Very large online platforms have a separate wallet-authentication obligation when users voluntarily request it, and public-sector bodies must accept compliant wallets where electronic identification and authentication are required for online public services.

2. Treat “relying party” as a compliance role

A relying party is not just a website that receives a credential. It is an organisation that relies on wallet data to provide a service. Once your service requests identity, an attribute, a pseudonym, a mandate, or a wallet-based signature, your product team is touching legal purpose, data minimisation, trust validation, registration, security evidence, and user-choice design.

The most common mistake is to begin with an integration library. The safer sequence is legal and operational: register the relying-party purpose in the appropriate Member State, constrain the requested attributes to that registered purpose, configure wallet requests so they cannot drift beyond approval, and keep evidence that the wallet, issuer, credential, and trust status were checked at the moment of reliance.

Commission rules on wallet-relying-party registration make this operationally important. Businesses should be ready to maintain organisation identity details, establishment data, contact information, wallet authentication information, and the purposes or entitlements for which wallet data is requested. In practice, this becomes a living register of what your service is allowed to ask for.

3. Build the data-minimisation model before the button

Wallets are designed for selective disclosure. That is good for users, but it forces businesses to be precise. “Verify customer” is not a wallet request. A production request needs to say whether the journey needs a legal name, date of birth, age-over-threshold proof, address, professional qualification, student status, company mandate, payment entitlement, or simply a pseudonymous returning-user handle.

WalletFit's cross-reference database highlights pseudonyms because they will change common product patterns. If identification is not required by Union or national law, relying parties should not refuse pseudonymous authentication where it satisfies the service purpose. That means product teams need three modes: fully identified journeys, authenticated-but-pseudonymous journeys, and journeys where no wallet data is needed.

The same discipline applies to attributes. Electronic Attestations of Attributes and Qualified Electronic Attestations of Attributes can carry age, address, entitlement, qualification, licence, or mandate evidence. The business value is large: less document upload, less manual review, better cross-border trust. The risk is also large if teams request a full identity credential when an age-over-18 proof would do.

4. Know what each sector should do first

Banking, payments, insurance, and fintech

Map wallet presentations to KYC, AML refresh, strong customer authentication, mandate checks, and qualified signing flows.

Telecommunications and digital infrastructure

Identify subscriber-onboarding and SIM/eSIM journeys where identity proofing or age assurance could move from document upload to wallet proof.

Healthcare, social security, and public services

Define which PID, entitlement, professional qualification, and cross-border matching evidence is needed before access is granted.

Transport, energy, water, postal, and education

Screen every online service that already requires high-assurance authentication or identity evidence under sector rules or contracts.

Very large online platforms

Prepare voluntary wallet authentication that requests only the minimum data needed for the specific online service.

These are not legal conclusions for every company in a sector. They are the first screens a responsible owner should run. The final answer depends on size, Member State establishment, national implementation, sector law, the exact online service, and whether wallet use is requested voluntarily by the user.

5. The 2026 readiness checklist

Use this checklist before briefing engineering. It deliberately combines legal, compliance, UX, and technical work because wallet acceptance fails when any one of those tracks is treated as someone else's problem.

Decide whether Article 5f, public-sector acceptance, VLOP rules, or voluntary integration applies to each user journey.
List the exact person identification data, attestations, pseudonyms, mandates, or signatures each journey needs.
Prepare relying-party registration data for the Member State where the organisation is established.
Design minimum-necessary attribute requests and a plain-language explanation shown before wallet consent.
Choose technical protocols for remote presentation, proximity presentation, trust validation, and revocation checks.
Create audit logs that prove what was requested, why it was lawful, what was received, and which trust source was checked.
Keep a non-wallet fallback route for users while wallet coverage remains uneven across Member States.

6. What to build now

The near-term technical centre of gravity for most online businesses is remote presentation, trust validation, and evidence handling. Your architects should be evaluating OpenID4VP for presentation, SD-JWT VC and mdoc profiles where relevant, trust-list and certificate validation, revocation/status checks, and identity-matching logic for cross-border use cases. If your organisation will also issue credentials, add OpenID4VCI and an attestation rulebook covering semantics, issuer eligibility, assurance level, disclosure policy, and validation rules.

For qualified electronic signatures or seals, most relying parties should avoid building the full qualified trust-service stack themselves. Instead, decide where wallet-triggered signing fits your process, then partner with a qualified provider that can supply the conformity, remote qualified signature/seal creation device, and validation evidence your audit trail needs.

Finally, plan for uneven rollout. Through 2026 and 2027, wallet availability, registrar workflows, national implementation details, and credential catalogues will differ by Member State. A serious readiness plan therefore includes fallbacks: manual review, existing eID, document upload, or alternative authentication for users who do not yet have a suitable wallet.

7. The executive decision

The businesses that benefit from EUDI Wallets will not be the ones that wait for a final procurement memo titled “mandatory wallet acceptance.” They will be the ones that know exactly which journeys are in scope, which data is necessary, which register entry authorises the request, which trust source is checked, and which fallback protects users when wallets are not available.

If you are a regulated European business, your next step is not a full transformation programme. It is a short, concrete readiness review: screen Article 5f applicability, map identity and attribute requests, prepare relying-party registration, and turn the result into a product backlog. That is enough to avoid panic later and start capturing the business upside of lower-friction, privacy-preserving digital identity.

Ready to apply the checklist?