eIDAS2, the EUDI wallet and the GDPR (VI)

21 September 2026

Several key data protection challenges are associated with the eIDAS 2 regulation, particularly regarding the implementation of EUDI wallets. These challenges arise from reconciling functionality, privacy and security.

Photo by Sasun Bughdaryan on Unsplash.

The following post analyses how different detecting, data breach and data disclosure threats could materialise in EUDI wallets. The following questions arise in the new eIDAS2 ecosystem:

Even if I do not show my personal details, can my Wallet provider or an external observer tell that I am taking a specific action or holding a specific credential just by watching or observing?
Where are my face scans, identity documents, and transaction records actually stored, and what happens to my digital identity if a provider participating in the EUDI Wallet ecosystem gets hacked? Could a malicious actor steal my identity or clone my wallet?
Can a provider or an intermediary collect more of my personal data than necessary through my wallet, keep my data indefinitely, or pass it on to third parties without my explicit knowledge?

Question 1 is related to the Detecting threat. This threat involves deducing the existence of data items or a data subject’s actions through observation, even when the actual content or underlying data values remain hidden. In the EUDI Wallet ecosystem, this threat arises when an observer such as a Relying Party, an intermediary, a Wallet Provider, or a network eavesdropper detects user characteristics or transactional behaviours by monitoring component reactions, network traffic, or API outputs.

Suppose a browser or operating system’s API, such as the Digital Credentials API, behaves differently based on whether a wallet is installed, whether a specific credential is present, or whether a user denies permission to share a credential. The Relying Party can easily detect this. For example, a malicious web tracker could call the API to detect if the citizen possesses a highly specific credential, such as a medical attestation or a minority status, simply by observing API error messages, timing variances, or device-state changes.

Another scenario is when a sensitive attestation is protected by an Embedded Disclosure Policy (such as restricting sharing to authorised Relying Parties only). If a user navigates to an unauthorised Relying Party, the wallet evaluates this policy and denies the request. If the wallet returns a specific “access denied” error to the Relying Party rather than a generic “credential not found” error, the Relying Party can immediately detect that the user does possess the sensitive attestation, even though the presentation was blocked.

Revocation checks and “phoning home” protocols (communication patterns in which a client device, application, or credential periodically or event-driven contacts a remote server controlled by its issuer, vendor, or operator to transmit data and/or receive instructions) could also help different actors materialise detecting threats, alongside an obvious method such as partial or total access to transaction logs.

The Data Breach threat involves the destruction, loss, alteration, unauthorised disclosure, or access to personal data through mistakes, malicious insiders, or cyberattacks, and it is related to question 2. While a data breach is a generic data protection threat, its materialisation within the EUDI Wallet ecosystem may have a catastrophic impact because of the high sensitivity of the data handled, including legal identity (PID), qualified attributes (QEAAs), biometric onboarding data, and lifelong transaction histories.

Unattended remote identity proofing often involves capturing high-resolution facial images, live video streams, and document scans. If Identity Proofing Service Providers (IPSPs) or Trust Service Providers (TSPs) retain these raw biometric streams in centralised databases, they create massive “honeypots”. A cyberattack or malicious insider breach of this kind of database would create a permanent risk of Identity Theft and biometric spoofing.

But this is only one example. As explained in our previous posts, current default attestation formats in the ARF (ISO mDL and SD-JWT) rely on salted-attribute hashes and static issuer signatures. If multiple Relying Parties suffer data breaches, an attacker (or colluding actors) possessing leaked presentation logs can compare static cryptographic fingerprints (salt values, public keys, or signatures) to link user transactions across different services ex-post. This retroactively converts a localised data breach into system-wide surveillance and profiling.

Furthermore, under eIDAS2 and CIR 2024/2979, Wallet Units must enable users to export a Migration Object containing attestation metadata and transaction logs to cloud storage for device recovery. If this Migration Object or remote transaction logs are stored unencrypted or with weak provider-managed keys, a breach at the cloud storage provider could expose the user’s complete history of digital interactions and service usage. The ways a data breach threat can materialise are virtually limitless, and the impact in this context is almost always severe.

Finally, concerning question 3, we must consider Data Disclosure threats, which involve excessive collection, storage, processing, or sharing/transfer of personal data. Unlike a data breach (which often involves unauthorised or malicious access), data disclosure can occur through authorised, legitimate, or routine operations when design decisions result in over-identification, over-sharing, function creep, or unjustified data retention, for example.

RPs may attempt “data hoarding” or “just-in-case” attribute requests. Suppose a Relying Party requests a user’s full PID (full legal name, date of birth, national identification number, address, or biometric portrait) for transactions where only a single attribute or boolean proof (“over 18” or “resident of municipality X”) is functionally required. In addition, attestation data or identity attributes disclosed for a specific, initial transaction being repurposed, cross-referenced with external commercial databases, or shared with third parties (such as advertising networks) without a valid legal basis or explicit user authorisation.

Other actors can also materialise this threat. For example, Wallet Providers or Attestation Issuers may collect usage metrics, observe transaction details, or track when and where a user presents their credentials. Or Identity Proofing Service Providers (IPSPs) collecting excessive supplementary evidence (for example, full bank statements, utility records, or unneeded document attributes) or indefinitely retaining raw video recordings, high-resolution document scans, and facial images during unattended or attended remote identity proofing (governed by ETSI TS 119 461).

As it has been introduced in previous posts in this series, addressing these threats requires different measures and safeguards, combining a data protection-by-design-and-by-default approach with technical scope enforcement. For example, detecting threats are countered by enforcing strict unobservability through local-only transaction log storage on the user’s device, asynchronous revocation checks that prevent issuers from tracking live presentations, and symmetric API and error responses that prevent observers from detecting different data subjects’ attributes. Data breach threats are addressed by eliminating centralised “honeypots”, such as biometric databases, through local processing, immediately deleting raw onboarding video streams and facial scans upon identity binding, maintaining logical and physical segregation of wallet data from other provider services, enforcing client-side encrypted backups, and deploying Zero-Knowledge Proofs (ZKP) or anonymous credentials to ensure that leaked presentation logs cannot be cross-linked across parties. Finally, data disclosure threats are mitigated by enforcing attribute-level selective disclosure, technically restricting Relying Parties to their registered scope via machine-readable Wallet-Relying Party Registration Certificates (WRPRC), enforcing pseudonymity by default whenever legal identification is not mandated by law, and restricting onboarding data collection strictly to the minimum essential attributes. A future post will analyse and illustrate the remaining data protection threats.