eIDAS 2 for Biometrics Companies

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.

For biometrics companies that serve banks, telecoms, insurers and public bodies directly, the wallet is a new authentication and identification method those clients must offer — and, before any of that, a credential that every PID provider must establish the user's identity for. Next to this, the regulation formalises a role that vendors verifying on behalf of their clients can fill: the intermediary, a registered party that connects to wallets on behalf of relying parties.

What eIDAS 2 changes for biometrics companies

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 biometrics companies:

1. A new authentication and identification method next to biometrics. Where a user holds an EUDI Wallet, login, step-up and identity establishment can be a single credential presentation: the user shares a PID or another credential, and the verifier validates it cryptographically in seconds. It sits beside biometric authentication as one more method a client offers, selected per user and per channel.
2. Customer demand from every regulated sector. The banks, telecoms, insurers, platforms and public services that make up the biometrics customer base must accept the wallet by the end of 2027 (public sector: end of 2026).
3. A formal role in the trust ecosystem. eIDAS 2 defines intermediaries — parties that interact with wallets on behalf of relying parties. A biometrics vendor that verifies wallet credentials for its clients can operate inside the regulation as a registered intermediary.
4. Identity proofing at the start of the wallet — and issuance at the end of the journey. Before a PID provider can issue a PID, it must verify the user's identity at Level of Assurance High. At the same time, the clients that hold verified customer data — banks, insurers, employers — gain the ability to issue credentials of their own, and will need someone to build it.

The compliance timeline is compact:

The roles biometrics companies can play under eIDAS 2

Every digital identity ecosystem has three actors — issuer, verifier, and wallet provider. A biometrics vendor 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, a biometrics vendor 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 a direct extension of what an authentication vendor already is for its clients — the party that takes the "who is this user" problem off their hands — with the wallet added as one more method. Second, it is use-case-independent: the same verification solution serves a PID for a bank's onboarding, an SCA attestation for a payment, an "over 18" proof for a platform, and a company credential for a B2B login.

Issuance enabler: the strategic role

Under eIDAS 2, any business can become an issuer — and a PID provider cannot issue at all until the user's identity has been verified. For a biometrics vendor, issuance therefore starts one step earlier than for other providers: the identity proofing that precedes PID issuance. Beyond that, many clients will have to issue: 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; employers will issue staff credentials that the vendor's authentication then verifies.

Wallet provider: the optional role

A biometrics vendor can provide the capabilities for clients to build or embed wallet capabilities into their own applications.

Core eIDAS 2 use cases for biometrics companies at a glance

The wallet as an additional authentication method

Today a biometrics vendor's clients authenticate users with a face or fingerprint match against an enrolled template, and identify new users with a document check and a liveness-backed match. With the EUDI Wallet, both can also be 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 template to match against 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.

Authentication, not only identification

The wallet is not limited to establishing identity once. A PID, or a credential a client has issued into the wallet, is bound to the wallet's secure keys and can be presented at every login and every step-up — a passwordless factor at Level of Assurance High. For banks, TS12 specifies exactly this: an SCA attestation issued into the wallet and verified, bound to the transaction, at payment and login. For a biometrics vendor this means the wallet joins the authentication catalogue it already offers, with the policy engine deciding per user, channel and risk level which method applies.

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 biometrics vendors this aligns wallet-based flows with GDPR data minimisation by default, and reduces the personal data the vendor needs to handle.

What the wallet does not replace

Wallet-based authentication and identification cover users who hold a wallet and are on a channel where they can present it. It does not replace:

• Biometric authentication and identification for users without a wallet, non-EU customers, or channels where a wallet presentation is not possible — the method every client 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 an authentication platform with the wallet as a new method among several, selected per user and per channel.

Identity proofing for PID issuance

Every EUDI Wallet starts with a PID, and every PID starts with identity proofing: The PID provider must verify the user's identity at Level of Assurance High before it issues. Member States will lean on their existing electronic identification means where they can — but not every citizen holds one, not every eID covers remote activation, and not every Member State has one at the required level.

Where the existing eID does not reach, the PID provider needs an identity proofing process that establishes a person's identity at Level of Assurance High remotely, at scale, from the end of 2026 — which is a capability biometrics companies already operate for their clients today.

Issuance: the strategic play

The clients of a biometrics company 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:

• PID providers issue the PID itself once identity has been established — the entry point of every wallet, covered above.
• 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. See the eIDAS 2 guide for financial services for the full picture.
• Employers and public bodies issue staff and citizen credentials that then serve as the authentication factor for the very journeys the vendor secures today.
• Insurers and telecoms issue proof of cover and subscriber credentials directly into customer wallets.

Every one of these issuers faces the same build: register 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 a biometrics platform

Many aspects of a biometrics platform — the matching engines, liveness detection, the SDKs, the policy engine, the client integrations — are where a vendor 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 vendors with a dedicated protocol engineering team.

Most vendors 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 vendors 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 biometrics companies 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, and results delivered via REST and webhooks into the existing policy engine.
• Issuer — help clients issue credentials — PID for PID providers, SCA attestations, staff credentials, proof of cover and more — in all mandated formats (SD-JWT VC, ISO/IEC 18013-5, W3C VC), with revocation built into the issuance workflow.
• Wallet — embed wallet capabilities into a client's app, for vendors 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 PID provider and an employer 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 the existing SDK, policy engine and client integrations, 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 a biometrics 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.

Does the EUDI Wallet replace biometric authentication?

No. It adds a further method: for users who hold a wallet and can present it, a PID or a client-issued credential bound to the wallet's secure keys serves as a passwordless factor for login, step-up and identification. Biometric authentication remains the method for everyone else and every other channel, and identity proofing — establishing who a person is before a PID or another credential is issued — is where biometric verification sits at the very start of the wallet lifecycle.

What does a biometrics company 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, using the same credential formats, and manage the revocation status for any credentials they issue.