How do relying parties connect to the EUDI Wallet ecosystem?

Relying parties connect to the EUDI Wallet ecosystem by registering within a national trust framework under CIR (EU) 2025/848, implementing standardized protocols to request and verify digital credentials, and accepting cryptographically signed attestations from wallet holders. This article walks through the key questions every organization needs to answer before making that connection.

What does a relying party actually do in the EUDI Wallet ecosystem?

A relying party is any organization or service that requests and verifies identity attributes or attestations from a user’s EUDI Wallet. Relying parties receive cryptographically signed attestations directly from the wallet, and they trust those attestations because they come from a recognized issuer within the ecosystem.

In practical terms, a relying party might be a bank asking a new customer to share their verified name and date of birth during onboarding, a government portal requesting proof of address, or a healthcare provider verifying a professional qualification. The relying party defines what it needs, the user decides what to share, and the wallet handles the secure transfer.

This model changes the mechanics of identity verification. Relying parties receive structured, machine-readable data that has already been verified by a trusted issuer, making the process faster, more reliable, and less prone to fraud.

How does a relying party technically connect to the EUDI Wallet?

A relying party connects to the EUDI Wallet by implementing the technical protocols set out in the Architecture and Reference Framework (ARF), primarily using OpenID for Verifiable Presentations (OID4VP) to request credentials and ISO/IEC TS 18013-7 for online document presentation. For proximity presentation scenarios, ISO/IEC 18013-5 applies. The legally binding requirements are set out in the implementing acts adopted under eIDAS 2.0, which amends Regulation (EU) 910/2014. The ARF provides the technical elaboration of those requirements. These open standards ensure that any compliant wallet can interact with any compliant relying party, regardless of which Member State issued the wallet.

The connection flow works roughly like this:

1. The relying party sends a presentation request specifying which attributes or attestations it needs, scoped to the attributes registered under its intended use in the national registry.
2. The user’s wallet displays the request and asks the user to approve sharing the relevant data.
3. The wallet generates a verifiable presentation, signed by the wallet and the original issuer.
4. The relying party receives the presentation and carries out the necessary verification checks before granting access or completing the transaction.

Verification is not a single cryptographic check. It involves three distinct steps: verifying the issuer’s signature against the relevant national trusted list, checking the revocation status through the issuer’s status information, and validating the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. Only the first of these can be performed fully offline.

To make this work in practice, relying parties need to integrate a verification library or service that handles these checks, manages trust anchors from the national trusted lists aggregated in the EU List of Trusted Lists (LOTL), and stays up to date with changes to the ARF and the underlying implementing acts. Building this capability in-house is possible, but many organizations choose to work with specialized providers that already have compliant verification infrastructure in place.

What is the trust framework relying parties must register under?

Relying parties must register within the trust framework established under eIDAS 2.0. Under CIR (EU) 2025/848, adopted on 6 May 2025, a relying party must register with the national competent authority of the Member State where it is established before it can request wallet data. Registration covers the intended uses for which attributes and attestations will be requested. The wallet checks each presentation request against this registered scope.

Governance of the broader framework is a shared responsibility: 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; national competent authorities maintain trusted lists; and the European Digital Identity Cooperation Group supports cooperation and cross-border alignment.

The trust framework serves two purposes. First, it protects users by ensuring they only share data with verified organizations. Second, it gives relying parties access to the cryptographic trust anchors they need to validate attestations issued by wallet providers in other Member States.

Each Member State maintains its own trusted list of recognized wallet providers and issuers. These national lists feed into the EU List of Trusted Lists (LOTL), so a relying party registered in one country can accept attestations from wallets issued in another, provided the relevant wallet has been certified and notified. For organizations operating across borders, registration remains connected to the applicable national registration framework, and cross-border use does not remove national or sector-specific obligations.

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

Relying parties can request any attribute that is defined within a recognized attestation type and that the user’s wallet contains. The most fundamental attestation is the Person Identification Data (PID), which includes attributes such as name, date of birth, nationality, and address. Beyond the PID, wallets can hold a range of qualified electronic attestations of attributes (QEAAs), public-body-issued electronic attestations of attributes (PuB-EAAs), and non-qualified electronic attestations of attributes (EAAs), covering documents such as driving licences, professional qualifications, diplomas, and health credentials.

However, relying parties cannot request more data than they need for a specific purpose. The principle of data minimisation is built into the eIDAS 2.0 framework, meaning that requests must be scoped to what is genuinely necessary for the service being provided. A platform that only needs to verify a user’s age, for example, should request an age attestation, such as a selective disclosure of the attribute confirming the user is over 18, rather than a full set of identity attributes.

