Businesses verify eIDAS 2.0 wallet credentials by acting as a relying party: they send a credential request to a user’s EUDI Wallet, receive a cryptographically signed response, and validate that response against the relevant national trusted lists. The entire exchange happens in seconds, without the business needing to call anyone to confirm the data is genuine. The sections below unpack each part of that process in detail, from the technical standards involved to the legal obligations your organisation takes on.
What happens during the eIDAS 2.0 credential verification process?
During eIDAS 2.0 credential verification, a business sends a presentation request to the user’s EUDI Wallet, the wallet prompts the user to review and approve which credentials to share, and the wallet then returns a cryptographically signed response that the business can validate automatically. No manual document check and no phone call is needed.
Here is how the flow works in practice:
- The business sends a presentation request. Using a standardised protocol, the relying party specifies exactly which attributes it needs, for example proof of age, a professional qualification, or a verified address.
- The user reviews and approves. The wallet displays what is being requested. The user decides whether to share it. Nothing leaves the wallet without explicit approval.
- The wallet returns a verifiable presentation. The response is digitally signed by the credential issuer, which could be a government body, a bank, or another trusted institution, and it is bound to the specific transaction.
- The business validates the presentation. The relying party performs three distinct checks: it verifies the issuer’s signature against the relevant national trusted list, it checks the revocation status of the credential via the issuer’s status information, and it validates the wallet unit attestation to confirm that the presenting wallet is running on a certified wallet solution. If everything checks out, the verification is complete.
The key advantage here is that the business never stores raw identity documents. It receives only the attributes it asked for, backed by cryptographic signatures, which reduces both fraud risk and data handling obligations.
What types of credentials can businesses request from a wallet?
Businesses can request any credential that has been issued into a user’s EUDI Wallet by a recognised issuer. The most common credential type is the Person Identification Data (PID) attestation, which covers core identity attributes such as name, date of birth, and nationality. PID is issued by authorised national issuers designated by each Member State, not by authentication mechanisms such as DigiD or BankID. Beyond PID, wallets can hold a wide range of electronic attestations of attributes, issued by qualified trust service providers as Qualified Electronic Attestations of Attributes (QEAAs), by public bodies as Public Body Electronic Attestations of Attributes (PuB-EAAs), or by other recognised issuers as non-qualified EAAs.
Practical examples of attestations businesses may request include:
- Age verification (for age-restricted services or products)
- Proof of address
- Professional qualifications or licences
- Mobile driving licences
- Health insurance or social security data
- Academic diplomas or certificates
- Employment status or employer attestations
- KYC-verified identity for financial onboarding
An important principle built into eIDAS 2.0 is selective disclosure. A business may only request the attributes it genuinely needs for a specific purpose. If you only need to confirm someone is over 18, you request an age attestation disclosing the attribute “older than 18”, without requiring the user’s full date of birth. This protects user privacy and keeps your data footprint small, which also simplifies GDPR compliance.
For organisations in regulated sectors such as financial services, the ability to receive a pre-verified KYC attestation from a trusted issuer can reduce onboarding friction. A customer who has already completed identity verification at their bank may be able to reuse that attestation with your organisation. Whether that reuse satisfies your AML obligations depends on AML regulation, not on eIDAS 2.0 itself.
How does a business become a trusted relying party under eIDAS 2.0?
To become a relying party under eIDAS 2.0, a business must register with the competent national authority in its Member State of establishment before it can request data from EUDI Wallets. This obligation is set out in Commission Implementing Regulation (EU) 2025/848 of 6 May 2025. Registration gives the business the right to request credentials from EUDI Wallets and ensures users can see that the requesting organisation is legitimate before sharing any data.
As part of registration, the relying party declares each intended use: which attributes and attestations it will request and for what purpose. The wallet checks incoming requests against this registered scope. A request that falls outside the declared scope will not be fulfilled. Cross-border use cases do not remove the national registration layer: a relying party operating across borders will need to understand the requirements in each relevant jurisdiction.
The registration process generally involves:
- Identifying the relevant national authority. Each Member State designates a body responsible for managing relying party registrations within its jurisdiction.
- Submitting an application. The business declares which credential types it intends to request and for what purposes.
- Receiving a relying party certificate. This certificate is embedded in presentation requests so that wallets and users can verify the requester’s identity before any data is shared.
- Maintaining ongoing compliance. Relying parties must continue to meet the requirements of the regulation, including data minimisation, purpose limitation, and security obligations.
From a user experience perspective, registration matters because EUDI Wallets are designed to show users the verified identity of the requesting party before they approve sharing anything. An unregistered or unrecognised requester will trigger a warning in the wallet, which is likely to result in the user refusing the request. Becoming a registered relying party is therefore both a legal requirement and a trust signal that directly affects whether users are willing to engage with your service.
One point worth clarifying: a relying party does not choose a wallet provider. Your organisation must be able to accept every relevant notified EUDI Wallet, regardless of which provider issued it. Registration as a relying party does not by itself require a Qualified Trust Service Provider (QTSP). A QTSP becomes relevant in specific scenarios, such as qualified signing or the issuance of qualified attestations.
What technical standards does eIDAS 2.0 wallet verification rely on?
eIDAS 2.0 wallet credential verification relies on a set of open, interoperable technical standards. The legally binding requirements are set out in the regulation and its implementing acts, adopted by the European Commission. The Architecture and Reference Framework (ARF), developed by the European Commission together with Member States and the European Digital Identity Cooperation Group, provides the technical elaboration of those requirements and serves as a reference for implementers. The two primary credential formats are ISO/IEC 18013-5 (used for mdoc credentials, such as mobile driving licences) and SD-JWT VC (Selective Disclosure JSON Web Tokens for Verifiable Credentials). Both formats support selective disclosure and cryptographic binding.
For the communication protocols used between wallets and relying parties, the framework draws on:
- OpenID for Verifiable Presentations (OID4VP) for online credential presentation flows
- OpenID for Verifiable Credential Issuance (OID4VCI) for issuing credentials into wallets
- ISO/IEC 18013-5 proximity protocols for in-person, offline verification scenarios
- ISO/IEC TS 18013-7 for online presentation of mdoc credentials
National trusted lists play a central role in the technical architecture. These lists are maintained by competent authorities in each Member State and are brought together in the EU List of Trusted Lists (LOTL). When a business receives a credential, it verifies the issuer’s signature against the relevant national trusted list and checks the revocation status via the issuer’s status information. A third check, validation of the wallet unit attestation, confirms that the presenting wallet instance is part of a certified wallet solution. The signature verification can take place offline, but revocation status and wallet unit attestation checks require a connection to the issuer’s or wallet provider’s systems. There is no single central European database that operationally manages all EUDI Wallets; governance is a shared responsibility distributed across the European Commission, Member States, national competent authorities, wallet providers, and issuers.
For organisations building or integrating verification infrastructure, understanding these standards is essential. Compliant wallet SDKs and verification libraries handle much of this complexity, meaning your development team does not need to implement the cryptographic primitives from scratch. What matters most is choosing a platform that is built on these standards from the ground up.
What are the legal obligations for businesses that verify wallet credentials?
Businesses that verify EUDI Wallet credentials take on a defined set of legal obligations under eIDAS 2.0, which amends Regulation (EU) 910/2014, and under related EU legislation. As a relying party, you are responsible for processing only the data you are authorised to request, using it only for the declared purpose, and protecting it in line with GDPR and applicable sector regulations.
The core legal obligations include:
- Data minimisation: You may only request the attributes strictly necessary for your stated purpose. Requesting more than you need is a breach of both eIDAS 2.0 and GDPR.
- Purpose limitation: Data received through a wallet presentation may only be used for the specific purpose declared at the time of the request.
- Security obligations: You must implement appropriate technical and organisational measures to protect the verified data you receive.
- Transparency to users: Users must be clearly informed about what data you are requesting and why, before they approve the request.
- Record keeping: Depending on your sector, you may be required to maintain audit trails of verification transactions for compliance and accountability purposes.
- Sector-specific requirements: In regulated sectors such as finance, healthcare, telecoms, energy, and transport, additional obligations from AML, KYC, or sector-specific data regulations may apply on top of the eIDAS 2.0 baseline. These sector-specific obligations do not disappear because a credential has been verified through a EUDI Wallet; relying parties must assess their obligations under each applicable regulatory framework.
It is also worth noting the distinction between a user approving a data request in the wallet and consent as a legal basis under GDPR. The user’s approval in the wallet is a wallet interaction. As a relying party, you need your own GDPR legal basis for the processing you carry out. For KYC purposes, that basis is typically a legal obligation. For health data, an additional ground under Article 9(2) GDPR is required.
Because wallet credentials carry tamper-evident cryptographic signatures and are timestamped, they can serve as strong evidence in an audit. A well-implemented verification flow generates a compliance record that protects your organisation if questions arise later. Organisations in healthcare and government will find this audit trail capability particularly valuable.
What acceptance obligations apply to private-sector organisations?
eIDAS 2.0 introduces a mandatory acceptance obligation for certain private-sector organisations under Article 5f of the regulation. From 24 December 2027, this obligation applies to organisations in regulated sectors where strong user authentication is legally or contractually required. The sectors covered include banking and financial services, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services.
Very large online platforms (VLOPs) are covered by a separate provision of Article 5f. For VLOPs, the obligation applies where the platform requires user authentication, on voluntary request from the user and for the minimum necessary data. The condition relating to legally or contractually required strong authentication does not apply to VLOPs.
Micro and small enterprises are exempt from the Article 5f obligation. The exemption applies to organisations with fewer than 50 employees and an annual turnover or balance sheet total not exceeding 10 million euros.
The 24 December 2026 deadline is a separate obligation: from that date, Member States must make at least one certified EUDI Wallet available and public bodies must accept notified wallets for online services requiring electronic identification. This deadline marks when wallets begin to become available and when private organisations can start testing acceptance ahead of their own 2027 deadline. Practical interoperability and national rollout are expected to develop in phases.
How the ID Connector supports eIDAS 2.0 credential verification
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 preparing for eIDAS 2.0 credential verification, the ID Connector handles the technical complexity of the verification process, including:
- Accepting every relevant notified EUDI Wallet, regardless of the issuing Member State or wallet provider
- Verifying issuer signatures against national trusted lists, brought together in the EU List of Trusted Lists
- Checking credential revocation status via issuer status information
- Validating wallet unit attestations to confirm the presenting wallet runs on a certified wallet solution
- Enforcing the registered attribute scope so that only declared attributes are requested and processed
- Supporting reuse of verified identity data across services
- Connecting to a qualified trust service provider for qualified signing where required
This applies across the sectors where the acceptance obligation and verification requirements are most pressing: financial services, healthcare, pharma, and government. If your organisation is preparing for eIDAS 2.0 and wants to understand what verification looks like in practice, get in touch with TrustTech.