Interoperability in production: why 27 wallets do not add up to one European identity

Building a digital identity wallet is a solved problem. Several member states have shipped one. France has France Identité, Austria has eAusweise, Italy has IT-Wallet, and Portugal has a national approach taking shape through ARTE and INCM. The engineering is understood, the standards exist, and the vendors are ready.

The unsolved problem starts the moment a wallet issued in one country meets a relying party in another. That is where the European Digital Identity framework either delivers on its promise or becomes 27 national apps with a shared logo.

Regulation (EU) 2024/1183 entered into force on 20 May 2024.1 The implementing acts that followed set the clock running. The practical consequence is December 2026: every member state must make at least one certified EU Digital Identity Wallet available to citizens and residents. Roughly twelve months later, obligated relying parties in banking, telecoms, healthcare, energy, transport, education, and very large online platforms must accept it.4

Two deadlines, twelve months apart. The first is an engineering deadline. The second is an interoperability deadline, and it is much harder.

Progress towards the first is uneven in a way that should worry anyone planning for the second. A rollout survey published in April 2026 found four member states with public sandbox environments, fourteen with announced projects and nothing public to test against, seven upgrading existing national apps, and a handful, Portugal among them, with existing applications but no confirmed EUDI Wallet upgrade path.3 Eight months from the deadline, most of Europe had no environment a foreign relying party could test against.

The gap between compliance and function

A wallet can be fully compliant and still fail in the field. Compliance means it satisfies a certification scheme. Function means a Portuguese citizen can open a bank account in Germany, sign a rental contract in Spain, or enrol at a university in Finland without anyone in the chain having to make a phone call.

Between those two states sit problems that no single member state can solve alone.

Trust registries have to agree on what they are asserting

When a German relying party receives an attestation from a Portuguese wallet, it needs to resolve two questions in milliseconds. Is this wallet genuinely certified? Is the issuer of this particular attribute genuinely authorised to issue it? Answering that requires trust lists that are machine-readable, current, and mutually recognised. Every gap in that chain becomes either a security hole or a rejected transaction.

Levels of assurance mean different things in different places

The framework defines low, substantial, and high. In practice, the evidence a member state accepts to reach "high" reflects its own identity infrastructure and legal tradition. A country with a mature national ID card and a biometric register can reach high assurance through a route that a country without those foundations cannot replicate. The label travels across borders. The underlying evidence does not, at least not without explanation.

Attribute schemas drift

A name is not a simple string once you cross a border. Composite surnames, patronymics, diacritics, and transliteration rules all differ. Address formats differ more. Professional qualifications differ most of all: a nursing licence, a lawyer's bar registration, and a commercial vehicle permit each carry national semantics that a shared data model can flatten but not fully reconcile.

Revocation is a distributed systems problem with a privacy constraint

A wallet holder loses a phone. An issuer discovers a fraudulent enrolment. A qualification lapses. Every relying party in Europe now needs to know, quickly, without any of them learning which attestations a particular person is presenting elsewhere. Solving that without building a surveillance-capable checking infrastructure is genuinely difficult, and the current specifications are still evolving on this point.2

What the Large-Scale Pilots actually taught us

Six Large-Scale Pilot consortia have now worked through real cross-border scenarios: payments, mobile driving licences, professional qualifications, education credentials, travel, and eHealth. Their value was not proving the concept. It was documenting the failure modes.

The panel that closed the interoperability block at LisbonID 2026 put the same point in its title. Yann Bouan of Idakto, Ivan Marin of Procivis, Florent Tournois of ANTS and Carlos A. Pina of NOSi sat down with David Kelts to talk about what breaks in production, alongside André Vasconcelos of ARTE presenting the Portuguese wallet approach. Nobody argued about protocols.

The recurring finding across the pilots is that failures cluster at organisational boundaries rather than in code. A wallet talks to a relying party. Both are technically conformant. The transaction fails because the two parties have different interpretations of an optional field, different assumptions about the freshness of a trust list, or different escalation paths when something goes wrong.

Nobody is at fault, and nothing gets fixed, because there is no shared owner of the failure.

This is exactly the class of problem that documentation does not solve and that only production traffic reveals. It is also why the fifteen months between now and the private-sector acceptance deadline matter more than the eighteen that preceded them.

Lessons from national rollouts that already happened

Europe is not starting from zero, and the useful evidence comes from countries that shipped national identity infrastructure years ago and then had to live with it.

Portugal has run the Cartão de Cidadão for two decades. The card, the middleware that lets it work across operating systems and browsers, the authentication chain behind Autenticação.gov, and later the Chave Móvel Digital together form one of the longer-running national eID deployments in Europe. Caixa Mágica Software developed and maintained the Cartão de Cidadão middleware, which means the hard lessons are documented rather than theoretical: what breaks when a browser vendor changes its security model, what happens to adoption when a driver update fails on one distribution, how much of the support burden falls on the issuer rather than the relying party.

Cape Verde offers a different lesson. NOSi built a national digital identity and service platform in a small state with constrained resources. The constraint turned out to be clarifying. When you cannot afford to build parallel systems for each ministry, you build one identity layer and make everything consume it. Carlos A. Pina has described this repeatedly as an experience beyond technology. The phrase is precise. The technical build was the smaller half of the work. Getting institutions to give up their own user registries was the larger half.

