What the EU Digital Identity Wallet means for public services

The European Digital Identity Wallet is coming to every EU Member State. Regulation (EU) 2024/1183, which revised the eIDAS rules on electronic identification, requires each Member State to provide at least one wallet within 24 months of the implementing acts on its technical specifications entering into force.¹ The Commission adopted the first five of those acts on 28 November 2024 and described the aim as Member States releasing wallets by the end of 2026.²

Most coverage asks what the wallet means for citizens. This piece asks what it means for the public bodies on the other side of the screen. The legal detail is in the guide to digital identity and eIDAS.

Job one: accept it at the front door

The rule is simple to state. Where a Member State requires electronic identification to access an online public service, that service must also accept European Digital Identity Wallets.¹ For any service that already asks people to sign in with a national eID, the wallet becomes another accepted route.

A body using the wallet as a relying party must register, so the wallet can show the user who is asking for their data.¹ In practice that means working out which of your services require identification today, who owns their sign-in, and how a wallet login will be matched to your own records.

Matching is where most of the work sits. A wallet must be issued under an electronic identification scheme at assurance level high, so the service can be confident about who has signed in.¹ It still has to connect that person to the right record in its own systems, and that depends on the identifiers and data quality it already has. A service that struggles to match people who sign in with a national eID today will struggle with the wallet too.

Two other rules shape the design. Using a wallet is voluntary, and people who don’t use one must not be restricted or disadvantaged in reaching public or private services, which must stay available through other means.¹ The wallet adds a channel; it doesn’t replace the others.

Job two: feed it from your registers

A wallet holds two kinds of data: person identification data, which establishes who someone is, and electronic attestations of attributes, which vouch for something about them, such as a diploma, a licence or a birth certificate.¹

That second category is where many public bodies come in. The Regulation lists attributes that Member States must make verifiable against authentic public sources at the user’s request, including address, age, nationality, educational and professional qualifications, public permits and licences, and company data.¹ Those sources are, in most countries, the base registries that public bodies already run.

An attestation is only as reliable as the record behind it. If a licence register has duplicates, gaps or out-of-date entries, the wallet will make those problems more visible, not less, because the attestation will travel further than the record ever did.

Job three: ask for less

The wallet is designed around selective disclosure: users must be able to share only the data a service needs rather than a whole credential.¹ That gives public bodies a reason to revisit their forms.

The same question applies to every form field: what decision does it support, and could a yes-or-no attestation answer it instead? That is the once-only principle and the “relevant only” idea working together.

Privacy features that change the conversation

Several design rules are meant to stop the wallet becoming a tracking tool. The wallet can generate pseudonyms, issuers of attestations must not receive information about how those attestations are used, and a dashboard lets the user see every transaction, ask a relying party to erase their data and report a suspicious request to their data protection authority.¹

For public bodies, that means expecting people to see exactly what was requested and by whom. Requests that look excessive will be noticed.

A short preparation checklist

1. List the online services that require electronic identification today.
2. Name an owner for wallet acceptance and relying-party registration.
3. Identify which of your registers hold attributes that may be issued as attestations.
4. Review data quality in those registers before attestations go live.
5. Go through each form and mark fields that could become a yes-or-no attestation.
6. Keep non-wallet routes open and tested, including for people who need help.