eIDAS 2 for Identity Verification Providers

eIDAS 2 (Regulation (EU) 2024/1183) requires every EU Member State to provide a certified EU Digital Identity Wallet (EUDI Wallet) by the end of 2026, and requires businesses to accept it for user authentication and identification by the end of 2027.

The wallet holds a Person Identification Data (PID) credential issued at Level of Assurance High alongside any number of further credentials: driving licences, diplomas, proof of address, company representation powers, bank-issued authentication credentials.

Next to this, the regulation formalises a role that identity verification providers are best placed to fill: the intermediary, a registered party that connects to wallets on behalf of their clients who want to be verifiers (relying parties).

What eIDAS 2 changes for identity verification providers

eIDAS 2 entered into force on 20 May 2024 and obliges every EU Member State to provide at least one certified EUDI Wallet to citizens and residents by the end of 2026.

The four most important changes eIDAS 2 brings for identity verification providers:

1. A new verification method. Where a customer holds an EUDI Wallet, identity proofing becomes a single credential presentation: the user shares their PID, and the verifier validates it cryptographically in seconds.
2. Customer demand from every regulated sector. The banks, telecoms, insurers, platforms and public services that make up the IDV customer base must accept the wallet by the end of 2027 (public sector: end of 2026). This brings a great chance for the IDV provider to provide the solution.
3. A formal role in the trust ecosystem. eIDAS 2 defines intermediaries — parties that interact with wallets on behalf of relying parties. An IDV provider that verifies wallet credentials for its clients can operate inside the regulation as a registered intermediary.
4. Verification beyond identity — and issuance. The wallet carries far more than the PID, and each attribute can be verified for a fraction of the cost of a document check. At the same time, the clients that hold verified customer data — banks, insurers, employers, universities — gain the ability to issue credentials of their own, and will need someone to build it.

The compliance timeline is compact:

The roles identity verification providers can play under eIDAS 2

Every digital identity ecosystem has three actors — issuer, verifier, and wallet provider. An IDV provider rarely plays any of them for itself. It plays them on behalf of its clients — and for the verifier role, eIDAS 2 gives that position a name: the intermediary.

Intermediary: the core role

As an intermediary, an IDV provider performs the verifier role for its clients: it registers with a national registrar, holds the access certificates wallets use to authenticate it, registers each client and their intended uses, sends presentation requests to wallets, and validates the credentials that come back. Under Article 5b(10) of the regulation, intermediaries acting on behalf of relying parties are deemed to be relying parties themselves.

Two things make this the core role. First, it is exactly what an IDV provider already is for its clients — the party that takes the verification problem off their hands — transposed into the wallet ecosystem. Second, it is use-case-independent: the same verification solution can be used from the verification of a PID for a bank's onboarding, an "over 18" proof for a gaming platform, a driving licence for a mobility operator, and an SCA attestation for a payment.

Issuance enabler: the strategic role

Under eIDAS 2, any business can become an issuer — and many IDV clients will have to. Wallet-based Strong Customer Authentication only works once a bank has issued an SCA attestation into the customer's wallet; insurers will issue proof of cover; universities will issue diplomas; employers will issue staff credentials.

Wallet provider: the optional role

As a wallet provider, an IDV provider offers the wallet itself, either as a standalone certified EUDI Wallet or as wallet capabilities embedded in a client's app.

Core eIDAS 2 use cases for IDV providers at a glance

Wallet-based identity verification

Today's remote verification chains together document capture, authenticity checks, liveness detection, biometric matching, and often a video call or manual review. With the EUDI Wallet, the same outcome is a single credential presentation.

What the PID is

The PID is the core identity credential every certified wallet must hold. It is issued by a designated PID provider in each Member State, which — under Commission Implementing Regulation (EU) 2024/2977 — must verify the user's identity at Level of Assurance High before issuance. Receiving the PID is what activates the wallet. The PID contains the user's name, date of birth, place of birth and nationality, among other attributes, is issued in the mandated formats — SD-JWT VC and ISO/IEC 18013-5 (mdoc) — and is cryptographically bound to the wallet's secure keys.

How a verification works

The verifier sends a presentation request over OID4VP (or ISO/IEC 18013-7 for remote mdoc flows), stating which attributes it needs. The wallet shows the user who is asking and for what, the user approves, and the wallet returns a presentation. The verifier then checks that:

• the credential was signed by an issuer on the EU trusted lists,
• it has not been revoked or suspended,
• it is bound to this wallet and was presented by its holder (holder binding),
• the wallet itself is genuine and not revoked (Wallet Unit Attestation), and
• the disclosed attributes match what was requested.

All of this is cryptographic. There is no document to inspect, no face to match against a photo, and no human in the loop. Because the PID was issued at Level of Assurance High, the result meets the identification requirements of the EU Anti-Money Laundering Regulation (Regulation (EU) 2024/1624), which recognises eIDAS-based electronic identification.

Selective disclosure and data minimisation

The wallet lets the user share only the attributes a process requires — a date of birth without an address, or an "over 18" confirmation without a date of birth at all. For IDV providers this aligns wallet-based flows with GDPR data minimisation by default, and reduces the personal data the provider needs to handle.

What the wallet does not replace

Wallet-based verification covers identity establishment for users who hold a wallet and are on a channel where they can present it. It does not replace:

• Document-based verification for users without a wallet, non-EU customers, or channels where a wallet presentation is not possible — a fallback every provider will need for years.
• Fraud and risk signals around the transaction.
• Screening and monitoring — sanctions and PEP screening, risk scoring, and ongoing due diligence remain the relying party's obligation.

The practical picture is a verification platform with the wallet as a new method among several, selected per user and per channel.

Beyond identity: the attribute verification market

