What capabilities should an identity orchestration platform provide for EUDI Wallet adoption? | Identity Infrastructure Explained

An identity orchestration platform is ready for EUDI Wallet adoption when it provides five capabilities: connectivity to every certified wallet, routing that picks the right method for each user, a defined fallback sequence when the wallet path fails, credential handling that keeps signed data structured, and the ability to add the next wallet or method without a rebuild. Authologic's eID-native identity infrastructure is built around these five capabilities.

Written by Florentyna Frend (Head of Product), Authologic.

Title card reading "Orchestration for EUDI Wallets" with the line "Identity Infrastructure Explained"

Key takeaways

Wallet support depends on architecture. A stack built around document scans handles signed wallet credentials as a special case, while an eID-native stack treats them as one more source of verified attributes.
Routing decides which method each user sees, and fallback decides what happens when that method fails. Together they determine whether wallet acceptance converts.
Fallback matters most while adoption is low: from 24 December 2027, private relying parties, except micro and small enterprises, that are required by law or contract to use strong user authentication for online identification must accept the wallet (Article 5f(2) eIDAS), in areas such as banking and financial services, transport, energy and telecommunications. Many users will not have a wallet for years.
Each Member State must provide at least one certified wallet and can build, mandate or recognise more, so the number of wallets a relying party meets will grow. By mid-September 2026, only 3 Member States had made a wallet available, and Euronews reported that 24 of 27 would miss the 24 December 2026 deadline.
The test of every capability is the same: can you add the next identity method, eID scheme or credential type without rebuilding what already works?

Why does EUDI Wallet support start with architecture?

Most identity stacks grew up document-first: photograph an ID, run OCR, check liveness, and add individual eIDs as they arrive. An EUDI Wallet presents structured, cryptographically signed credentials, which turns identity verification from an error-prone, probabilistic scan into an instant, tamper-proof cryptographic check.

An eID-native architecture puts government eIDs and wallets on the primary verification path and keeps the document check as a fallback for users and markets without an eID. The order of the two paths decides how much of the stack still works once wallets arrive.

	Document-first stack	eID-native stack
Primary input	Image of a document plus a selfie	Structured, signed credential (PID, mobile driving licence (mDL), photo ID and other credentials)
Wallet support	Added as another capture method and used mainly as a fallback to retrieve supplemental data	Native path; the wallet is one more source of signed attributes
Fraud surface	ID images can be generated by AI, so detection is an arms race	A credential cannot be forged without the issuer's private key, and cryptographic holder binding prevents it from being used if intercepted
AML evidence	Built on the document route of Article 22(6) AMLR	Built on the electronic identification route of Article 22(6) AMLR, which includes the EUDI Wallet
Adding the next method	New capture flow and new review logic	Configuration: a new source of attributes in the same model

Article 22(6) of the AMLR recognises two routes for remote identification: an identity document together with information from reliable and independent sources, or electronic identification at substantial or high assurance together with relevant qualified trust services. The EUDI Wallet is a means of electronic identification within the second route. AMLA's draft technical standards, sent to the European Commission on 1 October 2026, make electronic identification, as a rule, the default option at remote onboarding, with document checks as a fallback that the obliged entity has to justify. The draft does not apply yet, and the Commission can still amend it. What the draft expects is covered in How to verify customers remotely under AMLR.

What does routing across wallets, eIDs and document methods look like?

Routing means the platform chooses the verification path for each user instead of showing everyone the same flow. The choice runs on a small set of signals:

Routing signal	What it determines	Example
User's country and available methods	Which national eID, wallet or bank identity can serve the user	On Authologic's platform, a Danish user is first checked for a credential in an AltID wallet; a user without one is offered MitID
Required assurance level	Which methods meet the use case	Remote onboarding under the AMLR points to electronic identification at substantial or high assurance
Method availability	Whether the preferred method is working	During a provider outage, users are sent to another method in line with the flow agreed with the customer, instead of stopping
Wallet credential availability	Whether the user holds a usable wallet credential	A user without a wallet goes straight to the national eID
Conversion	Which path completes most often for the segment	Where two methods qualify, the one that converts better goes first

Routing is what makes a platform with 140+ identity methods usable: each user sees one path instead of a menu. Routing and fallback are defined in the Identity Orchestration Glossary. How to choose methods for each country, starting from the data you need, is covered in How do you choose identity verification methods for each country?

Why does fallback matter so much during wallet adoption?

Wallet acceptance becomes mandatory on 24 December 2027, but for years many users will reach onboarding without a usable wallet: they have no wallet yet, hold an expired credential, come from a Member State whose wallet launched late, or meet an outage. A platform that treats these cases as errors turns a compliance obligation into lost customers.