France's ANTS has watched the transition from a card-centric eID to a wallet-centric one from inside the issuing authority. Florent Tournois frames the question as adoption, trust, and impact rather than deployment, which reflects what happens after launch: a wallet that citizens install and never open has satisfied the regulation and failed the mission.

The pattern across all three is the same. The technology ships. The adoption problem is cultural and institutional, and it takes years.

Where trust management sits in the architecture

Trust management is the least glamorous part of the European identity stack and the part most likely to determine whether it works.

David Kelts of Decipher ID has made the case that wallet and login ecosystems need trust management as a first-class component rather than a configuration detail. The argument is straightforward. In a two-party federation, trust is a contract. In an open ecosystem with thousands of issuers and millions of relying parties, trust has to be discoverable, verifiable, and revocable at machine speed, which makes it an operational service with uptime requirements and an incident response process.

Antonio Maio of INCM approaches the same territory from the assurance side. Levels of assurance are only useful if the practices behind them are auditable and comparable. A relying party that accepts "substantial" from 27 different sources is implicitly trusting 27 different sets of enrolment practices, identity proofing rules, and binding procedures. Making those comparable is a governance task with a technical surface, not the reverse.

The uncomfortable implication is that Europe is deploying a system whose weakest link is not cryptography or biometrics. It is registry hygiene: whether trust lists are accurate, whether revocations propagate, whether certification status is current, and whether someone is on call when they are not.

What relying parties should be doing in the next twelve months

If your organisation falls under the acceptance obligation, the mistake to avoid is treating this as a procurement exercise that starts when the deadline gets close.

• Decide what you actually need to verify. Most relying parties over-collect out of habit. Selective disclosure makes it practical to ask whether someone is over eighteen rather than asking for a date of birth, or whether they reside in a member state rather than asking for an address. Every attribute you do not request is an attribute you do not have to protect, justify, or explain to a regulator.
• Plan for partial failure, not just success. Design the path for the citizen whose wallet presentation fails at 23:00 on a Sunday. If the fallback is a support queue that opens Monday, you have built a system that works for the happy path and abandons everyone else.
• Test against wallets from outside your own country early. A relying party that only ever tests against the national wallet will discover cross-border problems in production. Cross-border is the entire point of the framework.
• Instrument the failures. Log which attestations fail, from which issuers, at which step. You cannot contribute to a feedback loop you are not measuring.
• Treat conversion as a security metric. A verification flow that blocks fraud and also blocks a fifth of legitimate users has not made your organisation safer. It has moved the cost from fraud losses to abandoned customers, where it is harder to see and easier to ignore.

Liability is the unanswered question

Every identity system eventually faces the same question, and it is not technical. When a verification is wrong and someone loses money, who pays?

In a closed federation the answer sits in a contract. A bank and its verification vendor agree on responsibilities, define the standard of care, and price the risk. The lawyers settle it before the system goes live.

An open European ecosystem does not have that structure. A Spanish relying party accepts an attestation from a Portuguese wallet, issued by a Portuguese authority, certified by a Portuguese conformity assessment body, running on hardware from a manufacturer neither party chose. The transaction goes wrong. Perhaps the enrolment behind the attestation was fraudulent. Perhaps a revocation failed to propagate. Perhaps the relying party misread an optional field.

Where liability currently sits

The regulation establishes obligations and supervisory structures.1 It does not produce a clean answer to who absorbs a specific loss in a specific cross-border failure. Until case law develops there will not be one. That uncertainty has practical consequences right now.

Risk teams price uncertainty conservatively. A bank that cannot determine its exposure when accepting a foreign attestation will accept it grudgingly, add compensating controls on top, and route those transactions into manual review. The user experience that results is worse than the domestic path, which defeats the purpose. Multiply that across 27 member states and the framework delivers technical interoperability with commercial reluctance layered over it.

There is a second scenario worth planning for. Deadlines in large public technology programmes slip.5 This one involves 27 independent delivery efforts with different starting points. If a meaningful number of member states arrive late, relying parties face an obligation to accept wallets that do not uniformly exist. The likely outcome is a two-speed Europe for a period, where wallet-based flows work well between a handful of well-prepared countries and fall back to document capture everywhere else.

Planning for that scenario is not pessimism. It is the difference between a rollout that degrades gracefully and one that surprises its owners.

The question that decides the outcome

Technical interoperability is a solvable engineering problem, and Europe will largely solve it. Version 3.0 of the Architecture and Reference Framework landed in July 2026 with a wallet conformance framework attached, which is more than the ecosystem had at any earlier point.2 The certification schemes are taking shape. The pilots have found most of the obvious breakage.

The harder question is governance. When a cross-border transaction fails, who owns the failure? When an issuer's practices turn out to be weaker than its assurance level claims, who suspends it, and how fast? When a member state misses the deadline, what happens to the citizens of the states that met it? None of these have clean answers yet, and none of them are technical.

That is the conversation worth having in a room rather than in a comment thread. It needs people who issue credentials, people who accept them, people who certify them, and people who attack them, arguing in the same place at the same time.