Why is selective disclosure a game changer for eIDAS 2.0 compliance?

Selective disclosure is a core requirement of eIDAS 2.0 compliance. It allows users to share only the specific attributes an organisation needs for a given transaction, without handing over a full identity document. This directly satisfies the data minimisation requirements built into eIDAS 2.0, Regulation (EU) 2024/1183, which amends Regulation (EU) 910/2014, and into the European Digital Identity Wallet framework. The sections below explain how selective disclosure works, what the regulation actually requires, and how your organisation can prepare.

How does selective disclosure actually work in verifiable credentials?

Selective disclosure in verifiable credentials means a user can present a single attribute from a credential, such as proof of being over 18, without revealing their full name, date of birth, or any other data stored in that credential. The credential is cryptographically signed by a trusted issuer, so the receiving organisation can verify the claim is genuine without seeing the underlying data.

Think of it like a driving licence that only shows the age check field when you buy something online, while keeping your home address and licence number completely hidden. The technical mechanisms that make this possible include SD-JWT VC and the mdoc format, both of which allow individual fields within a credential to be revealed or withheld independently.

The cryptographic proof still holds even when only part of the credential is shared. The verifier receives a tamper-evident confirmation of the specific claim, and nothing more. No excess data, no unnecessary profiling.

What does eIDAS 2.0 require regarding data minimisation?

eIDAS 2.0 requires that the European Digital Identity Wallet enables users to share only the data strictly necessary for a given transaction, a principle known as data minimisation. This is a core design requirement built into the regulation. The legally binding requirements are set out in the implementing acts adopted by the European Commission. The Architecture and Reference Framework provides the technical elaboration of those requirements and governs how EUDI Wallet implementations give effect to them in practice.

The regulation explicitly states that users must be able to choose what they share and with whom, and that data not necessary for a service must not be shared. This aligns closely with the GDPR data minimisation principle, and eIDAS 2.0 goes further by making selective disclosure a technical requirement embedded in the wallet architecture, not only a policy obligation.

For organisations receiving identity data, this has direct compliance implications. If your service requests more attributes than you can justify, you are failing eIDAS 2.0 requirements and potentially creating GDPR exposure as well. Compliance means designing your verification flows around what you genuinely need, not what is convenient to collect.

Why can’t traditional identity systems meet selective disclosure requirements?

Traditional identity systems were not built for selective disclosure because they rely on sharing entire documents or static data sets. When a user uploads a passport scan or provides a PDF of their diploma, every piece of information on that document is transferred, regardless of how little the receiving party actually needs.

These legacy approaches create several structural problems:

• Over-sharing by default: A passport scan reveals nationality, document number, expiry date, and facial image, even if only age verification is required.
• No cryptographic proof: A scanned or photographed document cannot be verified as authentic without manual review or third-party checks.
• No user control: Once a document is shared, the user has no technical mechanism to limit what the recipient does with it.
• No interoperability: Each organisation builds its own verification process from scratch, forcing users to re-prove themselves repeatedly.

eIDAS 2.0 and the EUDI Wallet framework were specifically designed to replace this fragmented model. The regulation recognises that asking users to start from scratch with every new organisation is both inefficient and privacy-invasive. Selective disclosure, backed by verifiable credentials, makes the reuse of identity data both secure and privacy-respecting in a way that document uploads cannot achieve.

Which EUDI Wallet credential formats support selective disclosure?

The two primary credential formats supported in the EUDI Wallet ecosystem that enable selective disclosure are SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential) and mdoc, based on ISO/IEC 18013-5 for proximity presentation and ISO/IEC TS 18013-7 for online presentation, the standard originally developed for mobile driving licences. Both formats are referenced in the Architecture and Reference Framework for the EUDI Wallet.

SD-JWT VC

SD-JWT VC extends the widely used JWT format by allowing individual claims within a credential to be selectively disclosed. The issuer signs the full credential, but each attribute is individually hashed. The holder can then reveal specific hashes to a verifier without exposing the rest. This format is well-suited for web-based and app-based interactions and is the primary format for most EUDI Wallet use cases beyond driving licences. Credential issuance uses OID4VCI and presentation uses OID4VP.

mdoc

The mdoc format was originally developed for mobile driving licences and is now being extended to other document types within the EUDI Wallet. It supports selective disclosure at the field level and is designed for both online and proximity-based interactions, such as presenting your driving licence at the roadside or your age credential at a point of sale. The mdoc format is particularly relevant for regulated sectors such as transport and government services.

Organisations building EUDI Wallet integrations need to ensure their verification infrastructure can process both formats, as the wallet ecosystem will see both in active use across different credential types and member states. The High Assurance Interoperability Profile (HAIP) sets out the interoperability requirements that implementations must meet.