At today's price per verification, a large class of checks is simply not done: they are cheaper to skip, self-declare, or accept the risk on. With a wallet presentation those checks become viable at a price point an order of magnitude lower:

• Age assurance for gambling, alcohol, adult content, social platforms and age-restricted deliveries — an "over 18" proof without any identity data, repeatable on every transaction.
• Proof of address from the PID or a residence attestation, replacing utility bills and bank statements.
• Driving entitlement — categories and validity from the mobile driving licence, for rental, mobility and delivery platforms.
• Professional licences and qualifications — medical registration, diplomas, certifications — verified at hiring or on every engagement.
• Company representation powers — who is entitled to act for which legal entity, from business-wallet credentials, for B2B onboarding and contract signing.
• Coverage, entitlement and membership — proof of insurance cover, student status, employment — issued by one party and verified by another.

Issuance: the strategic play

The clients of an identity verification provider hold some of the most rigorously verified personal and financial data in the economy. Under eIDAS 2 that data becomes issuable, and in several sectors issuance is not optional:

• Banks must issue an SCA attestation into the customer's wallet before any wallet-based Strong Customer Authentication can take place; TS12 specifies the credential and the credential format. A bank offering wallet-based SCA is an issuer and a verifier at the same time. Beyond SCA, banks might issue account-ownership and KYC attestations. See the eIDAS 2 guide for financial services for the full picture.
• Insurers can issue revocable proof of cover directly into customer wallets.
• Telecoms can issue subscriber and contract credentials that support cross-border sign-up and SIM-swap protection.
• Universities and employers issue diplomas, micro-credentials, student status and staff credentials.
• Public bodies issue official documents as PuB-EAAs with the legal weight of the paper original.

Every one of these clients faces the same build: register as an issuer in the trust infrastructure, issue via OID4VCI in the mandated formats, validate credential data against the applicable schema or rulebook, and operate revocation. Most will not build it themselves and that's where the opportunity lies.

Build vs buy: how to add EUDI Wallet support to an IDV platform

Many aspects of an IDV platform — the SDKs, the workflow engine, the UX, the case management, the risk signals, the client integrations — are where a provider differentiates and will always be built in-house. The identity layer underneath the wallet — credential formats, exchange protocols, trust-list and wallet-authenticity validation, certificate lifecycle, revocation — is standardised by definition and changes every time the EU specifications evolve. For that layer, there are three possible implementation paths:

• Build apps, buy infrastructure (recommended) — keep the platform, and embed a proven, standards-compliant identity layer for wallet issuance and verification. Fastest time to market, lowest regulatory and technical risk.
• Build apps, own infrastructure — use open-source identity infrastructure to retain full control of the stack, while still avoiding implementing the credential formats, protocols and trust validation from scratch.
• Build everything in-house — implement and maintain the full stack internally, and keep it current as the specifications evolve. Viable only for providers with a dedicated protocol engineering team.

Most providers choose one of the first two paths. The deadlines are fixed, engineers with deep experience in these protocols are scarce, and the underlying specifications are still moving.

The walt.id solution

walt.id covers both of the first two paths. The walt.id Community Stack provides open-source issuer, verifier and wallet infrastructure for providers that want to own their stack; the walt.id Enterprise Stack is the enterprise-grade platform on top of it — built on open-source technology used by more than +59.000 developers, governments and businesses. For identity verification providers specifically:

• Verifier — verify PID and any other wallet-held credential as an intermediary on behalf of clients, with trust-list resolution, revocation, holder-binding and Wallet Unit Attestation checks handled automatically.
• Issuer — issue credentials on behalf of clients — SCA attestations, proof of cover, diplomas and more — in all mandated formats (SD-JWT VC, ISO/IEC 18013-5, W3C VC), with revocation built into the issuance workflow.
• Wallet — offer a certified wallet or embed wallet capabilities into a client's app, for providers that pursue the optional wallet-provider path.

In addition, the walt.id solution:

• Works across countries and wallets — any certified EUDI Wallet. In every Member State.
• Works across industries and use cases — one deployment serves a bank, a mobility platform and an insurer alike, without a separate build per client or sector.
• Multi-tenant by design — hundreds of clients run as isolated tenants in a single Enterprise Stack deployment, each with its own keys, certificates and configuration.
• Fits the existing platform — API-first services that slot behind your existing SDK, workflow, case-management systems and integrate with different types of KMS/HSM solutions, storage solutions, and cloud providers.

A role-by-role compliance breakdown is available in the eIDAS 2 Implementers Guide, or reach out to our team to discuss embedding walt.id in your platform.

Frequently asked questions

What is an intermediary under eIDAS 2?

Under eIDAS 2, an Intermediary is a special category of Relying Party that connects other organizations (which want to be a verifier) to EUDI Wallets on their behalf, essentially acting as a bridge that absorbs the technical, legal, and operational complexity of wallet interactions. Per Article 5b(10), Intermediaries are legally prohibited from storing any data about the transaction content — they must process and forward user attributes statelessly, deleting everything immediately after passing it to the end-Relying Party. Operationally, they're also responsible for presenting their own Access Certificate alongside the specific Registration Certificate of the end-Relying Party they're serving in each transaction, so the wallet can show the user both who is asking and why.

What does an IDV provider need to build to support the EUDI Wallet?

For verification: The solution must send credential presentation requests via OID4VP or ISO/IEC 18013-7, and validate returned credentials — in SD-JWT VC, ISO/IEC 18013-5, and W3C VC formats — against the EU trusted lists, including revocation status, holder binding, and Wallet Unit Attestation checks. For issuance: Providers must additionally support OID4VCI or ISO/IEC 18013-7, using the same credential formats, and manage the revocation status for any credentials they issue.