Relying parties under eIDAS 2.0 must register with a national authority in their EU Member State before they can request identity data from a European Digital Identity Wallet. This registration requirement is new and mandatory. It applies to any organization that wants to accept and verify attributes shared by wallet holders. The sections below walk through who qualifies, how registration works, what data you can request, and what happens if you skip the process.

Who qualifies as a relying party under eIDAS 2.0?

A relying party under eIDAS 2.0 is any organization, public or private, that requests and relies on identity attributes or attestations from a European Digital Identity Wallet to deliver a service. If your organization asks a user to prove their identity, age, qualifications, or any other personal attribute using an EUDI Wallet, you are a relying party.

This covers an enormous range of organizations. Banks verifying customer identity during onboarding, hospitals checking patient credentials, government portals granting access to public services, insurers confirming policyholder data, and employers verifying professional qualifications all fall into this category. In practice, any organization operating in a regulated sector that handles identity verification should assume it will qualify as a relying party.

The definition is deliberately broad. eIDAS 2.0 does not limit relying party status to large enterprises or specific industries. What matters is whether your service requests verified data from a wallet. If it does, registration applies to you.

Why do relying parties need to register under eIDAS 2.0?

Relying parties must register because eIDAS 2.0 requires it as a condition for receiving identity data from EUDI Wallets. Registration creates accountability and transparency in the ecosystem. Without a verified register of who is requesting data, users have no reliable way to know whether a service requesting their personal information is legitimate.

The registration requirement serves several important purposes. It ensures that wallet holders can trust the parties they share data with. It gives national supervisory authorities oversight of who operates within the identity ecosystem. It also creates a layer of protection against fraudulent or unauthorized data requests.

From a compliance perspective, the obligation is clear. The Commission Implementing Regulation regarding registration of Wallet Relying Parties is one of the adopted implementing acts under eIDAS 2.0. This means the registration framework is not a proposal or a guideline. It is binding law that organizations must follow before they can interact with EUDI Wallets in any meaningful way. Organizations in financial services and other regulated industries should treat this as a hard compliance deadline, not a future consideration.

How does the relying party registration process work?

Relying party registration under eIDAS 2.0 requires organizations to submit a registration to a designated national authority in the Member State where they are established. The authority verifies the registration, and once approved, the organization is listed in a national register that EUDI Wallet solutions can query to confirm the legitimacy of data requests.

The process broadly involves the following steps:

1. Identify the competent authority in your Member State responsible for managing relying party registrations.
2. Prepare your registration information, including your organization’s identity, the types of attributes you intend to request, and the purposes for which you will use them.
3. Submit your registration through the national process defined by your Member State’s implementation of the implementing regulation.
4. Receive confirmation and ensure your registration details are correctly reflected in the national register.
5. Maintain your registration by keeping it up to date when your data requests or use cases change.

One important nuance is that registration is not a one-time formality. If your organization changes the types of attributes it requests or expands its use cases, the registration must be updated accordingly. The ecosystem is designed so that wallet apps can automatically verify whether a relying party is registered and whether the data being requested matches what was declared at registration. Any mismatch can result in the wallet refusing to share data with your service.

What attributes can a relying party request from the EUDI Wallet?

Relying parties can only request attributes that are directly necessary for the specific service they provide. eIDAS 2.0 enforces a strict data minimization principle. You cannot request more data than your declared purpose requires, and your registration must specify which attributes you intend to use and why.

EUDI Wallets can store and share a wide range of verified attributes, including:

• Person Identification Data (PID), such as name, date of birth, and nationality
• Electronic Attestations of Attributes (EAA), such as professional qualifications, diplomas, or employment status
• Qualified Electronic Attestations of Attributes (QEAA), which carry a higher level of assurance and are issued by qualified trust service providers
• Sector-specific credentials, such as mobile driving licenses, health insurance data, or age verification

The key constraint is that your registration defines what you are permitted to request. A bank registered to request PID for KYC purposes cannot start requesting professional qualifications without updating its registration. This makes the registration process a genuine governance exercise, not just an administrative checkbox. Organizations should think carefully about their full range of use cases before submitting their initial registration.

What are the consequences of non-compliance with registration requirements?

Organizations that request data from EUDI Wallets without completing relying party registration are operating outside the legal framework established by eIDAS 2.0. In practice, wallet solutions are required to verify registration status before sharing any data, so unregistered parties will simply be blocked from receiving wallet attributes. Beyond the technical barrier, there are real legal and reputational risks.

Non-compliance with eIDAS 2.0 registration requirements can result in enforcement action by national supervisory authorities. Depending on the Member State, this could include fines, suspension of the right to request wallet data, or other regulatory sanctions. For organizations in sectors like healthcare or government, where identity verification is tied to regulated processes, the inability to accept wallet data could also mean disruption to core services.

There is also a trust dimension. The entire value of the EUDI Wallet ecosystem depends on users being able to trust the parties they share data with. An organization that attempts to operate outside the registration framework damages not only its own compliance standing but also user confidence in digital identity more broadly.

How should organizations prepare for relying party registration now?

Organizations should start preparing for relying party registration immediately. In 2026, Member States are obligated to make EUDI Wallets available to citizens and businesses. The registration infrastructure is being put in place now, and early preparation gives organizations the time to map their data needs, align internal processes, and avoid last-minute compliance pressure.

Practical steps to take now include:

• Map your use cases: Identify every service or process in your organization that currently uses identity verification and could benefit from wallet-based attributes.
• Define your attribute needs: For each use case, determine exactly which attributes you need and document the lawful purpose for requesting them.
• Monitor your national authority: Follow the competent authority in your Member State for guidance on the registration process and timelines.
• Review your technical infrastructure: Ensure your systems can interact with EUDI Wallet protocols and interfaces as defined in the Architecture and Reference Framework (ARF).
• Engage legal and compliance teams: Registration intersects with GDPR, sector-specific regulations, and eIDAS 2.0 obligations. Cross-functional alignment is essential.

Organizations that have already engaged with the available resources on eIDAS 2.0 and the EUDI Wallet ecosystem will be better positioned to move quickly when national registration processes open. Waiting for full regulatory clarity before starting internal preparation is a common mistake. The framework is stable enough to begin planning now.

How TrustTech helps with relying party registration under eIDAS 2.0

Navigating relying party registration under eIDAS 2.0 is a multi-layered challenge that touches compliance, technology, and organizational readiness at the same time. TrustTech is built specifically to support organizations through this transition.

Working with TrustTech, organizations can:

• Map their identity use cases to the correct attribute types and registration requirements under eIDAS 2.0
• Align their technical infrastructure with EUDI Wallet protocols and the implementing regulations on interfaces and protocols
• Build a compliant, wallet-ready onboarding flow that meets eIDAS 2.0 requirements from day one
• Integrate reusable identity and qualified signatures into existing workflows across finance, government, healthcare, and other regulated sectors
• Stay ahead of regulatory changes with ongoing expertise in the evolving eIDAS 2.0 implementing acts and national implementations

TrustTech combines deep regulatory knowledge with practical implementation experience, so organizations do not have to figure this out alone. Whether you are at the very start of your eIDAS 2.0 journey or ready to move into implementation, the right support makes the difference between a smooth transition and a compliance gap. Get in touch with TrustTech to find out how your organization can prepare for relying party registration and the broader shift to trusted digital identity in Europe.