How verification works with selectively disclosed credentials

Verifying a selectively disclosed credential involves three distinct checks, not a single cryptographic step.

1. Issuer signature verification: The verifier checks the issuer’s signature against the relevant national trusted list. National trusted lists are brought together in the EU List of Trusted Lists (LOTL). This check can be performed fully offline.
2. Revocation status check: The verifier checks the revocation status of the credential using status information provided by the issuer. This step requires a connection to the issuer’s status endpoint and cannot be performed fully offline.
3. Wallet Unit Attestation check: The verifier checks the Wallet Unit Attestation to confirm that the presenting wallet instance is running on a certified wallet solution. This step also requires connectivity.

Because two of these three checks require connectivity, describing credential verification as fully offline or as requiring no contact with the issuer is not accurate without qualification.

How should organisations prepare their systems for selective disclosure?

Organisations should prepare for selective disclosure by auditing the identity data they currently collect, mapping it to what they genuinely need per use case, and then redesigning their verification flows to request only those specific attributes. This is both a technical and a governance exercise.

A practical preparation approach follows these steps:

1. Map your data requirements per use case: For each service or transaction, define the minimum set of attributes needed. Age verification, professional qualification, and identity confirmation each require different data points.
2. Review your current identity infrastructure: Identify where your systems rely on full document transfers or broad data collection, and flag these as areas for redesign.
3. Update your technical stack for verifiable credential processing: Ensure your systems can receive, parse, and verify SD-JWT VC and mdoc credentials from EUDI Wallets, including the three verification checks described above.
4. Register as a relying party: Under CIR (EU) 2025/848, adopted on 6 May 2025, organisations must register with the national authority of their member state of establishment before requesting wallet data. Registration covers the intended use and the specific attributes and attestations your service will request. The wallet checks incoming requests against this registered scope.
5. Align with your compliance and legal teams: Data minimisation under eIDAS 2.0 and GDPR must be reflected in your privacy policies, data processing agreements, and internal governance. Your organisation needs its own GDPR legal basis for processing the attributes you receive. Wallet approval by the user is a separate step from consent as a GDPR legal basis.
6. Test with the EUDI Wallet reference implementation: The European Commission has made a reference wallet implementation publicly available. Use it to validate your integration ahead of the key deadlines. Public sector bodies and organisations providing services for which electronic identification is required must accept notified EUDI Wallets by 24 December 2026. For relevant regulated private sector organisations, the acceptance obligation under Article 5f of eIDAS 2.0 applies from 24 December 2027. Micro and small enterprises, defined as organisations with fewer than 50 employees and an annual turnover or balance sheet total not exceeding 10 million euros, are exempt from the private sector obligation. Do not wait for a single European go-live moment: begin preparing now.

It is also worth understanding how governance responsibilities are distributed across the ecosystem. The European Commission manages the legal framework and adopts implementing acts. EU Member States provide or mandate wallet solutions, certify and notify them, and supervise actors within their jurisdiction. The European Digital Identity Cooperation Group supports cooperation and cross-border alignment. National competent authorities, wallet providers, issuers of Person Identification Data and attestations, qualified trust service providers, and relying parties each carry distinct responsibilities within this shared governance structure. For relying parties, registration is governed by CIR (EU) 2025/848 and connects to the applicable national registration framework. Sector-specific legislation continues to apply alongside eIDAS 2.0.

Organisations in regulated sectors such as financial services, healthcare, and government face the most immediate pressure to adapt, as their existing compliance frameworks already intersect with identity verification requirements under AML, KYC, and data protection rules. Getting selective disclosure right now means building a foundation that supports multiple regulatory obligations simultaneously.

How the ID Connector supports selective disclosure and eIDAS 2.0 compliance

Preparing for selective disclosure requires aligning your identity infrastructure, compliance frameworks, and user experience around a new set of standards. 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.

For organisations working through selective disclosure requirements, the ID Connector specifically handles:

• Verifiable credential flows supporting SD-JWT VC and mdoc formats, ready for EUDI Wallet interactions
• Trust management and verification against national trusted lists, including issuer signature verification, revocation status checks, and Wallet Unit Attestation validation
• Registered attribute scope enforcement, so that credential requests stay within the scope your organisation has registered under CIR (EU) 2025/848
• Reusable, wallet-ready digital identity, enabling users to present verified attributes across multiple interactions without re-uploading documents
• Qualified signing via a connected QTSP, connecting identification, attestation, and signing into one auditable process built on European digital identity standards
• Reduced onboarding friction while meeting the assurance levels required by regulation

Organisations in financial services, healthcare, pharma, and government can explore the ID Connector on the TrustTech solutions page or contact the TrustTech team to discuss what selective disclosure means for your specific verification flows.