EUDI Wallet readiness: policies and controls for regulated firms
The EUDI Wallet readiness guide for regulated firms: 13 control domains, a control matrix with owners and evidence, an AMLR Article 22 map and a plan to 24 December 2027, based on the July 2026 amending acts and ARF v3.0.0.
In short
EUDI Wallet readiness means more than a technical integration. Before a regulated firm accepts European Digital Identity (EUDI) Wallets, it needs written policies and working controls across 13 domains, from registration and certificates to data minimisation, fraud, records and incidents.[1]
- Private firms above small-enterprise size that need strong user authentication, by Union or national law or by contract, accept the wallet at the user's request by 24 December 2027 (computed from Art. 5f(2)).[1]
- Registration creates transparency, not approval. You may not request data beyond what your registration indicates.[1][12]
- Several checks are only recommended in the Architecture and Reference Framework (ARF) v3.0.0, so your policy decides them.[12]
The harder question sits with compliance, security and product teams: what must be written down, owned and evidenced on the day the first wallet presentation reaches production.
This guide reads the primary texts as of 31 October 2026, including the two July 2026 amending acts, and turns them into a control matrix and a dated plan for banks, payment firms, insurers and telecoms. For the role itself, start with EUDI Wallet relying party: registration, certificates and duties. To choose your architecture first, read how to choose how you integrate the EUDI Wallet.
Keep a working route while you prepare
You need a non-wallet route in any case. Didit runs national electronic IDs and document verification in one workflow today, and EUDI Wallet acceptance is coming soon. See the EUDI Wallet page.[23]
EUDI Wallet readiness in 2026: what changed this summer
Three recent facts matter.
- Registration certificates are now the rule. Implementing Regulation (EU) 2025/848 first said Member States "may authorise" a certificate authority for them. Implementing Regulation (EU) 2026/1730 replaced that with "shall authorise", and with issuance "in an automated manner and without undue delay after the registration".[3][4]
- The portrait has its own rule. Implementing Regulation (EU) 2026/1731 limits when you may keep it, and wallets must warn users that the request "involves the sharing of biometric data".[6]
- Intermediaries are now traceable. Annex I of 2025/848 gains a point 16 that links an intermediary to the relying party it serves.[4]
- 22 July 2026Amendments2026/1730 and 2026/1731 published; in force 11 August 2026 (computed).
- 24 December 2026Wallets dueRegistration rules apply.
- 10 July 2027AMLR appliesArt. 22 and Art. 77 bind obliged entities.
- 24 December 2027AcceptanceIn-scope private firms, at the user's request.
- 11 August 2028Next stepPortrait in the mandatory set; wallets check registration certificates.
The wallet and acceptance deadlines are computed from 24 December 2024. The application dates of 2025/848, the AMLR and the 2028 rules are written in the acts.[1][3][6][10] See EUDI Wallet deadlines for 2026 and 2027.
First decide whether the acceptance duty applies
Your policy should open with a dated scope decision, signed by legal, because Article 5f(2), inserted by Regulation (EU) 2024/1183, has conditions.[1][2]
| Test | Question for your scope memo | Source |
|---|---|---|
| Size | Are we above a small enterprise under Recommendation 2003/361/EC | Art. 5f(2)[1] |
| Trigger | Does Union or national law, or a contract, require strong user authentication for online identification | Art. 5f(2)[1] |
| Sector | The named areas follow "including", so they are examples | Art. 5f(2)[1] |
| Platform | Are we a very large online platform that requires user authentication | Art. 5f(3)[1] |
| Voluntary use | Do we need a route for the user who declines a wallet (always yes) | Art. 5a(15)[1] |
Even out of scope, Article 5b binds any relying party using wallets.[1]
The EUDI Wallet control framework at a glance
Sort every requirement into three groups. Most gaps sit in the third.
Binding law
You must
- Register and keep it current
- Request only registered data
- Authenticate and validate the data
Art. 5b eIDAS, 2025/848
ARF guidance
You are advised to
- Check revocation status
- Verify device binding
- Refresh trust anchors regularly
ARF v3.0.0, section 6.6.3
Your risk appetite
You decide
- When to step up
- What to do when status is unknown
- What evidence to keep
Your internal policy
Three layers of obligation. The ARF is a framework, not a legal act.[1][3][12]
The 13 control domains
1. Governance and ownership
Name one accountable owner and a written policy that ties legal, compliance, security, product and support together. Registrars can suspend or cancel you over inaccurate data, breach of the registration policy, over-asking or other breaches of law, and a supervisory body can request it, so this is an operational risk too.[3] Control changes to the attribute list.
2. Registration and intended uses
You register in the Member State where you are established.[1] List each intended use with the data it needs: Annex I asks for that per use, in machine-readable form, plus a description of each use.[3] Under the ARF, a single relying party "may register multiple times", which suits firms with different services.[12]
Registration is not approval
The ARF is explicit: registration "does not imply that the Registrar (or any other entity in the EUDI Wallet ecosystem) authorises" the request.[12] Registrars collect intended uses and attributes "only for the purpose of transparency", with no preauthorisation.[4] Never tell a regulator or customer that your data use was approved through registration.
Changes must reach the register "without undue delay", and when you stop a use you must request cancellation.[3]
3. Certificate lifecycle: keys, renewal, revocation
Your service proves who it is with an access certificate, which signs each presentation request. In the ARF, the access certificate authority issues one "to each Relying Party Instance of the Relying Party", and a fallback system for business continuity is an instance too, so it needs its own.[12] Treat these as production secrets: inventory, hardware protection, rotation and named custodians are your policy, since the texts set no key rules for relying parties.
Relying Party authentication. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0. Figure 13, unchanged.
The certificate carries your name, identifiers and contact details, and its provider must revoke it when content "is no longer accurate and consistent" with the register.[3] So a rebrand or new support address can break production. You may also request revocation yourself, and status must be published within 24 hours of the request.[3]
4. Data minimisation
Article 5b(3)Regulation (EU) No 910/2014
"Relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, point (c)."
Source: EUR-Lex, consolidated eIDAS[1]
Review each field with your data protection officer. Article 5(1)(c) of the General Data Protection Regulation (GDPR) applies alongside this rule, so a registered attribute still has to be necessary.[13] Requesting more than registered is an express ground for suspension.[3] The European Data Protection Supervisor (EDPS) warns of "a propensity of certain relying parties towards over-asking".[15]
Ask for age_over_18-style attributes where a yes or no is enough, do not refuse pseudonyms where identification is not legally required, and add an automated test that fails a release if a request exceeds the registered list.[1]
Registration certificate verification. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0. Figure 14, unchanged.
Member States must ensure wallet providers inform users when a request goes beyond the registration certificates.[4] The wallet's own duty to validate your registration certificate applies from 11 August 2028.[6][7] Article 5b(3) binds you from the start.[1]
5. Trust checks
Article 5b(9) makes relying parties "responsible for carrying out the procedure for authenticating and validating person identification data and electronic attestation of attributes requested from European Digital Identity Wallets".[1] The ARF then separates what you verify from what you trust.
| Check | ARF v3.0.0 status | Suggested policy |
|---|---|---|
| Issuer signature | Performed by the relying party, using Trusted Lists or Lists of Trusted Entities (6.6.3.6) | Mandatory; refuse on failure |
| Trust anchors | "regular trust anchor management" (6.6.3.6) | Scheduled refresh, with an alert on failure |
| Revocation | "recommended but not mandatory" (6.6.3.7) | Mandatory for regulated flows |
| Device binding | "recommended but not mandatory" (6.6.3.8) | Mandatory; relying on wallet authentication implies it (6.6.3.9) |
| Wallet unit status | No direct check: trust the issuer (6.6.3.11, 6.6.3.12) | For a PID, rely on PID revocation; assess each attestation type |
The "suggested policy" column is our reading, not a rule.[12]
Where no reliable status information exists, the ARF says "a Relying Party performs a risk analysis considering all relevant factors for the use case, before taking a decision to accept or refuse the PID or attestation."[12] Write it down in advance. Implementation detail is in the OpenID4VP verifier guide; format differences are in SD-JWT VC vs mdoc. National variation is covered in accepting 27 national wallets as one integration.
6. Assurance mapping
Wallets are provided under a scheme at assurance level high.[1] Record what that settles. In our reading, it covers enrolment and how the means is protected. It does not establish beneficial ownership, sanctions status, or that the same person is behind every later action.
7. Fraud and step-up
1Validate the presentation
Signature, trust anchor, device binding.
Status is valid and the risk score is within appetite
Accept
Log the decision.
Step up
Liveness with attack detection, and face match.
Fall back
Offer another route.
2Continue due diligence
Missing attributes, screening, risk rating.
A sample decision policy. The thresholds are yours to set.
The ARF notes that a relying party can trust wallet authentication, or add its own check. Portrait matching by selfie needs "an approved liveness detection mechanism" and injection attack detection, "in particular deepfake detection".[12] A wallet is a strong signal at onboarding, not proof of who acts on the account next month. Our guide to the possession problem and holder binding sets out the threats and step-up triggers.
8. Fallback when there is no wallet
Article 5a(15)Regulation (EU) No 910/2014
"The use of European Digital Identity Wallets shall be voluntary. Access to public and private services, access to the labour market and freedom to conduct business shall not in any way be restricted or made disadvantageous to natural or legal persons that do not use European Digital Identity Wallets. It shall remain possible to access public and private services by other existing identification and authentication means."
Source: EUR-Lex, consolidated eIDAS[1]
A wallet user may fail mid-flow, or a wallet may be suspended. Define alternative routes with equal pricing, speed and service, and test that declining a wallet never worsens the offer. The fallback may carry most volume. Our country launch tracker shows which wallets exist.
9. Customer support
Users see your name and the requested attributes in the wallet, and a transaction log that lists identifiers without values.[12] They can send erasure requests from the wallet, and report you to a data protection authority even if no attributes were presented.[1][12] No standard protocol exists for erasure: the wallet opens your web form, email or phone, using contact details in your registration certificate, so a new support address means a register and certificate update.[3][12] Those channels must be monitored and reach your privacy team.
10. Records and evidence
Each decision should leave evidence: request, intended use, certificate version, check results, policy version, outcome. Log attribute identifiers; keep values only where a duty applies. For obliged entities, Article 77 of the Anti-Money Laundering Regulation (AMLR) expressly covers "information obtained through electronic identification means".[10]
- Period: 5 years from the end of the relationship, the occasional transaction or the refusal, then delete, subject to other laws.[10]
- Reference instead of copy: allowed if you can provide the information immediately and it cannot be altered, and your Article 9 procedures define this.[10]
- Identity matching logs: 2025/846 sets 6 to 12 months for security purposes, but it addresses public sector bodies, and private parties only where Member States enable it.[8]
11. GDPR: DPIA, retention, processors
Article 35 requires a data protection impact assessment where processing, "in particular using new technologies", is likely to result in a high risk.[13] Run the screening now and record the result. Recital 9 of 2025/848 adds that relying parties should declare whether they intend to rely on electronic identification to meet an Article 6(1) GDPR requirement; record that in your registration file.[3]
Article 3a(3)Implementing Regulation (EU) 2024/2977, inserted by 2026/1731
"The portrait shall not be retained by wallet-relying parties unless its processing is necessary for the purposes of identification and authentication in compliance with Union data protection law or where this is provided for by Union or national law, in compliance with Union data protection law."
Set a default of verify and discard for the portrait, with a written exception where a law requires retention. Provide a privacy policy URL per intended use, since Member States must ensure you provide one.[4] Review every processor under Article 28.[13]
12. AMLR Article 22 mapping
Article 22(6)(b) accepts electronic identification at level substantial or high as a means of verification.[10] A wallet does not supply the whole Article 22(1) data set, as this map shows. See the AMLR and the EUDI Wallet for the legal analysis.
| AMLR Art. 22(1)(a) | PID attribute | In the PID | Your control |
|---|---|---|---|
| Names and surnames | family_name, given_name | Mandatory | Take from the wallet |
| Place and date of birth | birth_place, birth_date | Mandatory | Check format and precision |
| Nationalities | nationality | Mandatory | Refugee or stateless status by other means |
| National ID number | personal_administrative_number | Optional | Collect by other means if needed |
| Usual residence | resident_address | Optional | Plan for it to be absent |
| Tax number, where available | Not in the mandatory set | No | Ask the customer |
Attributes from the annex to 2024/2977 as replaced in July 2026, for natural persons.[5][6][10]
The Anti-Money Laundering Authority (AMLA) draft standards are not law yet. They say eID "includes European Digital Identity Wallets", and that missing attributes are obtained "through other means in line with Article 22(6)".[11] Wire that branch into the flow. Beneficial owners, purpose, screening and monitoring stay outside the wallet.[10] Portrait-based plans should wait: it joins the mandatory set only from 11 August 2028, and Member States may let users decline it.[6]
13. Incidents, testing, monitoring and vendor oversight
Write runbooks for outside events.
Revokes your certificates
Runbook: fallback route, fix, appeal
If your registration is suspended or cancelled.[3][12]
| Event | What the texts say | Your runbook |
|---|---|---|
| Your registration is suspended | Possible with or without prior notice; you are told within 24 hours; certificates revoked[3] | Switch to fallback, find the cause, use redress |
| A wallet solution is suspended | Registered relying parties told within 24 hours; withdrawn if not fixed in three months[9] | Stop accepting it, reassess recent onboardings |
| Your key is compromised | You may request revocation; status published within 24 hours[3] | Revoke, reissue, review logs |
| Personal data breach | Controller notifies the authority without undue delay, where feasible within 72 hours of awareness, unless risk is unlikely; processors notify the controller[13] | Standard GDPR process |
Testing and monitoring. The EU publishes open-source reference verifier components for early tests.[16] Monitor signature and status failures, fallback rate and requests against the register; add negative tests for revoked and tampered credentials.
Vendors. An intermediary is deemed a relying party and "shall not store data about the content of the transaction".[1] The ARF, which is guidance, says the intermediary and the relying party "must agree on what verifications the intermediary will carry out", and that intermediaries are required to delete data immediately after forwarding it, so erasure requests always come to you.[12] Under the AMLR, obliged entities notify the supervisor before outsourcing starts and "remain fully liable for any action, whether an act of commission or omission, connected to the outsourced tasks".[10] Under the Digital Operational Resilience Act (DORA), financial entities "remain fully responsible" for their obligations.[14] Contract for the agreed checks, retention and audit rights; our integration guide compares the routes.
Control matrix: owner, evidence, source
"Good practice" marks controls with no rule behind them.
| Control | Owner | Evidence | Source |
|---|---|---|---|
| Dated scope decision | Legal | Signed memo | Art. 5f[1] |
| Named policy owner | Compliance | Approved policy | Good practice |
| Intended-use inventory | Product | Attribute register | Annex I, 9-10[3] |
| Registration kept current | Compliance | Change log, register extract | Art. 5(3)[3] |
| Certificate inventory per instance | Security | Inventory, expiry alerts | ARF 6.4.2[12] |
| Key custody and rotation | Security | Key ceremony records | Good practice |
| Over-request block in release tests | Engineering | Test report | Art. 5b(3)[1] |
| Signature and trust anchor checks | Engineering | Check logs | Art. 5b(9)[1] |
| Revocation and device binding policy | Security | Policy, check logs | ARF 6.6.3.7-9[12] |
| Unknown-status rule | Compliance | Risk analysis | ARF 6.6.3.7[12] |
| Assurance mapping | Compliance | Mapping document | Art. 5a(11)[1] |
| Step-up rules | Fraud | Rules, decision logs | ARF 6.6.3.9[12] |
| Equal non-wallet route | Product | Journey and price review | Art. 5a(15)[1] |
| Erasure and complaint channels | Privacy | Tickets, response times | Art. 5a(4)(d)[1] |
| Retention schedule | Privacy | Schedule, deletion logs | Art. 77[10] |
| Portrait rule | Privacy | Field-level retention test | Art. 3a[6] |
| DPIA screening | Privacy | Signed DPIA or screening | Art. 35[13] |
| Art. 22 attribute map | Compliance | Procedure, samples | Art. 22[10] |
| Incident runbooks | Security | Drill reports | Art. 5[9] |
| Intermediary contract | Procurement | Contract, audit reports | Art. 5b(10)[1] |
An EUDI Wallet readiness plan to December 2027
Bold dates come from the texts; the rest is our suggestion.
| When | Goal | Output |
|---|---|---|
| November 2026 | Scope and ownership | Scope memo, owner, gap list |
| 24 December 2026 | Registration rules apply; wallets due | National register and registration policy checked for each home Member State |
| January to March 2027 | Design | Intended uses, attribute lists, DPIA screening, route chosen |
| April to June 2027 | Build and contract | Reference tests, vendor terms, retention schedule |
| 10 July 2027 | AMLR applies | Article 22 map and Article 9 procedures live |
| July to September 2027 | Register | Registration, certificates, privacy pages, support training |
| October to November 2027 | Prove it | Pilot, incident drill, internal audit |
| 24 December 2027 | Acceptance deadline | Production sign-off, monitoring running |
Mid-plan check
Build the workflow, evidence and fallback now with national eIDs and documents, then read the integration guide.
What to do this month: an EUDI Wallet readiness checklist
- Write the scope memo for Article 5f(2).
- Name the accountable owner.
- List every flow that could accept a wallet.
- Draft the minimum attribute list for each flow.
- Find your registrar and national registration policy.
- Map the Article 22(1) data your wallet route will not supply.
- Start the DPIA screening.
- Set the portrait default to verify and discard.
- Check that privacy and support channels are ready for wallet requests.
- List vendors who would touch wallet data.
How Didit helps with EUDI Wallet readiness
Didit gives you the non-wallet route and the workflow around it. EUDI Wallet acceptance is coming soon; see the EUDI Wallet page, which puts it this way: "Integrate today, and keep it when the wallet arrives."[17][23] We hold no registered or approved status under these rules, and your firm's duties stay with your firm.
Didit provides
- National eIDs live today: MitID, BankID Sweden, Finnish Trust Network, Smart-ID and Mobile-ID[24]
- Document checks with NFC chip reading, liveness and face match
- Biometric authentication for returning users[21]
- Retention from 1 month to 10 years, and deletion on demand[18]
- Audit logs and four-eyes case review[19][20]
Stays with you
- Scope decision and policies
- Your registration and intended uses
- Your risk appetite and customer decisions
- GDPR controller duties: Didit acts as processor[18]
- Regulator contact and outsourcing notices
For vendor review, Didit's assurance covers SOC 2 Type 1 and Type 2, ISO/IEC 27001 and iBeta Level 1 presentation attack detection.[22] For AML duties see our AMLR page, and national eID verification for the route that works now. Costs are on the pricing page.
Put your fallback route in place first
Run national eIDs and documents in one workflow, with the evidence your controls need.
Key takeaways
- EUDI Wallet readiness is a control programme: 13 domains, each with an owner and evidence.
- Registration is transparency, not approval, and over-asking is an express ground for suspending or cancelling it.
- Revocation and device binding are ARF recommendations, so your policy must decide them.
- A wallet does not supply the whole Article 22 data set, and a fallback route is mandatory in practice.
- The portrait now has its own retention rule: default to verify and discard.
Frequently asked questions
What policies does a company need before accepting the EUDI Wallet?
At minimum: a scope decision, a policy with a named owner, an attribute list per intended use, certificate and key rules, trust check and step-up rules, a fallback route, retention rules, a DPIA screening, incident runbooks and vendor terms.[1][3][13]
Does every regulated firm have to accept the EUDI Wallet by 24 December 2027?
No. Article 5f(2) covers private relying parties required by Union or national law, or by contract, to use strong user authentication for online identification, except micro and small enterprises, and only at the user's voluntary request. The date is computed as 36 months from 24 December 2024. Very large online platforms have a separate duty under Article 5f(3).[1]
Do we need both an access certificate and a registration certificate?
Plan for both. Access certificates authenticate you to the wallet and are mandatory for registered parties. Registration certificates list your registered intended uses and attributes; since 2026/1730, Member States shall authorise at least one provider and ensure automated issuance. The wallet's duty to validate registration certificates applies from 11 August 2028; that deferral does not cover access certificates.[3][4][6][7][12]
Is assurance level high enough for AML customer due diligence?
It covers identity verification, not the whole of due diligence. AMLR Article 22(6)(b) accepts eID at level substantial or high. You still need the Article 22(1) data the PID lacks, plus beneficial owners, purpose, screening and monitoring. AMLA's draft standards, which are not law yet, say missing attributes are obtained through other means.[10][11]
Can we keep the portrait from a wallet presentation?
Only in limited cases. Article 3a(3) of 2024/2977, inserted by 2026/1731, bars retention unless processing is necessary for identification and authentication in compliance with Union data protection law, or Union or national law provides for it. Default to verify and discard.[6]
How long do we keep wallet data?
Obliged entities keep customer due diligence information, including information obtained through electronic identification means, for 5 years from the end of the relationship or the refusal, then delete it, subject to other laws. Outside AML, GDPR storage limits apply per purpose.[10][13]
Can we use an intermediary, and who stays responsible?
Yes, you can. An intermediary is deemed a relying party and may not store data about the content of the transaction. You and the intermediary must agree which checks it runs. Obliged entities remain fully liable for any action connected to outsourced tasks and notify the supervisor before outsourcing starts.[1][10][12]
Does Didit accept EUDI Wallets today?
No. EUDI Wallet acceptance is coming soon on Didit. MitID, BankID Sweden, Finnish Trust Network, Smart-ID and Mobile-ID run today, alongside document verification.[17][23][24]
Sources
- Regulation (EU) No 910/2014 (eIDAS), consolidated text of 18 October 2024, EUR-Lex.
- Regulation (EU) 2024/1183, EUR-Lex, Official Journal of 30 April 2024.
- Commission Implementing Regulation (EU) 2025/848, registration of wallet-relying parties, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1730, amending 2025/848, EUR-Lex, Official Journal of 22 July 2026.
- Commission Implementing Regulation (EU) 2024/2977, person identification data and attestations, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1731, amending 2024/2977, 2024/2979, 2024/2980 and 2024/2982, EUR-Lex, Official Journal of 22 July 2026.
- Commission Implementing Regulation (EU) 2024/2982, protocols and interfaces, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/846, cross-border identity matching, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/847, security breaches of wallets, EUR-Lex.
- Regulation (EU) 2024/1624 (AMLR), EUR-Lex, Official Journal of 19 June 2024.
- Final Report, draft RTS under Article 28(1) AMLR, AMLA, draft, not law.
- EUDI Wallet Architecture and Reference Framework v3.0.0, European Commission, 23 July 2026.
- Regulation (EU) 2016/679 (GDPR), EUR-Lex.
- Regulation (EU) 2022/2554 (DORA), EUR-Lex.
- TechDispatch on digital identity wallets, European Data Protection Supervisor, 16 December 2025.
- EU reference verifier repository, eu-digital-identity-wallet on GitHub.
- Digital ID wallets, Didit docs.
- Data retention and deletion, Didit docs.
- Audit logs, Didit docs.
- 4-eyes review, Didit docs.
- Biometric authentication, Didit docs.
- Security and compliance, Didit docs.
- EUDI Wallet solutions page, Didit.
- AMLR compliance, Didit docs.
See how the document and national eID routes fit together on the EUDI Wallet page.
Start with the route you can run today
Build on national eIDs and documents while wallets roll out.
Articles associés
- Exigences KYC de CANAFE (FINTRAC) pour les ESM crypto et de paiement (2026)
- Loi 25 du Québec et biométrie : guide de vérification de l'identité (2026)
- EUDI Wallet integration: how to choose your route (2026 guide)
- EUDI Wallet holder binding: what a presentation really proves
- EUDI Wallet cross-border acceptance: one integration across the EU
- Vérification de l'âge au Canada : S-209, C-34 et quoi faire maintenant