This selective disclosure capability is one of the most significant features of the EUDI Wallet model. Users can share a single attribute, such as proof that they are over 18, without revealing their full name or date of birth. For relying parties, this means designing credential requests thoughtfully and only asking for what the use case actually requires.

What are the main compliance obligations for relying parties under eIDAS 2.0?

Under eIDAS 2.0, relying parties have several concrete compliance obligations that go beyond simply implementing the right technical protocols. These obligations are designed to protect users and maintain trust across the ecosystem.

• Registration: Relying parties must register with the relevant national competent authority under CIR (EU) 2025/848 before requesting attestations from EUDI Wallets. Registration specifies the intended uses and the attributes that will be requested.
• Purpose limitation: Each credential request must specify a clear and lawful purpose, and relying parties may only use the data received for that stated purpose.
• Data minimisation: Requests must be limited to the attributes strictly necessary for the intended service.
• Transparency: Users must be clearly informed about who is requesting their data, why, and what will happen to it.
• GDPR alignment: All data received through the wallet remains subject to GDPR obligations, including storage limits, access rights, and security requirements. A relying party requires its own lawful basis for processing under the GDPR. For KYC purposes, that basis is typically a legal obligation. For health data, an additional ground under Article 9(2) GDPR is required.
• Audit readiness: Relying parties should maintain records of credential requests and verifications to demonstrate compliance if required.

Note that a supplier processing wallet data on behalf of a client does not become the relying party by doing so. The registration obligation rests with the organization that delivers the service to the end user.

Organizations in regulated sectors such as financial services or healthcare will also need to align their EUDI Wallet integration with sector-specific regulations, such as strong customer authentication requirements or patient data protection rules. Cross-border use does not remove these sector-specific obligations, and each attestation does not automatically carry the same legal consequence in every Member State.

How should organizations start preparing to become a relying party?

Organizations should start by mapping the use cases within their services where EUDI Wallet integration would add the most value, then assess the technical and legal steps required to support those use cases. Preparation involves both a compliance track and a technical track, and the two need to move in parallel.

A practical starting point looks like this:

1. Identify your use cases. Which services require identity verification? Where would accepting wallet attestations reduce friction or improve security?
2. Review the regulatory requirements. Understand what registration is required under CIR (EU) 2025/848 with the national competent authority in your Member State and what obligations apply to your sector.
3. Assess your technical readiness. Do your existing systems support the protocols needed to receive and verify EUDI Wallet attestations?
4. Plan your data minimisation approach. Define exactly which attributes you need for each use case and build your credential requests accordingly.
5. Test with available pilots and reference implementations. The large-scale pilot projects that ran from April 2023 to 2025 produced open-source reference implementations that offer a useful starting point for testing your integration before full deployment.

24 December 2026 is the legal deadline by which every EU Member State is required to make at least one certified EUDI Wallet available to citizens and residents, and public sector bodies must accept notified wallets as a means of identification for online services requiring electronic identification from that date. Practical interoperability and national rollout may develop in phases, and the level of maturity across Member States may vary at that point. For regulated private sector organizations, including those in banking, financial services, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services, a mandatory acceptance obligation applies from 24 December 2027 under Article 5f of eIDAS 2.0, within contexts where strong user authentication is legally or contractually required. Very large online platforms with more than 45 million users in the EU are covered by a separate provision of Article 5f: for those platforms, the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data. Micro and small enterprises, defined as organizations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros, are exempt from the private acceptance obligation. Organizations that begin preparing now have time to address technical and compliance gaps well before those deadlines arrive. Reviewing your implementation approach now gives you time to address gaps before they become urgent.

How the ID Connector helps organizations connect to the EUDI Wallet ecosystem

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 organizations becoming a relying party, the ID Connector handles the verification steps that the framework requires:

• Wallet acceptance: The ID Connector accepts every notified EUDI Wallet, regardless of the issuing Member State or wallet provider. A relying party does not choose a wallet provider; it must be able to accept any relevant certified wallet.
• Trust management: The ID Connector verifies issuer signatures against the relevant national trusted lists, aggregated in the EU List of Trusted Lists (LOTL).
• Revocation checking: The ID Connector checks the revocation status of each attestation through the issuer’s status information.
• Wallet unit attestation validation: The ID Connector confirms that the presenting wallet runs on a certified wallet solution.
• Registered attribute scope: The ID Connector enforces the attribute scope registered under each intended use, so that presentation requests remain within the bounds of what the relying party has declared to the national competent authority.
• Qualified signing: Where a use case requires a qualified electronic signature, the ID Connector connects to an accredited QTSP to support that workflow.

TrustTech works with organizations across government, financial services, healthcare, and pharma, combining knowledge of the EUDI Wallet ecosystem with practical implementation experience. If you are ready to begin integration or want to understand what relying party status means for your organization, get in touch with TrustTech to discuss your next steps.