A relying party under eIDAS 2.0 is any organization or service that requests and verifies identity data from a user’s European Digital Identity (EUDI) Wallet or another trusted identity source. The term comes directly from eIDAS 2.0, which is Regulation (EU) 2024/1183 amending Regulation (EU) 910/2014, and which formally defines and governs the role. If your organization needs to verify who someone is before granting access to a service, you are acting as a relying party. This article walks through what that means in practice, what your obligations are, and how to get ready.
What does a relying party actually do under eIDAS 2.0?
A relying party requests verified identity attributes from a user and then relies on that information to make a decision, such as granting access, completing an onboarding process, or signing a contract. Under eIDAS 2.0, this role is formalized: relying parties must meet specific requirements to interact with EUDI Wallets and the broader European digital identity ecosystem.
In practical terms, a relying party sends a request to a user’s EUDI Wallet asking for one or more verified attributes. This could be as simple as confirming someone is over 18 via selective disclosure of the relevant attribute, or as detailed as receiving a verified professional qualification. The user then decides which data to share. Once shared, the relying party receives tamper-evident, cryptographically signed information it can trust, subject to the verification steps described below.
This is a significant shift from today’s approach, where organizations typically run their own identity checks from scratch. Under eIDAS 2.0, verified data travels with the user, and relying parties can accept that data with confidence because it is backed by trusted issuers and a regulated framework.
How is a relying party different from an identity provider?
A relying party receives and uses identity data, while an identity provider issues and authenticates it. These are distinct roles within the digital identity ecosystem, even though the same organization can sometimes play both roles in different contexts.
An identity provider, such as a government authority or a bank, is responsible for verifying a person’s identity and issuing credentials. A relying party, by contrast, is on the receiving end. It trusts the identity provider’s attestation and uses the resulting data to deliver a service.
Consider this analogy: a government issues a driving licence (identity provider), and a car rental company checks that licence before handing over a vehicle (relying party). Under eIDAS 2.0, the same logic applies digitally. The EUDI Wallet holds verified attestations issued by trusted sources, and relying parties request specific attributes from that wallet when they need to verify something about the user.
Which organizations are considered relying parties under eIDAS 2.0?
Any organization that requests verified identity data from an EUDI Wallet or another eIDAS-compliant identity source to deliver a service qualifies as a relying party. This covers a wide range of sectors and use cases across both the public and private sectors.
Common examples of relying parties include:
- Financial institutions verifying customer identity during account opening or KYC processes
- Healthcare providers confirming patient identity or professional credentials before granting access to sensitive records
- Government agencies authenticating citizens for access to public services such as tax filing or benefit claims
- Employers verifying qualifications and right-to-work status during hiring
- Telecom operators registering SIM cards with verified identity
- Online platforms performing age verification or access control
- Pharmaceutical and life sciences organizations checking professional credentials for regulated access
If your organization currently runs identity checks as part of onboarding, access management, or compliance, you are likely already functioning as a relying party. Under eIDAS 2.0, that role comes with formal obligations. Organizations in financial services and healthcare are among those most directly affected.
What are the registration and compliance obligations for relying parties?
Under eIDAS 2.0, relying parties are required to register before they can request data from EUDI Wallets. This registration requirement is set out in CIR (EU) 2025/848, adopted on 6 May 2025. It applies to both public and private sector organizations. Each relying party must register with the national competent authority of the Member State where it is established, and must declare per intended use which attributes and attestations it will request. The wallet checks incoming requests against this registered scope before any data is shared with the relying party.
Registration serves a clear purpose: it ensures that users can see who is requesting their data and that only legitimate, accountable organizations can access verified identity attributes. The legally binding requirements for relying party registration are set out in the implementing acts adopted by the European Commission. The Architecture and Reference Framework (ARF) provides the technical elaboration of those requirements, specifying the formats and procedures that wallet providers, issuers, and relying parties must follow in practice.
Beyond registration, relying parties must also:
- Define and declare the purpose of each data request so users can make an informed decision about what to share
- Request only the minimum necessary data in line with GDPR’s data minimization principle
- Ensure their systems can handle verifiable attestations in the formats specified by the eIDAS 2.0 technical standards, including mdoc and SD-JWT VC
- Maintain audit trails of identity-related transactions for accountability and regulatory review
- Stay current with technical specifications as the ARF for the EUDI Wallet continues to evolve alongside the implementing acts
Non-compliance is not a theoretical risk. Organizations that fail to register or that handle identity data outside the regulatory framework face both legal exposure and a loss of user trust. Given that eIDAS 2.0 intersects with GDPR, AML, KYC, and PSD2 requirements, compliance is genuinely multi-layered.
How does a relying party verify identity data from the EUDI Wallet?
When a relying party receives a presentation from a user’s EUDI Wallet, verification involves three distinct checks, not a single cryptographic step.
The first check is verifying the issuer’s signature against the relevant national trusted list. National trusted lists are consolidated in the EU List of Trusted Lists (LOTL), which identifies issuers whose attestations carry the assurance levels required under eIDAS 2.0. This check can be performed fully offline once the trusted list has been retrieved.
The second check is confirming the revocation status of the attestation. This requires consulting the status information made available by the issuer, which means the relying party needs a connection to retrieve current revocation data. An attestation that has not been revoked at the time of presentation is valid; an earlier offline check does not confirm current status.
The third check is validating the wallet unit attestation. This confirms that the wallet presenting the data is running on a certified wallet solution. A wallet solution is the certified product of a wallet provider; the wallet instance is the application installed on a specific user’s device; and the wallet unit combines that instance with the Wallet Secure Cryptographic Application and the Wallet Secure Cryptographic Device in which the private keys are held. Private keys for PID and attestations do not leave the secure element, which is why attestations must be re-issued when a user moves to a new device.
Together, these three checks give a relying party a well-founded basis to trust the data it receives. It is worth noting that a relying party does not choose a wallet provider: it must be able to accept every relevant notified wallet, regardless of which provider issued it or in which Member State.
How does a relying party interact with the EUDI Wallet in practice?
A relying party interacts with the EUDI Wallet by sending a structured request for specific identity attributes, which the user reviews and approves before any data is shared. This interaction follows standardized protocols defined in the eIDAS 2.0 technical framework, ensuring interoperability across EU Member States. Interoperability operates at the level of the framework itself: a notified wallet from one Member State can be used with an appropriate relying party in another Member State, but this does not mean that every use case will be available in every country simultaneously, or that national registration requirements or sector-specific rules are overridden.
The practical flow typically looks like this: a user arrives at a service, such as opening a bank account or accessing a government portal. The service, acting as the relying party, presents a request asking for specific verified data, for example name, date of birth, and nationality. The user receives this request in their EUDI Wallet app, reviews what is being asked, and chooses to approve or decline. Each request requires a separate approval from the user. If approved, the wallet sends the cryptographically signed data back to the relying party, which then carries out the verification steps described above.
This model has two important practical implications. First, the user is always in control: nothing is shared without explicit approval of each individual request. Second, the relying party receives data it can trust, because it is backed by verified issuers operating within the regulated ecosystem. This removes the need for repeated manual checks and significantly reduces onboarding friction, which is one of the clearest operational benefits of the EUDI Wallet for organizations that currently run lengthy verification processes.
What are the acceptance obligations, and when do they apply?
eIDAS 2.0 introduces two separate acceptance obligations with different timelines and scopes.
From 24 December 2026, public sector bodies must accept notified EUDI Wallets for online services that require electronic identification. This deadline is a legal obligation, not a predicted launch date, and national rollout, wallet certification, and the practical readiness of relying parties are likely to develop in phases across different Member States.
From 24 December 2027, Article 5f of the regulation applies to relevant regulated private sector categories where strong user authentication is legally or contractually required. These categories include banking and financial services, healthcare, telecom, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services. Micro and small enterprises are excluded from this obligation: the threshold is fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros.
Very large online platforms (VLOPs) fall under a separate provision of Article 5f. For VLOPs, the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data. The condition about legally or contractually required strong authentication does not apply to VLOPs.
What should organizations do now to prepare as a relying party?
Organizations should start preparing now by mapping where identity verification happens in their current processes, understanding what data they actually need, and assessing whether their technical infrastructure can support verifiable attestations and wallet-based interactions.
The legal deadline for Member States to make EUDI Wallets available is 24 December 2026. National rollout, certification and notification of wallets, and the practical acceptance of wallet interactions by relying parties are likely to develop in phases across different Member States. Organizations should plan for a graduated rollout across the period leading up to both the 2026 and 2027 deadlines.
Concrete steps to take include reviewing your current onboarding and authentication flows to identify where EUDI Wallet integration makes sense, engaging your compliance and legal teams to understand the registration requirements in your Member State under CIR (EU) 2025/848, and connecting with your technical teams to assess readiness for the relevant protocols and data formats, including OID4VP for presentation and OID4VCI for issuance.
It is also worth looking at how other organizations in your sector have approached this. Four Large Scale Pilots ran from April 2023 to 2025, involving more than 350 organizations across 26 EU Member States. These pilots tested real-world wallet interactions across use cases including banking, healthcare, government services, education, social security, and payments. A second wave of pilots started in 2025, covering business wallets, payments, travel, ticketing, and vehicle registration. The insights from these pilots are shaping the final technical specifications, and staying informed about their outcomes will help you plan more effectively.
How TrustTech supports relying parties with the ID Connector
Becoming a compliant and technically ready relying party under eIDAS 2.0 involves navigating registration requirements, updating systems, and rethinking how identity data flows through your organization.
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 relying parties, the ID Connector specifically handles:
- Wallet acceptance across notified wallet solutions, regardless of the issuing Member State
- Verification against national trusted lists consolidated in the EU List of Trusted Lists
- Revocation status checks against issuer-provided status information
- Validation of wallet unit attestations to confirm the presenting wallet runs on a certified wallet solution
- Scope management to ensure requests stay within the attributes declared during registration
- Reuse of verified identity data across services, reducing repeated verification steps
- Qualified signing via a connected QTSP, where the use case requires it
TrustTech works with organizations in financial services, healthcare, pharma, and government. Get in touch with TrustTech to discuss your registration obligations, your technical requirements, and what the right next step looks like for your organization.