The EU is investing heavily in creating a comprehensive standards framework for digital identity wallets, with technical specifications for cryptographic protocols and data formats. On paper, this looks like a recipe for seamless interoperability – a wallet issued in Portugal works flawlessly with a service in Poland, because both were built according to the same technical standard.
But standards alone have never delivered on this promise, and the eIDAS 2.0 ecosystem will be no exception.
This isn't pessimism, it's pattern recognition. Every major technology domain has gone through this. Web developers spend enormous effort ensuring their sites work across browsers despite HTML and CSS standards. SQL is an ISO standard, yet databases from different vendors require considerable integration work to communicate effectively. TCP/IP is one of computing's most successful standards, yet network equipment from different manufacturers still requires careful configuration to work together reliably.
The uncomfortable truth is that standards, no matter how carefully crafted, systematically under-determine the software solutions built to comply with them. They leave gaps – some intentional, some accidental – that implementers fill with their own decisions, interpretations, and extensions. These gaps, multiplied across dozens of wallet providers and unique Member State implementations, will create a fragmented landscape of technically compliant but practically incompatible solutions.
The stakes for getting this wrong are enormous. A fragmented eIDAS 2.0 ecosystem doesn't just mean technical headaches, it means undermining public trust in digital government services, creating barriers to a single digital market, and ultimately failing to deliver on the promise of seamless digital identity across Europe. The time to address these interoperability challenges isn't after the first wave of implementations go live and citizens discover their wallets don't work as expected. It's now, while the technical architecture is still taking shape and there's still time to build the additional mechanisms needed to turn standards compliance into genuine interoperability.
To understand why standards compliance won't automatically deliver interoperability across EU Member State implementations, we need to examine the ways that standards fail to constrain implementation choices enough to guarantee seamless integration. Seven fundamental challenges consistently emerge when complex software systems attempt to interoperate based solely on shared standards, each of which will manifest in predictable ways as EU Digital Identity wallets are deployed across Member States.
Seven hurdles to interoperability
1. Standards under-determine implementation
Even the most detailed standards leave gaps that developers must fill when building systems. When developers write code to follow a standard, they're interpreting a blueprint with intentional and unintentional blanks, and each development team will fill those blanks differently based on their priorities, constraints, tendencies, and technical expertise.
These choices compound across the ecosystem. When dozens of technology providers each make reasonable but different implementation decisions, the result is a matrix of compatibility issues that grows with each new participant. Two perfectly compliant implementations can behave quite differently. What looks like simple standards compliance to policymakers becomes a complex interoperability puzzle for technical teams trying to make everything work together in practice.
2. Standards contain ambiguity
While the standards writing process is often impressively meticulous, the fuzziness of human language and the inability to state all assumptions and context results in inevitable ambiguity. When developers encounter these ambiguities, whether they realize the ambiguity or not, they must make judgment calls about the standard's intent.
This isn't necessarily a flaw in standards-writing – it's impossible to anticipate every scenario or define every term with mathematical precision. This means that standards compliance becomes a matter of reasonable interpretation rather than objective adherence.
3. Optional features and extensions
A development team might build a system that strictly follows the core standard while skipping optional features, only to discover that these "optional" components have become widely adopted by other implementations. This creates a situation where full interoperability requires not just implementing the mandatory parts of a standard, but also correctly guessing which optional features will become de facto requirements.
The result is that systems can be technically compliant with a standard yet practically incompatible. What starts as helpful flexibility in the specification becomes a source of fragmentation, where "optional" features gradually become essential for meaningful compatibility in the ecosystem.
4. Version differences
Developing against standards which are rapidly releasing new draft versions is challenging – development teams will often be working with different sets of versions simply due to the nature of development cycles and external constraints. This version fragmentation is acute during the bootstrap phase of new standards and new ecosystems, where early implementations are essential for testing and adoption but are built on moving targets.
Even after standards reach official release status, the version problem persists as new requirements emerge and specifications inevitably evolve. New versions introduce breaking changes, and organizations face difficult decisions about when to upgrade and what level of support to offer to older versions. This creates a perpetual challenge where successful integration requires not just implementing a standard correctly, but implementing the right version of the standard, at the right time, in a way that matches other implementations' choices.
5. Testing and certification gaps
Development teams implement what they believe satisfies the specification, but without comprehensive test suites or certification processes each system will likely handle edge cases – such as malformed certificates or unusual character encodings – completely differently. Certification itself fails if the program focuses on happy-path functionality and basic compliance checks rather than exhaustive interoperability testing.
A testing gap means that two certified implementations can still fail to work together when they encounter conditions not covered by the standard test suite.
6. Proprietary extensions
Organizations often extend standards with proprietary features in order to differentiate their products or address specific customer needs. These proprietary extensions fragment the ecosystem by creating multiple "flavors" of the same standard, each with different capabilities and requirements. The result can be pressure throughout the ecosystem to adopt specific vendor's extensions to maintain competitive functionality, undermining the standard's goal of creating vendor-neutral interoperability.
7. Bugs
No software is infallible, and the inevitable mistakes that happen in any complex development process have a large impact on interoperability. Since regulatory pressure demands practical interoperability, teams are often forced to implement reactive workarounds to accommodate the bugs. When a popular system – whether it is officially or unofficially a reference system – has a bug that violates the standard, other implementers face the choice of breaking compatibility with the system or introducing non-standard behavior to accommodate the flaw.
Concrete steps for true interoperability
1. Comprehensive conformance testing
The EU needs to develop exhaustive interoperability test suites that start with checking whether implementations meet the standard and extend to verifying they actually work together. This means testing edge cases, error conditions, and cross-implementation scenarios that real users will encounter.
2. Country-specific implementation profiles
Rather than hoping Member States will make compatible implementation choices, create explicit "country profiles" that document each nation's specific decisions about optional features, extensions, and implementation details. These profiles should be standardized documents that technology providers can reference to ensure compatibility with specific member state systems.
3. Universal adapter architecture
Instead of requiring every technology provider to integrate directly with 27 different Member State implementations, establish a standardized adapter layer. Each Member State would provide (or have built for them) a standardized "plug" that translates between their specific implementation and a common interface. Technology providers integrate once with the common interface rather than 27 times with unique systems.
Act now or fragment later
The time to implement these mechanisms is now, while technical architecture is still flexible and before incompatible implementations have become entrenched across the continent. Standards get us so far – only proactive interoperability engineering will deliver seamless European digital identity that citizens deserve.
