EUDI Wallet 2026: preparing business login and verification

01

Facts: what is due by the end of 2026?

Regulation (EU) 2024/1183, often called eIDAS 2.0, established the European Digital Identity Framework. The European Commission states that by the end of 2026 each Member State must provide at least one compliant EUDI Wallet to citizens, residents and businesses. Wallets are intended to use common technical rules and be mutually recognised across the EU.

A wallet can be used to authenticate, store and share digital documents and create legally binding electronic signatures. Official pilots cover use cases including bank-account opening, SIM registration, contract signing, payments, mobile driving licences, professional qualifications and proof that a person represents an organisation.

This material was checked on 12 October 2026. It provides general operational and technical information, not individual legal advice. A company’s obligations depend on its size, sector, the legal or contractual basis for strong authentication, its role in the process and sector-specific rules.

02

Facts: wallet availability is not a 2026 duty for every business

The end-of-2026 date primarily concerns Member States making wallets available. The Regulation sets a separate acceptance duty for specified private relying parties that provide services where EU law, national law or contract requires strong online user authentication. Listed areas include transport, postal services, banking, finance, energy, health, education, telecommunications and digital infrastructure.

That duty is to apply no later than 36 months after the relevant implementing acts enter into force and only upon the user’s voluntary request. The Commission describes this phase as acceptance by the relevant private service providers by the end of 2027. Article 5f(2) excludes microenterprises and small enterprises from this specific duty.

This does not prevent a smaller business from adopting the wallet earlier, nor does it create a blanket exclusion from every eIDAS rule. Voluntary integration may be valuable where manual document checks are costly, risky or inconvenient for customers from another Member State.

03

Facts: what is a wallet-relying party?

A wallet-relying party uses a wallet unit to provide a public or private service through digital interaction. A company intending to request data from an EUDI Wallet must register in the Member State where it is established. Registers are designed to make the party’s identity verifiable and reduce service-provider impersonation.

During registration, the party declares its intended wallet use and the data it plans to request. A user should see who is requesting the data and why, and the wallet should allow only the required attributes to be transmitted. The integration should therefore not be designed as a digital copy of a full identity document.

Implementing Regulation (EU) 2024/2980 describes wallet-relying-party registers, their registrars and access certificates used to authenticate the business to the wallet. Registration and operational onboarding also depend on the mechanism implemented by the relevant Member State.

04

Facts: the user controls the scope of shared data

Selective disclosure is a core EUDI principle. A service may need confirmation that a user exceeds an age threshold without receiving the full date of birth, document number and address. The wallet is intended to display the request and enable an informed decision to share.

The Commission emphasises protection against unlawful tracking and profiling, local data storage and visibility of wallet use. A relying party should therefore justify every requested attribute and connect it to a specific process step.

Cryptographic proof of an attribute does not automatically determine every business outcome. The company remains responsible for process rules, permissions, fraud controls, evidence retention and handling the unavailability of a wallet, network or source system.

05

WEBee recommendation: begin with a process and data map

Identify processes where the business currently requests a document, uses a verification payment or extra code, or manually checks an entitlement. For each one, record the legal or operational reason for verification, the user, expected outcome, cost of error and current handling time.

Then replace the document with the minimum attributes. The process should not collect data for possible future use. If a yes-or-no result is sufficient, do not retain the source value. Define retention, access and the evidence required to demonstrate successful verification.

• customer or employee login;
• proof of age, qualification or entitlement;
• verification that a person represents an organisation;
• contract signature or document approval;
• account opening and access recovery;
• a cross-border process requiring recognition of data from another Member State.

06

WEBee recommendation: design the integration as a secure flow

A “Sign in with EUDI Wallet” button is only the beginning. The backend must create an unambiguous request, state its purpose and attributes, verify the response, issuer and relying-party certificate, and bind the result to the correct session. Every request needs a short lifetime and replay protection.

The audit trail should record a transaction identifier, time, outcome, rules version and type of verified attribute without duplicating more personal data than the process needs. Technical failure, user refusal and a missing credential must be distinguished so that the system does not treat each event as a false identity.

• separate authentication from the business decision;
• use transaction state, a nonce and replay protection;
• validate the trusted issuer, signature and credential validity;
• do not place personal data in URLs or error messages;
• design logout, consent withdrawal and lost-device handling;
• maintain an alternative path for outages and people without a wallet.

07

WEBee recommendation: run a six-step pilot

Choose a use case with a clear benefit and limited customer impact. Do not start by replacing every login method. The pilot should cover the positive path as well as refusal to share data, an invalid credential, lost connectivity and returning to an interrupted session.

Test on mobile devices, in browsers and in the app, including accessibility and a wallet issued by another Member State. Measure completion time, abandonment, manual reviews, validation failures and retries. Expand only after comparing the outcome with the current method.

• select one use case and business owner;
• define minimum attributes, purpose and retention;
• confirm the relying-party role and registration path;
• build the integration and safe exception handling;
• run security, accessibility and interoperability tests;
• compare the result with the current method and document the decision.