EUDI Wallet privacy: selective disclosure and unlinkability

The EU Digital Identity Wallet is built around data minimisation: you carry your credentials yourself and choose what to reveal. That is a real improvement over uploading passport scans to every service. But privacy in a wallet is not automatic. It depends on three things, namely what the credential formats allow, what the protocols leak, and what services are permitted to ask for. This page explains each and where open questions remain, as of October 2026.

What the law requires

Regulation (EU) 2024/1183 (see eIDAS 2.0 explained) sets several privacy rules for wallets. In short:

• You control which data you share, and each presentation needs your approval.
• A dashboard lets you see the transactions you have made and report unlawful requests.
• You may use pseudonyms where identification is not legally required.
• Wallet providers must not collect information about your use of the wallet beyond what is necessary, and must keep wallet data logically separate from other services they offer.
• Where identification is not necessary, the design should prevent tracking and linking of your transactions.

Read the text on EUR-Lex. The detail of how this is achieved sits in implementing acts and the Architecture and Reference Framework.

Selective disclosure

Selective disclosure is the most mature privacy feature. With SD-JWT VC, the issuer signs a credential in which every claim can be hidden or revealed individually. You decide which claims to reveal for each presentation. The mdoc format used for mobile driving licences achieves the same by letting you release individual data elements.

A good example is age checks: instead of a birth date, the service receives a signed ‘over 18’ attribute. See our guide to EU age verification.

What selective disclosure does not do by itself is stop a service from asking for too much. A bank may legitimately need your address. A shop usually does not.

Where unlinkability gets difficult

Even if you reveal only one attribute, other parts of a credential can act as identifiers. The issuer’s signature, the public key bound to your device and revocation status checks can be the same across presentations. If a verifier or the issuer sees the same value twice, it can link the two events. If issuers and verifiers collude, the combined view can reveal where and when you used a credential.

The Spanish data protection authority AEPD discusses these risks in a blog series on eIDAS 2 and the GDPR. It notes that signature-based formats such as SD-JWT and mdoc can allow tracking, and recommends stronger cryptographic techniques such as zero-knowledge proofs and anonymous credentials.

The current approach to mitigation is pragmatic:

1. Batch issuance. The wallet obtains many copies of a credential, each with different keys and salts, and uses each only once or for a short time.
2. Short-lived credentials. Reducing the window in which a value could be correlated.
3. Privacy-friendly revocation. Designs that avoid revealing per-credential lookups.
4. Zero-knowledge proofs later. Standards for these are still being developed, and some national wallets, such as Germany’s, have said they will follow after launch.

These workarounds have costs for issuers and for wallet storage. They are good enough for many cases, but they are not a mathematically complete answer to linkability.

Over-asking and relying-party registration

A service that wants to read data from your wallet must register as a relying party in its member state and describe what it will request and why. The wallet can then show you who is asking. The aim is to stop services from asking for more than the law or their purpose permits.

Critics, including civil society organisations, note that the registration is mostly an administrative control. The wallet can display a request, and the national authority can sanction abuse, but the system cannot technically prevent a registered service from asking for an attribute it did not declare in every case. In practice, you and the data protection authorities remain part of the control loop. For background on the role, see relying party.

What the wallet provider can and cannot see

By design, the issuing authority and the wallet provider are separate from the service you present to. The wallet provider operates the app and may check device integrity, but it should not see the content of your presentations. Wallet providers also must not combine wallet data with data from their other services. Whether a specific national implementation meets this depends on its design, so favour wallets that publish architecture documents, source code and independent audit results.

Compared with today’s practice

Today, proving your age or address often means uploading a photo of your ID card, sometimes with a selfie, to a company you have never heard of. That copy can then sit in a database for years and leak. A wallet presentation replaces the copy with a signed claim that is checked on the spot. The service need not store your document, and for age checks it need not learn your birth date. Even with the open questions above, this is a clear gain, especially for services that only need a yes or no.

Data protection law around the wallet

The GDPR continues to apply to wallet providers, issuers and verifiers. Each of them is responsible for its own processing, needs a lawful basis and must respect data minimisation. National data protection authorities supervise this, alongside the bodies that supervise the wallet framework. If you think a service asked for too much, you can complain to your data protection authority.

Practical privacy habits

• Read the request. Before approving, check the service name and the attributes listed. If you do not understand why it asks, decline.
• Prefer the smallest proof. Use ‘over 18’ rather than a full ID where offered.
• Use pseudonyms where the wallet and service support them.
• Check the dashboard. Review past transactions from time to time.
• Complain when needed. Report a suspicious or excessive request to the registering authority and your data protection authority.
• Keep your device healthy. Wallet privacy cannot compensate for malware on your phone. See wallet security.

Bottom line

The EU wallet is a better privacy baseline than most existing identity systems because it makes minimal disclosure the default pattern, not an optional extra. But the strongest guarantees, full unlinkability and technical limits on over-asking, are still being worked on. Treat the first generation of wallets as a considerable step forward, not a finished privacy solution. For the broader introduction, start with the EU Digital Identity Wallet explained.