eIDAS 2 for Identity Orchestration Platforms

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 orchestration platforms can occupy: 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 orchestration platforms

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 orchestration platforms:

1. A new node in every journey. The wallet can sit wherever an identity source sits today: as a login method, as the identification step in onboarding, as a step-up factor, or as an attribute check mid-flow — returning government-issued, cryptographically verified data.
2. The obligation lands on clients — inside the journeys the platform runs. The banks, telecoms, insurers, platforms and public services that must accept the wallet by the end of 2027 (public sector: end of 2026) build their login and onboarding flows in an orchestration platform — and will expect a wallet node there.
3. A formal role in the trust ecosystem. eIDAS 2 defines intermediaries — parties that interact with wallets on behalf of relying parties. An orchestration platform that hosts the wallet connection for its clients can operate inside the regulation as a registered intermediary.
4. Authentication, not just verification — and issuance. The wallet goes beyond one-off ID checks: it's a passwordless login mechanism, a holder of bank-issued SCA credentials, and — since journeys can issue credentials as their output — a building block for the journeys that follow.

The compliance timeline is compact:

The roles identity orchestration platforms can play under eIDAS 2

Every digital identity ecosystem has three actors — issuer, verifier, and wallet provider. An orchestration platform plays them on behalf of its clients, inside the journeys it runs — and for the verifier role, eIDAS 2 gives that position a name: the intermediary.

Intermediary: the core role

As an intermediary, an orchestration platform 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.

Orchestration platforms already abstract identity sources behind connectors on behalf of many relying parties; the wallet is one more source behind the same abstraction

Whether the platform or its client is the relying party depends on who hosts the wallet connection — see the FAQ below.

Issuance enabler: the strategic role

Under eIDAS 2, any business can become an issuer — and many orchestration clients will have to. A bank cannot offer wallet-based Strong Customer Authentication until it has issued an SCA attestation into the customer's wallet; an employer that wants staff to log in with a wallet needs to issue the employee credential first. In every case the issuance belongs at the end of a journey the platform already runs.

Wallet provider: the optional role

An orchestration platform can provide the capabilities for clients to build or embed wallet capabilities into their own applications.

Core eIDAS 2 use cases for orchestration platforms at a glance

The wallet as a journey node

An orchestration platform lives on connectors: every identity source, risk signal and verification service is a node with inputs, outputs and a configuration. The EUDI Wallet fits the same model.

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 presentation 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.

Three ways to wire the node

How the wallet node connects to the rest of the platform depends on what the journey needs from it:

1. As an OpenID Connect identity provider. Every orchestration platform can federate to an OIDC IdP; it is how social logins, enterprise SSO and national eID schemes are connected today. Exposed as an OIDC IdP, the wallet becomes a login and identification method without protocol work: the platform redirects to the IdP, the user presents a credential, and the platform receives an ID token with the verified attributes as claims.
2. As a verification step with an API. Where the journey needs more than a login — a specific credential mid-flow, an "over 18" proof, a transaction-bound SCA presentation, or a decision based on which credential the user holds — the node calls a verifier API directly, receives the result via webhook, and branches on it.
3. As an issuance step with an API. At the end of onboarding, hiring or contracting, the node calls an issuer API to place a credential into the user's wallet.

What the wallet does not replace

The wallet is a node, not the journey. It does not replace:

• Fallback methods for users without a wallet, non-EU users, or channels where a wallet presentation is not possible.
• Risk and fraud signals and the policy engine that combines them with the wallet result.
• Session, consent and account management — the wallet establishes who the user is; the platform decides what that means for the account.

Beyond login: what the wallet adds to a journey

Once government-verified attributes are one node away, a set of journeys becomes possible that was not before:

• Passwordless login. A PID or client-issued credential bound to the wallet's secure keys replaces the password and the SMS code.
• Onboarding without a document check. For wallet holders, identification is one presentation instead of capture, liveness and review.
• Step-up with proof instead of friction. "Over 18" before a purchase, a driving category before a rental, professional registration before a clinical action, company representation powers before a contract — with nothing else disclosed.
• Wallet-based Strong Customer Authentication. Under TS12, banks issue an SCA attestation into the customer's wallet and verify it, bound to the transaction, at payment and login; see the eIDAS 2 guide for financial services.
• B2B journeys with business wallets. Legal Person Identification Data and company credentials let a journey verify which organisation the user may act for.
• Cross-border by default. A credential from any Member State verifies the same way, so a journey built once works for every EU user.

Issuance as a journey step

The clients of an orchestration platform already run the journeys in which verified facts are established: a customer is onboarded, an employee is hired, a contract is signed, a policy is bound. Under eIDAS 2 the outcome of those journeys can be issued into the user's wallet, and in several sectors it must be:

• 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. Beyond SCA, banks might issue account-ownership and KYC attestations.
• Employers issue employee credentials that then serve as the login method for the workforce journeys the platform runs.
• Insurers issue revocable proof of cover; telecoms issue subscriber credentials; universities issue diplomas and student status; public bodies issue official documents as PuB-EAAs.

A credential issued at the end of one journey becomes the accepted input of the next — the employee credential logs the user in, the KYC attestation shortcuts the next product's onboarding, the SCA attestation authorises the payment.

Every issuing client 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 orchestration platform

The journey builder, the connector framework, the policy engine, the SDKs and the client integrations are where an orchestration platform differentiates and will always be built in-house. The identity layer underneath the wallet node — 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 verification and issuance behind the connector. 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 platforms with a dedicated protocol engineering team.

Most platforms 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 platforms 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 orchestration platforms 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; request specific credentials and attributes with DCQL and deliver results via REST and webhooks so the journey can branch on them.
• Issuer — issue credentials on behalf of clients — SCA attestations, employee credentials, 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 — embed wallet capabilities into a client's app, for platforms that pursue the optional wallet-provider path.

In addition, the walt.id solution:

• Exposes the wallet as an OpenID Connect identity provider — the Enterprise Stack's OIDC Bridge turns wallet verification into a standard OIDC IdP that any OIDC-capable platform or IAM system (Keycloak, Ory, Auth0, Okta, Microsoft Entra ID and others) federates to like any other identity source.
• Works across countries and wallets — any certified EUDI Wallet. In every Member State.
• Works across industries and use cases — one deployment serves a bank's SCA journey, a retailer's age check and an employer's workforce login alike.
• 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.
• Deploys the way clients do — the same stack runs as a hosted service or inside a client's own environment, integrates with different types of KMS/HSM solutions, storage solutions and cloud providers, and sits behind existing API gateways.

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 an orchestration platform.

Frequently asked questions

Is an identity orchestration platform an intermediary under eIDAS 2?

It depends on who hosts the wallet connection. If the platform's own infrastructure interacts with wallets on behalf of its clients, the platform is an intermediary under Article 5b(10): it is deemed a relying party, registers itself and its clients' intended uses, presents its own access certificate alongside the client's registration certificate in each transaction, and must not store the content of the transaction. If the wallet connection runs inside the client's environment, the client is the relying party and the platform is a software supplier.

Can the EUDI Wallet be used as an OpenID Connect identity provider?

Not natively — the wallet protocols (OID4VP, ISO/IEC 18013-7) are not OIDC. But a bridge component can expose wallet verification as a standard OIDC identity provider, so any OIDC-capable orchestration or IAM system can add wallet login and identification without implementing the wallet protocols. walt.id provides this with the Enterprise Stack's OIDC Bridge: the platform redirects the user to it, the user presents a credential, and the platform receives an ID token with the verified attributes as claims.