EUDI Wallet cross-border acceptance: one integration across the EU

Last reviewed: 31 October 2026 · Not legal advice

EUDI Wallet cross-border acceptance looks like a 27-country project, but Regulation (EU) 2024/1183 and its implementing acts fix the data model, formats and trust lists for every Member State. The hard part sits in your own systems: a French customer's PID does not look like a Polish one, a returning customer has no common EU identifier, and some countries will arrive late.

This guide assumes you know what a relying party must do and how an OpenID4VP verifier works. Choosing how to connect: read our guide to EUDI Wallet integration routes. Rules below come from the primary text, including the July 2026 amendments and the Architecture and Reference Framework (ARF) 3.0.0.

What EUDI Wallet cross-border acceptance means in law

Each Member State must provide "at least one European Digital Identity Wallet", directly, under a mandate, or independently but recognised by that state, so one country can have several.^[1] A relying party "shall register in the Member State where it is established", once, and wallets must be able to authenticate it "irrespective of where they are established in the Union".^[1][6] And the relying party is "responsible for carrying out the procedure for authenticating and validating" the data it requests.^[1]

For private firms, Article 5f(2) excludes micro and small enterprises and applies "only upon the voluntary request of the user".^[1] Our deadlines guide covers who is in scope.

1. 11 August 2026PID rules updatedRegulation 2026/1731, published 22 July, enters into force and replaces the PID annex.
2. 24 December 2026Wallets dueIdentity matching and registration rules also apply.
3. First quarter of 2027Test baselineIndicative goal for the conformance release candidate.
4. 24 December 2027Private acceptanceArticle 5f(2) deadline for firms in scope.
5. 11 August 2028Portrait, certificatesPortrait in the mandatory set; wallets validate registration certificates.

The dates that shape a cross-border rollout. 24 December 2026 and 2027 are computed from the entry into force of the implementing acts on 24 December 2024.^{[1][2][5][15]}

The trust model: LoTEs, not one big list

For a PID, "the EU trusted list" is the wrong mental model. ARF 3.0.0 states that "Trusted Lists exist only for QEAA Providers", the qualified attestation issuers, whose national lists are reached through the Commission's List of Trusted Lists (LOTL).^[8] Everything else sits in Lists of Trusted Entities, "signed and published by the Commission" after Member States notify the entities.^[8]

Which list does what, based on ARF section 3.5 and Regulation 2024/2980 Article 5.^[4][8] Relying parties themselves are on no list.^[8]

When a wallet responds, your verifier walks one chain, the same for a PID from any Member State:

One verification chain for every issuing country, condensed from ARF sections 6.6.3.6 to 6.6.3.9.^[9]

The ARF calls revocation checks and device binding checks "recommended but not mandatory" in general, yet trusting the wallet's user authentication "implies that Relying Parties must verify device binding".^[9] For onboarding, we advise treating both as required. What device binding does not prove is a separate question.

You cannot check the wallet itself: you rely on the PID Provider, which revokes the PID if the wallet unit is revoked, so the PID status check covers the wallet.^[9] Entities are never deleted from a list, only set to Invalid, so read status.^[8]

Register once, and ask only what you registered

You register at home only, and any wallet can authenticate you; the wallet compares your request with your registration certificate.^[1][6][9]

Register once at home, present anywhere. Simplified from ARF section 6.6.3 and Regulation 2025/848.^[6][9]

The cross-border trap is the outcome. If you ask for more than you registered, the wallet "shall clearly warn the wallet user before any disclosure", but each wallet provider decides, on its own risk analysis, whether the user may continue, whether only the registered subset is shared, or whether the request is rejected.^[2] One over-asking request can therefore give three different results in three countries.^[2] Wallets only have to validate registration certificates from 11 August 2028, so test this behaviour per wallet rather than rely on one result.^[2]

Register every attribute you may need in any country, then request per journey only what it needs. Member States "may require" registration certificates, so check your registrar's policy.^[6] Our policies and controls guide turns this into an owned control.

PID attributes: same schema, different contents

The PID annex of Regulation 2024/2977 was replaced by Regulation 2026/1731 in July 2026, so older tables are out of date.^[2] Attribute names also differ between the two formats.

The natural-person PID as replaced in July 2026.^[2] Metadata: issuing_authority and issuing_country are mandatory; expiry_date, issuance_date, document_number and issuing_jurisdiction are optional.^[2]

Test each of these:

• Unknown and stateless. Unknown nationality is the value QU, no nationality is QS.^[2] A strict ISO country parser rejects both.
• Place of birth. It "shall contain at least one" of country, region or locality.^[2] You may receive a town with no country.
• Several nationalities. The provider "may include" all of them. The Rulebook also allows a second one in a domestic attribute.^[2][11]
• Street. resident_street now includes the house number; the separate house number attribute is gone.^[2][3]
• Domestic extras. Countries may add attributes in a namespace such as eu.europa.ec.eudi.pid.[country] or a domestic type, published under Regulation 2025/1569.^[2]

For firms under the Anti-Money Laundering Regulation (AMLR), this is where one wallet stops being enough. The EU Anti-Money Laundering Authority's (AMLA) final draft standard of 30 September 2026, still a draft, says that where a means does not hold every attribute, the firm "shall take steps to obtain and verify the missing attributes through other means".^[14]

Based on Annex I of AMLA's draft standard.^[13][14] That draft still lists resident_house_number, which the July 2026 PID annex removed, so expect the mapping to change.^[2][14] Read our AMLR guide for the full position.

Normalising names, addresses and places

PID text is UTF-8 with the full Unicode range, and an mdoc text field has a 150-character limit.^[2] No PID attribute carries a Latin transliteration: neither the annex nor Rulebook 1.7 defines one.^[2][11] So a customer can arrive in Greek or Cyrillic script while your sanctions screening and your existing records use Latin characters. AMLA's draft asks firms to screen names "in their original alphabet and/or transliterated into the Latin alphabet".^[14]

The closest legal standard, written for public bodies, says the outcome of matching "shall, to the extent possible, not be affected by differences in transliteration, blank spaces, hyphenation, concatenation, and similar orthographic variations".^[5] Our recommended design, engineering advice rather than law:

• Keep the original. Store the signed value as evidence; derive a separate match key.
• Normalise in one place. Apply Unicode normalisation (NFC), fold case, collapse spaces, and treat hyphens and apostrophes as separators.
• Compare in layers. Try exact, then without diacritics, then token order, and record which layer matched.
• Treat script changes as evidence. Use the Latin form on the customer's own document, not one transliteration table.

Language is yours to handle. No PID attribute carries a language or locale, so take it from your own flow.^[2][11] The wallet shows its own screens, while your request, intended-use text and error messages need translating; for the portrait the rules expect intended use "in clear and intelligible language".^[2]

Addresses need the same care. resident_address is free text, while the parts are separate attributes, and any of them may be missing.^[2] AMLA's draft asks for country, town and street elements, and its recitals want attributes in "structured data fields".^[14] Accept both shapes.

Identity matching and returning customers

There is no EU-wide customer number. personal_administrative_number is optional and unique only "among all personal administrative numbers issued by the provider".^[2] For several PIDs of the requested format, the wallet asks the user unless context decides, and technical PIDs typically last days or weeks.^[10][11] So never key an account on a PID signature, public key or document_number.

Regulation (EU) 2025/846 sets cross-border identity-matching procedures applicable from 24 December 2026. It binds "public sector bodies or [...] bodies acting on behalf of a public sector body".^[5] Member States decide whether private relying parties can use those systems, and where they do, the procedures apply "where applicable".^[5]

Article 2(7)Regulation (EU) 2025/846

"Where the match is not exact or relates to more than one natural person, or the party performing the identity matching cannot guarantee that the match is unequivocal, the identity matching process shall be deemed unsuccessful."

Source: EUR-Lex, Implementing Regulation (EU) 2025/846^[5]

The Regulation 2025/846 process, simplified. Public bodies must follow it. For private firms it is a template unless national rules extend it.^[5]

The logs are retained "for a minimum of 6 months and a maximum of 12 months for security purposes", and longer for other purposes only where Union or national law requires it.^[5] Keep them apart from AML records. After a first match, store your own association between the person and the account, one of the listed reuse options, so a re-issued PID does not repeat the work.^[5]

Formats, protocols and wallet versions

A PID Provider "SHALL issue any PID in both" formats, so a PID-only verifier could ask for one, but cover both unless your testing proves otherwise.^[10] Our SD-JWT VC vs mdoc comparison explains the differences. Presentation has two profiles, each with two ways to reach the wallet.^[2]

Regulation 2024/2982 Annex II, added in July 2026.^[2][7]

The rules name dated specifications, which amending acts can move, and ISO server retrieval is banned for everyone.^[2][7] The operating system is a variable too: a wallet must support a mediating API, but the Regulation records that a device or browser may not support both protocols, a case it treats as a non-conformity outside the wallet's control.^[2]

Check certification status separately from protocol conformance. Member States report certified wallets for a Commission list under Article 5d.^[1] The Commission's functional conformance framework is still in its 0.x series: its roadmap, marked indicative, aims for "a release candidate in the first quarter of 2027", with version 1.0.0 as "the first full-scope baseline suitable for certification".^[15]

