eIDAS 2.0, Regulation (EU) 2024/1183, amends Regulation (EU) 910/2014 and protects user privacy by giving people direct control over their identity data. The regulation requires that only the minimum necessary information is disclosed in any given interaction. These protections apply to every EU citizen, resident, and business that uses a European Digital Identity Wallet, and they are built into the technical architecture of the system itself.
The sections below unpack the specific privacy rights users gain, how the technology enforces those rights, and what all of this means for organizations building compliant digital services.
What specific privacy rights does eIDAS 2.0 give users?
eIDAS 2.0 gives users the right to control what personal data they share, with whom, and for what purpose. Users can choose which attributes to disclose in any given transaction, keep track of which organizations have accessed their data, and decline to share anything beyond what is strictly necessary for the service they are using. These rights are legal requirements built into the regulation.
In practical terms, this means a user accessing a public service online can share only their name and address, without revealing their date of birth, national ID number, or any other data the service does not need. The same applies to private sector interactions, such as opening a bank account or verifying age for an online platform.
The core privacy rights eIDAS 2.0 establishes for users include:
- Data minimisation: Only the data strictly required for a specific purpose may be requested or processed.
- User approval and control: Users actively choose what to share before any data leaves their wallet, approving each request individually.
- Transparency: Users can see which organizations have requested access to their data and for what reason, through the wallet dashboard.
- Portability: Users can carry their verified identity data across borders and services without re-verifying from scratch.
- Right to refuse: Users can decline data requests that go beyond what is necessary, without losing access to the core service.
These rights represent a significant upgrade from the original eIDAS regulation, which focused mainly on cross-border recognition of national eIDs without addressing personal data control at this level of detail.
How does selective disclosure work in the EUDI Wallet?
Selective disclosure allows a user to share only specific attributes from a credential, rather than the full document. In the EUDI Wallet, this means a user can prove they are over 18 without revealing their exact date of birth, for example by disclosing only the attribute “age over 18”, or confirm their nationality without disclosing their home address. The wallet handles this at a technical level using credential formats such as mdoc and SD-JWT VC, which make partial disclosures verifiable and tamper-evident.
A traditional ID card shows everything at once. A digital wallet credential lets you present only the relevant field, while the receiving party can still verify that the underlying data is authentic and issued by a trusted source.
Selective disclosure of a single attribute such as “age over 18” does not require zero-knowledge proofs. The mdoc and SD-JWT VC formats both support selective disclosure natively, allowing a wallet to present only the specific claim a relying party needs. Zero-knowledge proofs are one possible cryptographic technique for derived predicates, but they are not a required mechanism in the EUDI Wallet architecture.
Verification of a presented credential involves three distinct checks: the verifier confirms the issuer’s signature against the relevant national trusted list, checks the revocation status through the issuer’s status information, and validates the wallet unit attestation to establish that the presenting wallet runs on a certified wallet solution. Only the first of these checks can be performed fully offline.
For organizations, this changes how identity verification needs to be designed. A service can request only the specific attributes it needs and receive a cryptographically verified response, which reduces data liability and simplifies compliance. Under CIR (EU) 2025/848, adopted on 6 May 2025, relying parties must register with the national authority of their Member State of establishment before requesting wallet data, and must specify per intended use which attributes and attestations they will request. The wallet checks incoming requests against this registered scope.
How does eIDAS 2.0 approach user tracking across services?
eIDAS 2.0 includes deliberate architectural requirements to limit cross-service tracking. The technical specifications for the EUDI Wallet include mechanisms designed to make it harder for different service providers to combine their data to build a profile of a user’s activity. This is a structural design requirement, not merely a policy recommendation.
One of the significant risks with digital identity systems is the potential to create a surveillance infrastructure. If every credential presentation is logged by a central party or a network of service providers, daily behavior becomes visible in ways that paper documents never allowed. The EUDI Wallet architecture addresses this through several technical and governance measures, though it does not eliminate all tracking or profiling risk entirely.
- Pseudonymous presentation: When a user presents credentials to a service, the wallet can generate a session-specific pseudonym. Pseudonyms are generated by the wallet and stored locally. They differ per relying party and are not PID attributes.
- No central logging requirement: The architecture does not require a central registry to track when or where credentials are used. The wallet dashboard is a tool for the user, not a logging facility for the wallet provider.
- Wallet provider restrictions: Wallet providers are explicitly prohibited from collecting data about which services their users interact with.
- Selective attribute disclosure: By sharing only the minimum necessary attributes, users limit the data footprint they leave with each service.
For sectors like financial services or healthcare, where users interact with multiple providers, these measures are especially relevant. They allow organizations to verify identity without creating unnecessary data dependencies or exposure.
What is the relationship between eIDAS 2.0 and GDPR?
eIDAS 2.0 and GDPR work together. GDPR sets the overarching legal framework for how personal data must be handled across the EU, while eIDAS 2.0 defines the technical and regulatory standards for digital identity specifically. Any processing of personal data within an eIDAS 2.0 context, including the use of EUDI Wallets, must comply with GDPR requirements such as lawful basis, purpose limitation, and data subject rights.
In practice, eIDAS 2.0 reinforces many GDPR principles at the technical level. Data minimisation, which is a core GDPR requirement, is built directly into the selective disclosure model of the EUDI Wallet. Privacy by design, another GDPR obligation, is reflected in the wallet’s architecture, which defaults to sharing the least possible data.
Where the two frameworks interact most directly is in the area of user approval. Under GDPR, consent as a lawful basis must be freely given, specific, informed, and unambiguous. It is important to distinguish between a user approving a data request in the wallet and consent as a GDPR lawful basis. A relying party needs its own GDPR lawful basis for processing the data it receives. For KYC purposes, that basis is typically a legal obligation. For health data, an additional condition under Article 9(2) GDPR is required. The EUDI Wallet’s model of explicit, attribute-level approval before any data is shared aligns well with GDPR’s transparency requirements, but the relying party’s lawful basis must be established independently.
Organizations operating in regulated sectors such as healthcare or government should treat eIDAS 2.0 compliance and GDPR compliance as complementary workstreams. Implementing one without considering the other creates gaps that regulators are increasingly likely to scrutinize.
Who is responsible for privacy compliance in an eIDAS 2.0 ecosystem?
Privacy compliance in an eIDAS 2.0 ecosystem is a shared responsibility distributed across several parties. These include wallet providers, credential issuers such as government agencies and qualified trust service providers, and relying parties, the organizations that request and verify credentials. Each party has distinct obligations, and no single actor bears all of the responsibility. The regulation is explicit about this distribution to prevent any one party from becoming a single point of failure or control.
At the European level, the European Commission manages the legal framework and adopts implementing acts that contain the legally binding requirements. EU Member States are responsible for providing or mandating wallet solutions, certifying and notifying those wallets, and supervising actors within their jurisdiction. The European Digital Identity Cooperation Group supports cooperation and cross-border alignment between Member States. National competent authorities and registrars carry out supervisory and registration functions at the national level.
Wallet providers are responsible for ensuring the technical integrity of the wallet, protecting stored credentials, and complying with the prohibition on tracking user activity. They must meet certification requirements set by their Member State and adhere to the technical elaboration set out in the Architecture and Reference Framework, which supports the implementing acts adopted under the regulation.
Credential issuers, including government agencies issuing Person Identification Data and qualified trust service providers issuing attestations, are responsible for the accuracy of the data they attest to and for issuing credentials in formats that support selective disclosure and privacy-preserving verification. Issuers must also make revocation status available and support re-issuance when a user moves to a new device, since private keys do not leave the secure element and attestations cannot simply be copied.
Relying parties, meaning the organizations that ask users to present credentials, are responsible for requesting only the data they genuinely need, having a lawful basis for processing it under GDPR, and not retaining it beyond what is necessary. Under CIR (EU) 2025/848, a relying party must register with the national authority of its Member State of establishment before requesting wallet data, specifying per intended use which attributes and attestations it will request. A vendor that processes wallet data on behalf of a client does not thereby become the relying party: the registration obligation rests with the organization that delivers the service to the end user. This is where many organizations will face the most immediate compliance work, since it requires redesigning onboarding flows, data collection forms, and internal processing logic.
For organizations still mapping out their responsibilities, working with partners who understand both the regulatory and technical dimensions of the eIDAS 2.0 ecosystem is a practical starting point. The TrustTech approach to digital identity implementation is built around exactly this kind of multi-party accountability.
How the ID Connector supports eIDAS 2.0 privacy compliance
Translating eIDAS 2.0’s privacy requirements into working systems requires both technical depth and regulatory understanding. The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
In the context of privacy compliance, the ID Connector addresses several concrete requirements:
- EUDI Wallet integration: Connecting your services to wallet-based identity flows that support selective disclosure and data minimisation by design.
- Verification against trusted lists: Checking issuer signatures against the relevant national trusted lists, which are brought together in the EU List of Trusted Lists, to confirm the authenticity of presented credentials.
- Revocation status checks: Verifying the revocation status of credentials through issuer-provided status information as part of each verification flow.
- Wallet unit attestation validation: Confirming that the presenting wallet runs on a certified wallet solution, as required for a complete verification.
- Registered attribute scope enforcement: Ensuring that data requests stay within the scope registered per intended use under CIR (EU) 2025/848.
- Reusable identity flows: Enabling users to present verified identity data across your services, reducing friction while maintaining compliance.
Organizations in financial services, healthcare, pharma, and government face specific identity and trust requirements under eIDAS 2.0. The ID Connector is built to meet those requirements in production environments. Get in touch with TrustTech to discuss what eIDAS 2.0 privacy compliance means for your organization.