Failure scenario	Without fallback	With a defined fallback sequence
User has no wallet	The flow ends with no alternative method; the user has to leave, install a wallet and start again	User is sent to the national eID, bank identity or another eID, and finally to document verification
Wallet credential expired	Error message and abandoned onboarding	User is sent to another method; credential renewal and re-issuance happen separately
Wallet provider outage	No wallet user can complete onboarding	Users are rerouted to another method in line with the flow agreed with the customer

What happens when a provider behind a method goes down, and who decides where users are sent, is covered in What happens when an identity verification provider goes down? Questions 6 and 14-16 of the EUDI Wallet Readiness Checklist test the same area.

What does multi-wallet readiness mean?

Under Article 5a of eIDAS, each Member State must provide at least one wallet, and wallets built independently of the state can also be recognised. Such private wallets can become an important part of the ecosystem. A relying party therefore meets more than one wallet per country over time, each certified against the same rules.

In the Netherlands, where the government wallet has been postponed to late 2027, a coalition of Dutch companies including ABN AMRO, Rabobank and KPN announced in October 2026 that it is developing MyCheck, an independent wallet, and offered to work with the government on its introduction. The roles in the wallet ecosystem are defined in the Digital Identity Glossary.

Wallet type	Who provides it	Integration implication
State wallet	Member State directly, or an organisation it mandates	The baseline: at least one certified wallet per country
Recognised private wallet	Private provider whose wallet the Member State recognises, certified as an EUDI Wallet	Often the same credentials and protocols; the number of wallets grows over time
Platform wallet (e.g. Apple Wallet, Google Wallet, Samsung Wallet)	Existing mobile wallets adding identity credentials	Large installed user bases, though not every credential is supported; differences between platforms have to be handled and maintained

Multi-wallet readiness means the platform verifies credentials from any certified wallet through the common protocols, such as OpenID for Verifiable Presentations or ISO/IEC 18013-5 and ISO/IEC 18013-7, instead of maintaining one integration per wallet. How to check a platform's interoperability, including conformance tests, is covered in Which identity orchestration platforms support EUDI Wallet integration? Authologic's partnership with Google, a platform wallet provider, is described in Google Wallet credentials for businesses.

How do you test an orchestration platform's EUDI Wallet capabilities?

Capability	What it must do	How to test it
Multi-wallet connectivity	Verify credentials from every certified wallet through the common protocols	Run a test presentation from at least 2 different wallets (or national reference apps) and review the verifier's conformance test results
Routing	Choose the method per user from country, assurance, availability and conversion signals	Change session parameters (such as the user's country or the required level of assurance) and confirm the platform serves the right path without code changes
Fallback sequencing	Move the user to the next method when a path fails, inside one flow	Trigger a wallet failure (cancel the presentation or simulate a timeout) and check that the user is immediately routed to another eID or to document verification
Credential handling	Consume PID and other credentials as a structured list of attributes with selective disclosure	Review the API response and the audit trail: selectively disclosed attributes and cryptographic proofs are handled natively, not forced into a document-shaped schema
Extensibility	Add a wallet, eID scheme or new credential type without a rebuild	Confirm in the sandbox that enabling a new method or credential needs only configuration, not a code-level redeployment

Which certifications and test reports to ask the same provider for is covered in Which certifications should an identity verification provider hold in the EU?

Authologic provides routing, fallback sequencing, credential handling and extensibility in production across 140+ identity methods, and verifies EUDI Wallet credentials in some national test environments today, ahead of the national registers opening on 24 December 2026. How relying parties register, directly or through an intermediary, is covered in What is a relying party intermediary under eIDAS 2.0?

FAQ

What capabilities should an identity orchestration platform provide for EUDI Wallet adoption?

Five: connectivity to every certified wallet through the common protocols, routing that picks a method per user, a defined fallback sequence when the wallet path fails, credential handling that keeps signed attributes structured, and the ability to add the next wallet, eID scheme or credential type without a rebuild. Wallet protocols alone cover only the first of the five.

What is an eID-native architecture?

An eID-native architecture is an identity stack built around government eIDs and wallets as the primary verification method, with document scans as the fallback. The order matters because wallets deliver structured, cryptographically signed data, which a stack built around images has to handle as a special case.

Do orchestration capabilities matter before wallets reach mass adoption?

Orchestration capabilities matter more while adoption is low. For years after 24 December 2027, most users will still need an onboarding path other than the wallet, while AMLA's draft technical standards under the AMLR make electronic identification the default option at remote onboarding. Routing and fallback therefore decide whether wallet acceptance brings customers through onboarding or loses them.