EUDI Wallet integration: how to choose your route (2026 guide)
EUDI Wallet integration compared: four routes, what an intermediary may and may not do under Article 5b(10), the certificate model since 2026/1730, vendor questions, and what stays with you.
In short
EUDI Wallet integration is one decision before it is a technical project: who stands in front of the wallet as the relying party, you or an intermediary acting for you.[1][6]
- You always register in your own Member State and may never ask for more than you registered.[1]
- An intermediary is deemed a relying party and may not store data about the content of the transaction, which limits what a vendor acting in that role can keep for you.[1]
- Private firms under a strong authentication duty accept the wallet by 24 December 2027 (our count); micro and small enterprises are exempt.[1]
The European Digital Identity (EUDI) Wallet reaches a real deadline this winter: every Member State owes one by 24 December 2026, and the register rules for the firms that accept it apply the same day.[1][2] The question for most teams has moved from "what is it" to "how do we connect to it".
This guide compares the four routes to EUDI Wallet integration, separates what you can delegate from what stays yours, and maps each capability to the rule behind it. It reads the law in force and version 3.0.0 of the Architecture and Reference Framework (ARF), the technical blueprint, including the July 2026 changes on intermediaries.[3][6]
If you need the basics first, read EUDI Wallet relying party: registration, certificates and duties and the OpenID4VP verifier guide; for the law, eIDAS 2 explained.
Keep verifying users while you decide
Didit runs national eIDs and document checks in one workflow today, and EUDI Wallet acceptance is coming soon. Start free or talk to us about your European user base.
What an EUDI Wallet integration really has to do
There are five jobs. Someone registers the service. Someone holds the keys that prove who is asking. Someone sends the signed request. Someone verifies what comes back. Someone keeps the record. Every route splits them differently.
The ARF calls the system that talks to wallets a Relying Party Instance. In the ARF it authenticates with an access certificate whose private key "is securely stored in the hardware of the Relying Party Instance".[6] A second object, the registration certificate, states one intended use and the attributes registered for it.[1][6] A relying party puts one of these in every presentation request, by value.[7]
Where a relying party sits in the ecosystem. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
Two changes from 2026 alter the buying decision. Implementing Regulation (EU) 2026/1730 of 15 July 2026 amended the registration rules. Member States must now authorise at least one certificate authority to issue registration certificates, and issuance must be automated.[3] It also added Annex I point 16, the link to the relying party an intermediary serves, which the access certificate must carry under Annex II.[3]
The dates that set your plan
- 11 August 2026Rules amended2026/1730 in force, our count: 20 days after its 22 July publication.
- 24 December 2026Wallets dueRegistration rules of 2025/848 apply.
- 10 July 2027AMLR appliesOutsourcing and record rules apply to most obliged entities.
- 24 December 2027AcceptanceArt. 5f(2) private relying parties (our count).
- 11 August 2028Certificate checkWallets must authenticate and validate registration certificates.
Dates from Regulation (EU) No 910/2014, 2025/848, 2026/1730, 2026/1731 and the AMLR. 24 December 2027 is our count: 36 months after the implementing acts entered into force (published 4 December 2024, in force 20 days later).[1][2][3][4][5][9]
The legal trigger sits in Article 5f(2). It covers private relying parties that law or contract requires to use strong user authentication for online identification, in areas that include banking, energy and health, and it applies "only upon the voluntary request of the user".[1] Very large online platforms have a separate duty under Article 5f(3), with no separate date in the text.[1] For the full calendar, see every EUDI Wallet deadline.
The four routes to EUDI Wallet integration
The table sorts routes by who talks to the wallet, and in what legal role. Effort and control are our assessment, not a legal test.
| Route | Who faces the wallet | Certificates | Control | Effort | Usually fits |
|---|---|---|---|---|---|
| Build your own verifier | You, as relying party | You hold access and registration certificates | Highest | Highest: keys, trust lists, wallet testing | Banks and large platforms with security engineering |
| Relying party intermediary | The intermediary, on your behalf | It holds access certificates; the registration certificates are for you | Medium: set by contract | Low on protocol, new vendor oversight | Firms that want the wallet only |
| Identity or orchestration platform | Depends on the product: ask which role applies | Usually as for an intermediary on the wallet leg | Medium, across several methods | Lowest to launch, deepest dependency | Firms that need wallet, eID and document routes in one flow |
| Wallet-provider or trust-service tooling | Depends: tooling is a product, not a role | Varies | Varies by use | Depends on the use case | Signatures, attestation issuing, a parallel need beside verification |
Route 1: build your own verifier
You run the Relying Party Instance. The European Commission publishes a reference implementation with guides to build a remote verifier and a proximity verifier, and its verifier endpoint is licensed under Apache 2.0.[14][15] You still own the hardware-held keys, a certificate for each instance and service, the download of trusted lists, and the upgrades when specifications move.[6][7]
It fits large wallet volumes, or a risk team that will not let a third party see presented attributes.
Route 2: a relying party intermediary
Article 5b(10) gives this model its legal shape; the ARF spells out the rest: an intermediary is a "special class of Relying Party" that performs the relying party's tasks on its behalf, and the customer "will not need an access certificate".[6] You still register, because the intermediary must ensure that each customer is registered in the Member State where that customer is established.[7]
Route 3: an identity or orchestration platform
"Platform" is a commercial word, absent from Article 5b(10). On the wallet leg a platform is either an intermediary, with every limit that brings, or a host of your own instance. Its value is routing several methods through one integration. The risk is assuming that what a platform does for documents, such as storing evidence for years, carries over to wallets. It may not.
An open question
Is a vendor that merely hosts your instance, under your own access certificate, an intermediary. The ARF definition, a person "interacting with Wallet Units on their behalf", reads widely, and we found no text that settles it.[6] Put the question to your counsel and your registrar before you sign.
Route 4: wallet-provider or trust-service tooling
Wallet providers and trust service providers sell software too, useful when you need qualified signatures or want to issue attestations. The registration rules list those activities as separate entitlements, such as QEAA_Provider and QCert_for_ESig_Provider, next to Service_Provider for an ordinary business.[2] If the tool talks to wallets on your behalf, test it against the intermediary rules.
What stays with you, and what you can delegate
Article 5b(10)Regulation (EU) No 910/2014
"Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction."
Source: EUR-Lex, consolidated text[1]
Being "deemed" a relying party does not make your own duties vanish. Article 5b(9) makes relying parties responsible for carrying out the procedure for authenticating and validating the person identification data and attestations they request.[1] The ARF leaves the split to contract: "the intermediary and any Relying Party using its services must agree on what verifications the intermediary will carry out".[6] The registrar may ask for proof of the relationship, such as a signed contract or a mandate.[6]
| Task | Can a vendor do it | Rule |
|---|---|---|
| Decide the intended use and the data | No: your decision | Art. 5b(2)(c), 5b(3)[1] |
| Be registered in your Member State | Paperwork yes, if the registrar allows; the entry stays yours | Art. 5b(1)[1], RPI_03[7] |
| Keep the entry accurate | May help; duty stays yours | Art. 5b(6)[1] |
| Hold access certificates and send requests | Yes, as intermediary | ARF §6.6.5[6] |
| Verify authenticity, revocation, device and user binding | Yes, if agreed | RPI_09[7] |
| Pick the registration certificate for each request | You indicate it | RPI_05[7] |
| Answer user deletion requests | Support only; your contact sits in your registration certificate, and wallets send erasure requests to you | RPRC_11[7], 2024/2982 Art. 6[4] |
| Decide the risk profile and the relationship | No for AMLR obliged entities, bar one fund derogation | AMLR Art. 18(3), 18(7)[9] |
Regulated firms have three further layers. The Anti-Money Laundering Regulation (AMLR) lets obliged entities outsource tasks, but they must notify the supervisor first and stay "fully liable".[9] The Digital Operational Resilience Act keeps financial entities "fully responsible" under ICT contracts.[11] The General Data Protection Regulation (GDPR) requires processors with sufficient guarantees.[10] No text we read says whether an intermediary is a processor or a controller, so record your analysis in the contract.
How an intermediary works, and why the certificate count matters
Compares both identifiers
Shows your name to the user
Runs the agreed checks
Deletes the presentation
An intermediated presentation, simplified from ARF §6.6.5 and Topic 52.[6][7]
First, the user sees your trade name, not the vendor's, though the wallet logs the intermediary, so a user can find it later.[6] Second, the wallet compares the identifiers in the registration certificate with those in the access certificate, and the mismatch path can stop the transaction.[6] Third, the interface between you and the intermediary is out of the ARF's scope, and the ARF does not require end-to-end encryption of attributes, so the vendor may well see every attribute.[6]
The ARF's arithmetic is the point. Implementing Regulation 2026/1730 adds the link to the served relying party to the registration data, and in ARF v3.0.0 the access certificate carries that association, so to the served relying party, an intermediary "receives a separate set of access certificates for each of its intermediated Relying Parties".[3][6] A vendor that described a shared certificate model before July 2026 needs to show you its new design. Scale concentrates risk: if the Access Certificate Authority of your intermediary is suspended, its certificates are revoked, and you cannot request attributes "even though its registration is still valid".[7] You would have to move to another intermediary or wait, so an exit plan is an operational control.
Relying party authentication, the step every route must perform. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
The evidence problem: delete versus retain
Rules that say delete
Intermediary and verifier
- No stored data about transaction content (Art. 5b(10))
- Delete "completely and immediately" after forwarding (RPI_10)
- Discard signature values, salts, hashes and timestamps once no longer needed (OIA_16)
Regulation and ARF Annex 2[1][7]
Rules that say keep
Obliged entity
- Keep information obtained through electronic identification means (Art. 77(1)(a))
- Retain it for 5 years
- Show the supervisor that outsourced work mitigates your risks (Art. 18(2))
AMLR, from 10 July 2027[9]
OIA_16 tells a Relying Party Instance to discard all unique elements, a list that includes the attestation provider's signature, and not to communicate them "to the Relying Party or to any other party".[7] So a promise to keep the signed wallet response as your audit trail needs testing, whichever vendor makes it. The ARF is a framework, not a legal act, and it does not define "no longer needed" against a five-year retention duty. Ask your counsel and, if regulated, your supervisor.
Below is our suggested design, to validate, not a rule.
| Record | Held by | Basis |
|---|---|---|
| Attributes needed for due diligence | You, in your system | AMLR Art. 77[9] |
| Check log: time, method, checks run, result, certificate used | You, without unique elements | AMLR Art. 18(2), our suggestion[9] |
| Portrait, if requested at all | Not retained, unless necessary or provided by law | ARF Annex 2[7] |
| Signature, salts, hashes | Your open legal question | OIA_16[7] |
| Transaction content at the intermediary | Nobody: deleted at once | Art. 5b(10)[1], RPI_10[7] |
The capabilities a vendor must show, and the rule behind each
Use this table as the technical annex to a request for proposal, or for your own build.
| Stage | Capability | Rule or standard |
|---|---|---|
| Set-up | Registration data, including the intermediary link | 2025/848 Annex I points 14 to 16[2][3]; TS5 usesIntermediaries[8] |
| Set-up | Access certificates per instance, service and customer, hardware-held keys | ARF §3.11.3[6]; ETSI TS 119 411-8 via 2026/1730[3] |
| Set-up | Trust anchors from Trusted Lists and Lists of Trusted Entities, refreshed | OIA_12, OIA_15a[7] |
| Request | Hard block on any attribute outside the registered use | Art. 5b(3)[1]; 2025/848 Art. 9(2)(c)[2] |
| Request | The registration certificate for the current use, by value, in each request | RPRC_19[7] |
| Request | Recommended: both protocol profiles, OpenID4VC-HAIP and ISO/IEC mdoc | 2026/1731 annex to 2024/2982[5] |
| Verify | Issuer signature, by attestation type | OIA_12 to OIA_15[7] |
| Verify | Revocation check, plus a written policy when status is unknown | VCR_13, VCR_14[7] |
| Verify | Device binding and the chosen user-binding method | OIA_17, ARF §6.6.3.9[6][7] |
| After | Disposal of unique elements | OIA_16[7] |
| After | Deletion requests and contact for your data protection authority | RPRC_11, RPRC_12[7]; 2024/2982 Arts. 6, 7[4] |
| Assure | Published test results | OpenID Foundation self-certification[12] |
The OpenID Foundation opened its OpenID for Verifiable Presentations (OpenID4VP) conformance tests for self-certification on 7 August 2026, and verifiers can run them free of charge; publishing a self-certification costs a fee.[12] The Commission's Functional Conformance Assessment Framework is still "under active development", and its initial system under test is the Wallet Solution, so do not expect a relying-party badge from it yet.[13] On formats, a person identification data (PID) credential must be issued in both mdoc and SD-JWT VC, but check other attestations one by one. Our format comparison explains the difference.[7]
Illustrative design-guide screens, not a national wallet: what a user reviews before sharing. Adapted (cropped) from EUDI Wallet Architecture and Reference Framework, Annex 5, European Commission, CC BY 4.0.[16]
Wallet and non-wallet routing
Article 5a(15) says wallet use "shall be voluntary" and that it "shall remain possible to access public and private services by other existing identification and authentication means".[1] So the wallet can never be your only door. AMLR Article 22(6) likewise allows identity documents or electronic identification at level substantial or high.[9]
1Offer the methods for this country
The user chooses. A wallet request starts only on the user's request.
The wallet presentation succeeds and passes your checks
Continue
Add what the wallet does not give you.
Apply your policy
The written risk analysis decides accept or refuse.
Route on
National eID, then document with liveness.
2Screen, assess risk, decide
The same record, whichever method was used.
A routing design that keeps every door open. VCR_14 governs the status-unknown path.[1][7]
The portrait can become mandatory PID data only from 11 August 2028, and Member States may let users decline it, so a design that relies on face matching against the wallet will not always work.[5] Our post on holder binding covers when a wallet alone is enough and when to add liveness. National differences in fields and identifiers are in accepting 27+ national wallets, and the rollout status is in the country tracker. For regulated onboarding, read AMLR and the EUDI Wallet.
Design the router before the wallet arrives
You can build this path now with the methods that exist. Identity verification with Didit covers document capture, NFC chip reading, liveness and face match, with branches by country and result.[18][19]
Choosing a route by company type
Art. 5f(2): you must use strong user authentication and are not a micro or small enterprise
Acceptance duty
Plan to be live by 24 December 2027.
Optional
Unless Art. 5f(3) applies to you as a very large online platform. Registration applies if you accept.
You can run key custody, trust lists and wallet testing yourself
Build
Or keep the build as your exit from a vendor.
Use a vendor
An intermediary alone, or a platform when you also need other methods.
A starting point: your counsel and your volumes decide.[1]
| You are | Starting route | Watch |
|---|---|---|
| Bank or payment firm | Build, or intermediary with a build option | AMLR Art. 18 and the Digital Operational Resilience Act[9][11] |
| Fintech or crypto firm | Platform or intermediary | Check whether Art. 5f(2) applies; retention[1][9] |
| Very large online platform | Build or intermediary | Art. 5f(3), minimum data[1] |
| Age-gated service or small firm | Vendor, if you choose to accept | Ask only what you need; no pseudonym refusal where identification is not required[1] |
| Group in several Member States | One design, several registrations | Each entity registers where it is established[1] |
| Firm with no EU establishment | Take advice first | The texts we read describe no route; Art. 5b(1) keys to establishment[1] |
What to put to a vendor in writing
The register rules apply from 24 December 2026, so ask for the register entry behind any claim of a registered service.[2]
| Topic | Get in writing | Warning sign |
|---|---|---|
| Legal role | Its role on the wallet leg, and which registrar it files with, and when | "We are a platform, that does not apply" |
| Your registration | Who files, with what mandate, and who updates it | The entry would be in the vendor's name |
| Certificates | The model per customer since 2026/1730 | One shared certificate for all customers |
| Certificate authority | Which authorities it uses, and the plan if one is suspended | No second source, no exit |
| Checks run | A list: authenticity, revocation, device and user binding | "We verify the wallet" |
| Data visibility | Whether it sees attributes in clear | No answer |
| Deletion | How deletion is done and shown after forwarding | Presentations kept for "your audit" |
| Your records | What lands in your system, and in what form | Evidence only inside its portal |
| Scope limits | A technical block on unregistered attributes | A promise to configure carefully |
| Testing | Published results, and wallets tested by name and version | "Works with all wallets" |
| Exit | Moving to another intermediary without new user impact | Registration tied to the vendor |
What to do this month
- Confirm in writing whether Article 5f(2) or 5f(3) applies to each legal entity.[1]
- List each use case with the fewest attributes it needs.
- Find your registrar and its national registration policy.[2]
- Ask counsel about OIA_16 against your retention duties.[7][9]
- Write the policy for an unknown revocation status.[7]
- Draft the supervisor notification if an obliged entity will outsource.[9]
- Build the fallback path with the methods you have today.
Our companion post on EUDI Wallet policies and controls turns these steps into a control matrix with owners and evidence.
How Didit helps with EUDI Wallet integration
EUDI Wallet acceptance is coming soon, with no date or price yet.[17] See how we approach it on the EUDI Wallet solution page, whose wording is "Integrate today, and keep it when the wallet arrives".
What exists today is the rest of the flow in this guide. Didit runs MitID, BankID Sweden, Finnish Trust Network, Smart-ID and Mobile-ID alongside document capture, with a configured document fallback.[18] See eID verification. Workflows branch by country and result, webhooks are signed, and retention is configurable from 1 month to 10 years.[19][20][21] Didit acts as a data processor and you remain the controller.[22] Didit holds SOC 2 Type 1 and Type 2 reports, ISO/IEC 27001:2022 certification and iBeta Level 1 presentation attack detection testing.[23] For prices, see pricing.
Didit provides
- National eIDs and document checks in one workflow
- Routing branches and a document fallback
- Signed webhooks and configurable retention
Stays with you
- Your relying party registration and intended uses
- The risk assessment, policies and customer decision
- Your retention decisions and legal analysis
Build your routing before the wallet arrives
Start with national eIDs and documents in one workflow.
Key takeaways
- The real choice is who faces the wallet as relying party: you or an intermediary.
- Under Article 5b(10), an intermediary is deemed a relying party and may not store data about the content of the transaction.
- 2026/1730 puts the served customer in the access certificate; ARF v3.0.0 gives an intermediary a separate set for each customer.
- Delete rules and retention duties collide: settle OIA_16 and AMLR Art. 77 with counsel.
- Article 5a(15) keeps other means open, so design routing first.
Frequently asked questions
What is an EUDI Wallet integration platform?
It is a service that connects your application to EUDI Wallets, often next to other identity methods. The term has no legal meaning. On the wallet leg the vendor is either an intermediary or a host of your own instance, so ask which role applies.[1][6]
How do I integrate the EUDI Wallet into my service?
Register in your Member State, define each intended use and its attributes, then choose a route: your own verifier, an intermediary, a platform, or specialist tooling. Requests are signed with an access certificate and carry a registration certificate.[2][7]
What is a relying party intermediary?
It is a person or company that interacts with wallets on behalf of relying parties. Article 5b(10) deems it a relying party and forbids it from storing data about the content of the transaction.[1][6]
Do I still have to register if I use an intermediary?
Yes. The ARF requires the intermediary to ensure that each customer is registered in the Member State where that customer is established. The registrar decides how, and may let the intermediary handle the filing with proof of the relationship.[6][7]
Can my vendor keep the signed wallet response as evidence?
Treat this as an open question. An intermediary may not store transaction content, and ARF requirement OIA_16 tells verifiers to discard signature values once no longer needed. Regulated firms should settle this against AMLR Article 77 with counsel.[1][7][9]
When must private companies accept the EUDI Wallet?
By 24 December 2027 on our count of the 36 months, if law or contract requires them to use strong user authentication for online identification. Micro and small enterprises are exempt, and acceptance applies only at the user's voluntary request.[1]
Can the EUDI Wallet replace document verification?
For one customer, a qualifying wallet can stand in for the document check, but not as your only route: wallet use is voluntary and other means must stay available under Article 5a(15). The AMLR allows identity documents alongside electronic identification, so plan both.[1][9]
Does Didit accept EUDI Wallets today?
No. EUDI Wallet acceptance is coming soon, with no date or price yet. Today Didit runs national eIDs and document checks in one workflow.[17][18]
Sources
- Regulation (EU) No 910/2014, consolidated text of 18 October 2024, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/848, registration of wallet-relying parties, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1730 of 15 July 2026, EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2982, protocols and interfaces, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1731 of 15 July 2026, EUR-Lex.
- Architecture and Reference Framework v3.0.0, European Commission, July 2026.
- ARF v3.0.0, Annex 2, high-level requirements by topic, European Commission.
- Technical Specification 5, relying party registration formats and API, European Commission.
- Regulation (EU) 2024/1624 (AMLR), EUR-Lex.
- Regulation (EU) 2016/679 (GDPR), EUR-Lex.
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex.
- OpenID4VP and OpenID4VCI conformance tests are complete and open for self-certification, OpenID Foundation, 7 August 2026.
- Functional Conformance Assessment Framework, EUDI Wallet project.
- EUDI Wallet Reference Implementation documentation, European Commission.
- EUDI verifier endpoint repository, Apache License 2.0.
- ARF v3.0.0, Annex 5, design guide for data sharing scenarios, European Commission.
- EUDI Wallet, Didit solution page.
- Digital ID wallets, Didit documentation.
- Workflow builder, Didit documentation.
- Webhooks, Didit documentation.
- Data retention, Didit documentation.
- Security and compliance, Didit documentation.
- Certifications, Didit documentation.
The route you pick today should survive a change of vendor, a late national wallet and a retention audit. Follow the rollout and how Didit approaches acceptance on the EUDI Wallet solution page.
Get your identity flow ready for every route
Verify users with national eIDs and documents today, in one workflow.
Articles relacionats
- Law 25 del Quebec i biometria: guia de verificació d'identitat (2026)
- Requisits KYC de FINTRAC per a MSB de criptoactius i pagaments (2026)
- EUDI Wallet readiness: policies and controls for regulated firms
- EUDI Wallet holder binding: what a presentation really proves
- EUDI Wallet cross-border acceptance: one integration across the EU
- Verificació d'edat al Canadà: S-209, C-34 i què cal fer ara