What POTENTIAL actually was
POTENTIAL was the largest of the four EU Large Scale Pilots for the European Digital Identity Wallet. It ran from April 2023 to September 2025, ended on schedule, and presented its consolidated final results in November 2025. The numbers are unusually clean for an EU programme: 140 organisations, 19 EU member states plus Ukraine, six use cases, and a single coordinator — France's national digital identity agency. Project coordinator Florent Tournois delivered the line that has since travelled further than the rest of the report: "common standards must be applied rigorously" (Biometric Update, 28 November 2025). Every relying party planning a 2027 launch should treat that sentence as scope.
Why POTENTIAL matters more than the other pilots
The four large-scale pilots — POTENTIAL, EWC, NOBID and DC4EU — were never equivalent. POTENTIAL was the biggest by organisation count, the broadest by use-case coverage, and the most heterogeneous by member-state participation. Its consortium included Germany's Bundesdruckerei, France's Idemia, Amadeus, Deutsche Telekom, and a long tail of national identity providers, banks, telcos, healthcare authorities and government agencies (POTENTIAL consortium homepage). Where EWC concentrated on travel and payments and NOBID on Nordic payment flows, POTENTIAL deliberately tested the harder problem: would the same wallet, issued in one member state, work cleanly at a relying party in another, across six unrelated business domains, with implementations built independently by competing vendors.
That is the real significance of the pilot. The launch problem — getting one national wallet to talk to one national relying party — is comparatively easy and many member states have already solved it. The hard problem is cross-border, cross-vendor, cross-use-case interoperability, and POTENTIAL was the only pilot designed to surface where that breaks. It surfaced more breakage than the headline communications conveyed, and that is the part relying parties should be reading.
The 6 use cases tested
eGov — online government services. Citizens used their wallets to authenticate against national e-government portals across borders: a Belgian wallet logging into a Spanish municipal service, an Italian wallet against a German federal portal. The flow worked cleanly inside well-aligned bilateral pairs and produced consistent failures at the edges, particularly where national assurance levels did not map one-to-one onto the eIDAS LoA model. eGov is the use case most relying parties already understand, and POTENTIAL confirmed that this is the easy end of the spectrum.
Bank account opening. Remote KYC against a wallet, in lieu of video-ident or branch attendance. The technical flow is straightforward; the regulatory flow is not. POTENTIAL surfaced the still-unresolved tension between AMLD requirements and selective disclosure: banks want everything, the wallet is designed to share the minimum, and the legal acceptance of pure-attribute KYC differs by national supervisor. Several pilot banks reported needing parallel document-upload paths to satisfy compliance even when the wallet flow technically completed.
SIM and eSIM registration — Deutsche Telekom multi-wallet. The most operationally interesting branch. Deutsche Telekom tested SIM activation against multiple wallet implementations from different member states in parallel, which is exactly the production reality a 2027 telco will face. The findings were sobering: even within POTENTIAL, where every wallet was built to the same architectural reference, behaviour at the protocol level diverged enough to require per-wallet conditional logic in the relying-party code.
Mobile driving licence (mDL). The use case with the most mature international standard (ISO/IEC 18013-5) and, predictably, the cleanest cross-border behaviour. mDL implementations interoperated comparatively well, especially for offline ISO/IEC 18013-5 flows. The harder cases were online presentation via OpenID4VP, where the mdoc-over-OpenID4VP profile was still consolidating during the pilot.
Qualified electronic signature (QES). Wallet-mediated QES against a remote QSCD, aligned with ETSI TS 119 475. The cryptographic flow worked. The legal-binding flow exposed national variation in how QTSPs accept wallet-asserted authentication of the signatory. QES is a 2027 problem more than a 2026 problem for most relying parties.
ePrescription. Cross-border medical prescriptions against pharmacies in another member state. The healthcare attribute set is more sensitive than any other use case in the pilot and mapped onto national health-data regulations that resist harmonisation. Technically working, legally constrained, and dependent on the parallel work happening inside the European Health Data Space rather than on the wallet stack alone.
Read across the six, the pattern is consistent: the technical layer matured faster than the legal and operational layers around it. Relying parties scoping a 2027 launch should plan the regulatory mapping as a workstream in parallel with the integration, not as a sign-off after it.
Lesson 1 — Standards are not optional
Tournois did not say standards are important. He said they must be applied "rigorously". The distinction matters. Across POTENTIAL, the dominant interoperability failures were not missing standards — the OpenID4VP profile, ISO/IEC 18013-5, ETSI TS 119 475 and the related EU Architecture and Reference Framework all existed before the pilot started. The failures came from implementations that read the standards loosely.
The kinds of concrete divergence a relying party should plan for when integrating multiple wallets are well known in cross-vendor wallet engineering: OpenID4VP request profiles where one wallet expects client_id_scheme=x509_san_dns and another expects redirect_uri; mdoc encoding edge cases around CBOR canonicalisation that work in one library and fail in another; presentation-definition shapes that one verifier accepts as JSON Schema while another rejects as not Presentation Exchange 2.0; selective-disclosure salt handling differences between SD-JWT-VC implementations. The public POTENTIAL summary does not enumerate these line by line, but it is precisely the class of failure Tournois's "rigorously" was pointing at, and it is the kind of breakage relying-party teams testing against more than one wallet are encountering in 2026.
For a relying party, "rigorous" translates directly into engineering practice. It means pinning to the specific OpenID4VP profile draft your wallets target, not "OpenID4VP" generically. It means testing against multiple wallet implementations before launch — not one. It means treating the OpenID Foundation conformance suite as a baseline rather than a milestone. And it means reading the EU Reference Framework as binding scope, not as inspiration. Relying parties who skip the conformance step at launch will inherit, in production, the same divergences POTENTIAL surfaced in test environments.
Lesson 2 — Cross-border interop is the unsolved problem
This is the lesson that most directly threatens 2027 launches. Even within POTENTIAL — a single coordinated programme with shared architecture documents, shared test infrastructure and shared funding — multiple wallets did not interoperate cleanly with multiple relying parties out of the box. Pairs worked. The full N-by-M matrix did not.
The implication for cross-border merchants and service providers in 2027 is awkward. The eIDAS 2 regulation gives EU citizens the right to use their wallet at a relying party in any member state. The technical reality, on POTENTIAL's evidence, is that universal acceptance will be lumpy for the first 12 to 18 months after launch. Some wallet-relying-party pairs will be solid from January 2027. Others will require relying-party-side conditional handling, vendor-specific quirks, or temporary fallback paths.
Relying parties who plan to serve cross-border traffic should not assume that "EUDI Wallet support" is a single capability. It is more accurate to plan for "EUDI Wallet support per issuer cluster", with a tested set of national wallets at launch and an explicit roadmap for extending coverage as additional wallet implementations stabilise. Concretely, that means publishing — internally and to support teams — which national wallets are tested-and-working, which are tested-and-degraded, and which are not yet tested. The merchants who skip that staging will own the interop bug reports, and the support tickets that follow them.
Lesson 3 — Attribute scoping pays off
Selective disclosure is the wallet feature that survived contact with reality best. Across all six use cases, POTENTIAL relying parties that requested only the minimum attributes needed for the transaction reported smoother user flows, faster consent, and lower drop-off. Relying parties that requested more — the full identity bundle when only age was needed, or address when only country of residence was needed — produced visible user friction.
In a pilot, that friction shows up as reduced completion. In production, after the wallet launches in 2027, the same over-requesting will produce something more expensive: regulatory scrutiny. The eIDAS 2 framework and the GDPR principle of data minimisation both bind relying parties to request the smallest attribute set that satisfies the use case. National data protection authorities will almost certainly audit the wallet flow with this lens — and the over-requesting relying parties will be the easiest targets.
The practical move is to build attribute scoping into the relying-party design from day one. Document, per flow, which attributes are strictly necessary; ship that as the production presentation request; and resist the engineering temptation to "ask for everything in case we need it later." POTENTIAL's data confirms that minimum-attribute flows convert better. The compliance argument and the conversion argument point the same direction.
Lesson 4 — Age-only flows are the easiest path to early ROI
Buried in POTENTIAL's per-use-case results is a finding worth pulling out separately. Across all six use cases, the attribute combinations that worked most consistently across wallet vendors and relying parties were the simplest ones — and the most consistent of all was age. Age-over-18, age-over-21, age-in-range: these flows survived implementation diversity more reliably than full identity, more reliably than name-and-address, more reliably than QES.
There is a structural reason. Age attributes have the shortest specification surface, the smallest selective-disclosure scope, and the longest standardisation history (ISO/IEC 18013-5 has carried mDL age attributes for years). Wallet vendors implemented them first and tested them most. Relying parties wired them up with the fewest edge cases.
For a relying party planning a 2027 launch, this points to a clear sequencing strategy. Integrate age-only verification first — alcohol, gambling, age-gated content, regulated marketplaces — then expand to full identity flows as the wallet ecosystem matures. The relying parties that sequence in that order will see real ROI within Q1 and Q2 2027. The relying parties that aim straight for full identity onboarding will spend the same months debugging.
This is not a strategic compromise. Age-only flows are a substantial, growing market in their own right and the launch ecosystem is genuinely better equipped to deliver them. It is also, conveniently, the lowest-risk way to acquire production operational experience before extending scope.
Lesson 5 — Fallback design separates production-ready from pilot-ready
POTENTIAL's clearest organisational finding is the one most easily ignored. Across all six use cases, the relying parties that survived edge cases — lost devices, expired credentials, cross-border holders, users who simply gave up halfway — had clean non-wallet fallbacks. The relying parties that did not, reverted to manual processes when the wallet flow failed.
"Manual process" in pilot-speak is a polite term for a customer service queue, an in-branch appointment, or a support ticket. None of those scale to production volumes, and all of them quietly transfer the cost of a missing fallback path onto the operations budget. The relying parties that treated fallback as a first-class production path — designing it, instrumenting it, training support on it — kept their flows usable through pilot edge cases. The ones that bolted fallback on as an afterthought hit the edge cases and stopped.
The lesson for 2027 is direct. A wallet-only flow at launch is a self-inflicted reliability problem. Every wallet integration should ship with at least one explicit non-wallet path: an existing national eID flow where one exists, a document-upload route for non-residents and edge cases, an in-person path where the business model supports it. The fallback is not a temporary scaffolding to remove in 2028. It is part of the production design, and on POTENTIAL's evidence it is what separates relying parties that will run smoothly through Q1 2027 from those that will not.
The bottom line
POTENTIAL is the closest thing the EU has to a production smoke test for the EUDI Wallet. It ran for two and a half years, consumed 140 organisations across 19 countries, exercised six unrelated use cases, and produced its findings before the regulatory deadlines bind. Read its findings as a readiness checklist, not as academic literature. Standards rigour, multi-wallet interop testing, attribute minimisation, age-first sequencing, fallback paths — these are the five concrete commitments any relying party can audit against its own backlog today. Anything on that list you cannot honestly check off before Q3 2026 is a 2027 ship-blocker. The pilot is over. The deadlines are not.
Share this article
Help others learn about eIDAS verification