Under eIDAS 2.0, user consent is built on the principle that individuals must be in full control of what personal data they share, with whom, and when. The regulation requires that data sharing through the European Digital Identity (EUDI) Wallet is always deliberate and informed, meaning users actively choose what to disclose rather than having it shared automatically. This article walks through the most important questions organisations need to understand about eIDAS 2.0 consent rules.

How does eIDAS 2.0 define user consent for data sharing?

Under eIDAS 2.0, user consent for data sharing means that individuals must explicitly and actively agree to share specific identity attributes before any data is transmitted. Consent must be informed, granular, and freely given. Users are never required to share more information than is strictly necessary for a given interaction, and sharing cannot happen without a clear, deliberate action from the user.

This definition is embedded in the architecture of the EUDI Wallet itself. The wallet is designed so that every data disclosure requires a conscious decision by the user. For example, when a relying party requests identity attributes, the wallet presents the user with a clear overview of exactly what is being requested and why. The user can then choose to approve, modify, or decline the request.

This approach is sometimes called selective disclosure. Rather than sharing an entire identity document, a user can share only the specific attributes that are needed. Booking an appointment at a healthcare provider might only require a name and date of birth, not a full national identity record. The regulation is explicit that anything beyond what is necessary should not be shared.

What specific rights do users have under eIDAS 2.0 consent rules?

eIDAS 2.0 gives users a clear set of rights when it comes to their identity data and how it is shared. These rights are designed to give individuals genuine control, not just a checkbox to tick. Under the regulation, users have the right to:

• Choose which attributes to share and which to withhold
• Decide on a per-interaction basis, rather than giving blanket permission
• Access a log of what data has been shared, with whom, and when
• Withdraw consent and stop sharing data at any point
• Use digital services without being forced to share unnecessary personal data
• Access the EUDI Wallet and digital identity services without going through private platforms that collect additional data

These rights apply across both public and private sector interactions. Whether a user is accessing a government service, opening a bank account, or verifying their age for an online platform, the same principles apply. The regulation is designed to prevent situations where users feel pressured to over-share in order to access a service.

Are organisations required to obtain explicit consent every time?

In most cases, yes. eIDAS 2.0 requires that consent is obtained at the point of each data sharing interaction, not stored as a general permission that covers all future requests. Each time a relying party requests identity attributes through the EUDI Wallet, the user must actively confirm what they are willing to share in that specific context.

There is an important distinction here between authentication and data sharing. A user may set up a trusted relationship with a service provider, but that does not give the provider ongoing access to the user’s identity data. Each new request still requires user action. This is fundamentally different from how many current digital identity systems work, where a one-time consent often leads to persistent data access.

Organisations operating in financial services or other regulated industries need to pay close attention here. Existing onboarding flows that rely on broad or standing consent may need to be redesigned to align with the per-interaction model that eIDAS 2.0 introduces.

What happens if a user refuses or withdraws consent?

If a user refuses or withdraws consent under eIDAS 2.0, organisations are not permitted to deny access to a service solely on that basis, provided the requested data is not strictly necessary for the service in question. Users cannot be penalised for exercising their right to data minimisation. If an organisation requests more data than is genuinely required, the user has the right to decline without losing access.

Withdrawal of consent means that any ongoing data sharing arrangement must stop immediately. Organisations must have processes in place to honour withdrawal requests without delay. This has practical implications for systems that store or reuse identity data, since any data shared under a consent that has since been withdrawn should no longer be actively used.

For organisations in healthcare or government services, where identity verification is often a legal requirement, there is more nuance. In these cases, certain data may be required by law, which creates a different legal basis for processing than consent. However, even in these contexts, data minimisation principles still apply.

How do eIDAS 2.0 consent rules interact with GDPR?

eIDAS 2.0 consent rules and GDPR operate alongside each other and are designed to be complementary. GDPR sets the overarching framework for personal data processing in the EU, including the conditions under which consent is valid. eIDAS 2.0 builds on these foundations by embedding data minimisation and user control directly into the technical architecture of the EUDI Wallet.

In practice, this means that when a user shares identity attributes through the EUDI Wallet, the organisation receiving that data must still comply with GDPR obligations. This includes having a lawful basis for processing, respecting retention limits, and honouring data subject rights such as access and erasure.

One area where the two frameworks interact closely is the concept of purpose limitation. Under GDPR, data collected for one purpose cannot be freely reused for another. eIDAS 2.0 reinforces this by requiring that consent is specific to each interaction and each stated purpose. An organisation cannot use identity data shared during onboarding for a different process later without fresh consent or another lawful basis.

Organisations should treat eIDAS 2.0 compliance and GDPR compliance as connected workstreams rather than separate projects. A structured implementation approach that maps data flows, consent mechanisms, and legal bases across both frameworks will reduce duplication and close compliance gaps more efficiently.

What should organisations do now to prepare for these consent requirements?

Organisations should start by auditing their current identity and data sharing processes to understand where they do and do not align with eIDAS 2.0 consent principles. The key questions to ask are: what data are we currently requesting, do we actually need all of it, and how are we obtaining and recording consent today?

From there, a practical preparation plan should include the following steps:

1. Map your data requests: Identify every point in your customer or user journey where identity data is collected or shared, and assess whether each data point is strictly necessary.
2. Review consent mechanisms: Check whether your current consent flows are granular, per-interaction, and clearly documented in line with both eIDAS 2.0 and GDPR requirements.
3. Prepare for EUDI Wallet integration: Understand how relying party registration works under eIDAS 2.0 and what technical requirements apply to organisations that want to accept wallet-based identity credentials.
4. Update internal policies: Ensure your data protection policies, privacy notices, and internal procedures reflect the new consent model and the rights users have under eIDAS 2.0.
5. Train relevant teams: Compliance, legal, IT, and product teams all need to understand the implications of eIDAS 2.0 consent rules for their specific responsibilities.

Organisations in sectors such as government services or science and education may also want to explore the outcomes of the EU large-scale pilot programmes, which have been testing real-world EUDI Wallet use cases and generating practical insights that can inform implementation planning. More background and guidance is available through TrustTech’s resources.

How TrustTech helps with eIDAS 2.0 consent compliance

Navigating eIDAS 2.0 consent requirements is not just a legal exercise. It requires the right technical infrastructure, clear processes, and a platform that is built to support user-controlled data sharing from the ground up. That is exactly where TrustTech comes in.

TrustTech helps organisations across regulated sectors prepare for and implement eIDAS 2.0 in a way that is both compliant and practical. Specifically, TrustTech supports:

• Wallet-ready identity infrastructure that supports selective disclosure and per-interaction consent flows
• Reusable, verifiable credentials that reduce friction while keeping users in control of what they share
• Integration with the EUDI Wallet ecosystem, so your organisation is ready to accept wallet-based identity attributes as a relying party
• Compliance alignment across eIDAS 2.0 and GDPR, helping you close gaps without duplicating effort
• Sector-specific expertise in finance, healthcare, government, and pharmaceuticals, where consent and data sharing requirements are most complex

Whether you are just starting to assess your readiness or already working toward implementation, TrustTech provides the expertise and technology to make eIDAS 2.0 consent compliance manageable. Get in touch with TrustTech to discuss how we can support your organisation.