eIDAS 2 Verifier Requirements

An eIDAS 2 verifier (also called a relying party) is a government and business that request and verify claims about a user — for example, checking that a user is over 18, or that their income meets a threshold by requesting digital credentials from an EU Digital Identity Wallet (EUDI Wallet). Verifiers must register with a national Registrar to be able to request credentials and implement the required verification protocols and credential formats.

What is an eIDAS 2 verifier (relying party)?

A verifier (also called a relying party or RP) is any organisation that requests and validates credential attributes from an EUDI Wallet. The verifier does not issue credentials — it consumes them to grant access, confirm identity, or fulfil a regulatory check. Verification can take place online — remotely over the internet — or offline in person (proximity), such as presenting a mobile driving licence at a physical checkpoint without an internet connection.

A key obligation introduced by eIDAS 2 is the mandatory registration requirement: under Regulation (EU) 2025/848 every verifier must register with the national Registrar before it can request attributes from a usere/wallet. The registration specifies the organisation, each "intended use" (the service requiring the credential check), and the exact set of attributes to be requested for that use. A verifier may register multiple intended uses, each with its own attribute set.

Trust is established through the access certificate issued to the verifier upon registration: when a verifier sends a presentation request, the wallet checks the access certificate against the national registry. If the verifier is not registered or if the request asks for attributes beyond those defined during registration, the wallet warns the user or refuses the request outright.

eIDAS 2 verifier requirements: the compliance checklist

Every eIDAS 2 verifier must meet the following core obligations. The checklist below is the baseline for compliance.

1. Register with the national Registrar and obtain an Access Certificate for each Relying Party. The "intended use" and the exact attributes to be requested must be declared at registration time.
2. Sign each presentation request with the private key corresponding to the access certificate.
3. Implement OID4VP with the HAIP profile for online credential presentation, and ISO/IEC 18013-7 for mdoc remote flows.
4. Support ISO/IEC 18013-5 for offline proximity verification where the use case requires it (e.g. age checks at physical points of service).
5. Support the mandated credential formats: SD-JWT VC (IETF) and W3C VC VCDM 2.0 for online flows; ISO/IEC 18013-5 for both online and offline.
6. Request only registered attributes — if a request exceeds what was declared at registration, the wallet warns the user and may refuse the request.
7. Validate every presented credential: verify the presentation signature and the full certificate chain to the correct trust anchor; confirm user/holder binding (proof of possession); respect any embedded disclosure policy; and for rulebook-governed credentials (e.g. diplomas, health attestations) apply the rulebook's additional validation rules.
8. Maintain identity-matching logs (including user-provided values, date/time, supporting documentation, and relevant identifier) for a minimum of 6 months and a maximum of 12 months for online verification flows.
9. Support pseudonym authentication for services that do not require the user's full identity.

How credential verification works under eIDAS 2

Verification follows a defined sequence built on the OID4VP (OpenID for Verifiable Presentations) protocol with the HAIP profile for online flows, and ISO/IEC 18013-5 for offline proximity flows. The online sequence is:

1. Relying party registration and certificate — before any interaction, the verifier is registered with the national Registrar. The Registrar's Access Certificate Authority issues an access certificate to the Relying Party Instance (the verifier).
2. Presentation request creation — the verifier creates a signed presentation request specifying the requested attributes (matching the registered intended use) – like name, age, or address.
3. Wallet authenticates the relying party — the EUDI Wallet validates the verifier against the national registry and confirms the request does not exceed the registered attribute set. An unregistered or over-reaching request is flagged or rejected.
4. User approval and selective disclosure — the wallet presents the request to the user. The user may approve the full set of attributes or decline optional ones.
5. Credential presentation returned — the wallet returns the requested attestations and attributes to the verifier.
6. Verifier validates the presentation — the verifier checks the signature of the presented attestations; validates the full certificate chain to the trust anchor; verifies user/holder binding; checks credential status/revocation; and applies any rulebook-specific validation rules.

Build vs buy: how to meet eIDAS 2 verifier requirements

Becoming a compliant verifier means implementing OID4VP and ISO/IEC 18013-5/7, multi-format credential parsing and validation, certificate management, Wallet Provider checks, revocation checking, trust-anchor resolution, policy enforcement, and log retention — and keeping all of them current as the ARF and Implementing Acts evolve. There are three possible integration paths:

• Build apps, buy infrastructure (recommended) — build only the application layer (service logic, UX) and use a standards-compliant verification solution (such as the walt.id Enterprise Stack). Fastest time to market, lowest regulatory and technical risk.
• Build apps, own infrastructure — use open-source verification solutions (such as the walt.id Community Stack) to retain full control while avoiding the need to implement OID4VP, format parsers, and trust validation from scratch.
• Build everything in-house — implement and maintain the full stack internally. Viable only for organisations with a dedicated identity engineering team.

How walt.id helps verifiers comply

walt.id provides the verification infrastructure behind compliant eIDAS 2 deployments. The walt.id Verifier delivers what the relying-party requirements demand, out of the box:

• Verify every credential type and format — PID, LPID, EAA, QEAA, PuB-EAA, and SCA attestations in SD-JWT VC, ISO/IEC 18013-5, and W3C VC VCDM 2.0, over OID4VP + HAIP and ISO/IEC 18013-7 for remote flows, and ISO/IEC 18013-5 via BLE/NFC for offline proximity flows.
• Automated trust validation — the walt.id Trust Service automatically caches and validates EU Trusted Lists in real time, resolving trust anchors for signature validation; Full trust-chain validation are performed automatically on every presentation.
• Relying-party certificate lifecycle management — access and registration certificates are managed via the walt.id solution; the verifier service presents its certificates automatically to wallets during credential exchange.
• Configurable verification policies via OPA/REGO — a layered policy framework on top of the standard eIDAS 2 validations: pre-defined policies (signature, validity, schema); parameterized policies including webhook delegation to external systems; and custom REGO rules evaluated by OPA targeting the full presentation or individual credentials.
• Transaction-data verification for SCA/PSD2 — fully supports the inclusion and verification of dynamic transaction data (amount, currency, payee) within the authorisation request, as required for Strong Customer Authentication under the TS12/PSD2 specifications.
• Pseudonym-based authentication — relying party server and client components for pseudonym-based user authentication, including challenge generation, relying-party ID setup, and auth-info storage for repeat logins.

Explore the eIDAS 2 infrastructure layer or talk to the team about a specific verification use case.

Frequently asked questions

What is an eIDAS 2 verifier (relying party)?

An eIDAS 2 verifier (also called a relying party) is a government or business that requests and validates credential attributes from a user's EU Digital Identity Wallet to deliver a service — such as opening a bank account, verifying age, enrolling at a university, or authorising a payment. Verifiers must register with a national Registrar before they can interact with EUDI Wallets.

What are the requirements to become an eIDAS 2 verifier?

An eIDAS 2 verifier must: register with the national Registrar and obtain an Access Certificate; declare each intended use of requested attributes and the exact attributes to be requested; implement OID4VP with the HAIP profile (and ISO/IEC 18013-5 for offline flows); support the mandated credential formats; request only registered attributes; validate every presented credential including signature, certificate chain, user binding, and rulebook checks; and support pseudonym authentication.

Do verifiers have to register under eIDAS 2?

Yes. Registration is mandatory. Regulation (EU) 2025/848 on the registration of wallet-relying parties requires every verifier to register with the national Registrar before interacting with EUDI Wallets. Registration covers the organisation, each service ("intended use"), and the exact set of attributes to be requested. An Access Certificate is issued per Relying Party Instance (Verifier). Without a valid registered certificate, the wallet will reject or flag the presentation request.

What is the difference between online and offline verification under eIDAS 2?

Online verification uses OID4VP with the HAIP profile (and ISO/IEC 18013-7 for mdoc remote flows) and supports SD-JWT VC, W3C VC, and ISO/IEC 18013-5 credential formats. Offline (proximity) verification uses the ISO/IEC 18013-5 protocol over BLE or NFC and supports only ISO/IEC 18013-5 credentials.

Which protocols and formats must an eIDAS 2 verifier support?

For online verification: OID4VP with the HAIP profile and ISO/IEC 18013-7 for mdoc remote flows; credential formats SD-JWT VC (IETF), W3C VC VCDM 2.0, and ISO/IEC 18013-5. For offline proximity verification: the ISO/IEC 18013-5 protocol over BLE/NFC; credential format ISO/IEC 18013-5.

Can a verifier request any attribute from a wallet?

No. A verifier may only request attributes that were declared at registration time for a specified intended use. Each Verifier access certificate is tied to a registered attribute set. If a presentation request asks for more attributes than registered, the wallet warns the user and may refuse the request. This constraint is enforced by the wallet, making over-reaching requests technically self-defeating in addition to being non-compliant.