Test before the national wallets arrive

The Commission's reference implementation includes a sample wallet, a test verifier and a test issuer, with open repositories for the verifier endpoint and trust validation.^[19] A pass shows protocol fit, not national wallet behaviour.

The Launchpad 2026 testing track moved to "validating how solutions work together under real-world conditions, ahead of launch", with test access to LoTEs on the eIDAS Dashboard.^[16] Relying parties join through Large Scale Pilots or a national invitation, and solution providers also take part.^[16] Six pilots have run, POTENTIAL among them on cross-border authentication.^[18] APTITUDE and WE BUILD remain active, the second on business and payment use cases.^[17]

What to do when a country is late

Our EUDI Wallet tracker holds the status by country, and Germany and Italy have their own guides. Make each country a configuration with one of three states, driven by the lists, not the press.

A country state model for rollout. This is our suggestion; the law does not define these states.

You need the other routes anyway. Wallet use "shall be voluntary", access must not be "restricted or made disadvantageous" for people without one, and it "shall remain possible" to use other means.^[1] Under the AMLR, identity documents and electronic identification at level substantial or high stand side by side as verification routes.^[13] Your integration route should make a late country a setting.

Your cross-border checklist for this month

• Map which entities and countries fall under Article 5f(2).^[1]
• Confirm your home Member State's registrar and registration policy.^[6]
• List every attribute you may need in any country.
• Build one internal schema that maps mdoc and SD-JWT VC names.^[2]
• Replace old PID tables with the July 2026 annex.^[2]
• Add test cases for QU, QS and partial birthplace.^[2]
• Build a list loader for ETSI TS 119 602 and ETSI TS 119 612.^[8]
• Write match failure messages in each customer language.^[5]
• Set log retention for matching and compare it with AML retention.^[5]
• Ask your national coordinator about pilot, Launchpad or Commission programme access.^[16][20]

How Didit helps with cross-border acceptance

EUDI Wallet acceptance is coming soon at Didit, and you can follow it on our EUDI Wallet page. Today you can build the routes that surround it. National eIDs (MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID) work through wallet sign-in, with results normalised because "wallet attribute names vary".^[21] You choose accepted wallets per country and whether a failure falls back to a document or declines.^[21] The document route covers 14,000+ document types.^[22] For the name and address gaps above, it reads the customer's document, and AML screening runs against 1,300+ sanctions, PEP and watchlist sources.^[23]

Frequently asked questions

Sources

1. Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, consolidated text, EUR-Lex.
2. Commission Implementing Regulation (EU) 2026/1731, amending Regulations 2024/2977, 2024/2979, 2024/2980 and 2024/2982, EUR-Lex, 15 July 2026.
3. Commission Implementing Regulation (EU) 2024/2977, person identification data, EUR-Lex, original text.
4. Commission Implementing Regulation (EU) 2024/2980, notifications, EUR-Lex.
5. Commission Implementing Regulation (EU) 2025/846, cross-border identity matching, EUR-Lex.
6. Commission Implementing Regulation (EU) 2025/848, registration of wallet-relying parties, EUR-Lex.
7. Commission Implementing Regulation (EU) 2024/2982, protocols and interfaces, EUR-Lex.
8. Architecture and Reference Framework 3.0.0, chapter 3, Roles, European Commission.
9. Architecture and Reference Framework 3.0.0, chapter 6, Trust model, European Commission.
10. ARF Annex 2, High-level requirements by topic, European Commission.
11. PID Rulebook, version 1.7, European Commission, 17 July 2026.
12. Compiled list of PID Providers, eIDAS Dashboard, European Commission, read 31 October 2026.
13. Regulation (EU) 2024/1624 (AMLR), EUR-Lex.
14. Final Report, draft regulatory technical standards under Article 28(1) AMLR, AMLA, 30 September 2026.
15. Functional conformance roadmap, EUDI Wallet functional conformance framework, read 31 October 2026.
16. Launchpad Testing 2026, European Commission, updated 23 October 2026.
17. What are the Large Scale Pilots, European Commission, updated 22 July 2026.
18. PID Identification Manual, European Commission, updated 11 February 2026.
19. EUDI Wallet Reference Implementation documentation, European Commission.
20. Relying Party Engagement Programme, European Commission, updated 18 September 2026.
21. Digital ID Wallet Verification API and Coverage, Didit documentation.
22. ID Verification overview, Didit documentation.
23. AML Screening overview, Didit documentation.
24. Data retention, Didit documentation.

Follow the rollout on our EUDI Wallet page, see the routes that work now on our eID verification page, and compare options on the pricing page.