This case study illustrates how the Guidelines on the Sharing of Interoperability Solutions may be applied in practice to support compliance with Article 4 of the Interoperable Europe Act and its implementation. Focusing on the Interoperability Test Bed, it shows how interoperability solutions can facilitate sharing and reuse between public administrations through different delivery and reuse models. The case study does not provide a legal assessment of the Test Bed itself, but highlights how its main features relate to the operational pathways set out in the Guidelines.
Overview & Context
Across Europe, public administrations operate numerous IT systems that must interact across organisational and national boundaries. Variations in technologies, processes and data models create significant barriers to interoperability, making conformance testing both essential and complex. Conformance testing, the process of verifying that an IT system correctly implements a given specification, is important in ensuring that digital public services function consistently across these boundaries. Yet while interoperability specifications define expected system behaviour, they do not guarantee interoperability in practice.
The Interoperability Test Bed was developed to close precisely this gap. Offered by the European Commission’s Directorate-General for Digital Services (DG DIGIT), it is a reusable service and software platform that enables projects to verify whether systems implementing common specifications can genuinely communicate and exchange data as intended. The Test Bed can be downloaded and installed locally, or reused through a shared online installation operated by DIGIT. All Test Bed software is free to use, including when used as a service, open source and EUPL-licensed.
The platform originates in the European Commission’s ISA Programme and was subsequently developed as a dedicated action under the ISA2 Programme (2016-2020), supporting EU policy frameworks such as the European Interoperability Framework (EIF). Initially conceived as a shared testing infrastructure, the Test Bed evolved into a reusable, modular testing platform in response to repeated needs across projects.
Although the Test Bed focuses primarily on the technical and semantic layers, these often reflect requirements originating from legal and organisational agreements. A recent example is the European Union Agency for Railways, which used the Test Bed’s validators to implement its law-as-code initiative – demonstrating that the platform can also act as an enabler for initiatives originating from legal or organisational interoperability layers.
According to a May 2026 interview with the Test Bed team, approximately 70 projects or user communities are known to use the Test Bed, while its open source components have been downloaded over four million times. These figures should be understood as a conservative picture of known uptake, since the software can be downloaded, deployed and used without contacting the Test Bed team - an approach promoted by the Test Bed’s self-study guides, tutorials and rich documentation.
The Test Bed has also been proposed for the Interoperable Europe Solution label. Based on the maturity framing used in the Guidelines on Sharing Interoperability Solutions, the Test Bed can be regarded as a reusable solution: mature, with stable functionality, structured documentation, and clear governance and maintenance arrangements.
Challenge
The Test Bed did not introduce the concept of interoperability testing as such. Organisations were already carrying out testing before it existed and may still do so without it. The underlying problem, however, was one of duplication and fragmentation. Without the Test Bed or a similarly capable solution, projects often invest significant effort in work that has already been done – effectively reinventing the wheel.
Custom-built solutions typically addressed specific requirements but lacked scalability, usability and long-term maintainability. They also risked overlooking aspects that the Test Bed incorporates through years of accumulated experience – not only at the technical level, but also in areas such as user experience, reporting, orchestration, service delivery and the need to provide a structured testing service rather than a simple text output.
Several concrete examples illustrate this pattern:
The Business Registers Interconnection System (BRIS) initially relied on a custom BRIS emulator that implemented important protocol and validation logic, but lacked a self-service approach and an interface to visualise testing progress for project staff and Member State testers.
In the case of eDelivery, the service moved towards a new generation of conformance testing based on the Test Bed after an experimentation phase, with the new platform finalised and brought online in November 2023. This allowed eDelivery to benefit from richer Test Bed features, including monitoring, customised certificates and badges.
The Electronic Exchange of Social Security Information (EESSI) solution for the exchange of social security information followed a similar trajectory. The Test Bed is used to support a decentralised conformance testing approach, allowing national implementation teams to install a preconfigured testing package on-premise and validate their node implementations earlier in the development process.
More recently, collaboration with ETSI, the European standardisation body, where existing specification-specific tooling could continue to be used while the Test Bed provided additional service delivery, orchestration and reporting capabilities.
At its core, the challenge the Test Bed addresses is straightforward yet fundamental: ensuring that systems implementing common specifications can demonstrably interoperate, providing formal verification rather than relying solely on the assumption that adherence to a specification guarantees interoperability in practice.
The timing of adoption also matters. The Test Bed team observed that projects tend to engage earlier when conformance testing is reflected in high-level requirements, legal texts, procurement documents or standardised project set-ups. Where this is not the case, testing may only be considered later in the lifecycle, which can limit the first version of the testing approach or create additional effort if a project needs to move away from a bespoke solution. This underlines that conformance testing should be foreseen as part of interoperability-by-design, rather than treated as a late technical add-on.
Solution & Features
In response to these challenges, the Test Bed provides value across the entire lifecycle of interoperability solutions. It can be used to assess the clarity and testability of specifications during their drafting, support iterative development through continuous validation, and enable independent testing by third parties during integration phases. In this way, it effectively acts as a technical ‘contract’ between systems, ensuring that implementations adhere to agreed specifications.
Core functionality
The Interoperability Test Bed offers two main categories of solutions: validators and a full conformance testing platform, each addressing different levels of testing needs. Validators enable one-off data validation (e.g. XML, RDF, JSON), while the conformance testing platform supports the execution and monitoring of complex, multi-step interaction scenarios. The key distinction is that conformance testing goes beyond validating data to verifying end-to-end system behaviour, including message exchanges, workflows and interaction logic.
From a functional perspective, the platform interacts directly with systems under test through message exchange, supporting both outbound and inbound communication. Test scenarios can be defined at varying levels of abstraction and may include standard flows, edge cases and error scenarios. Capabilities include simulation of external systems, validation of content and formats, verification of communication protocols, and validation of multi-step interactions – with outputs generated in standardised, machine-readable formats. Importantly, according to Interoperability Test Bed user guide, the Test Bed focuses specifically on technical conformance and interoperability, rather than areas such as performance or security testing.
Deployment flexibility
The solution is highly adaptable in terms of both deployment and use. It can be operated as a centrally managed service, installed locally (self-hosted) with full access to source code, or made available as a decentralised testing toolkit. The DIGIT-hosted Test Bed remains available for projects that are unable or unwilling to host their own instance, while self-hosting is relevant where organisations have specific requirements such as internal network access, the use of sensitive data, access restrictions or full operational control. Self-hosting is the approach most widely adopted by projects, as it offers full control over the resulting service with no external dependencies, and is not only supported but also recommended.
The decentralised model was originally developed at the request of a Joint Research Centre project on maritime information sharing (Common Information Sharing Environment - CISE) and since adopted by other projects, including EESSI. In this model, pre-configured testing packages were shared with testing participants to self-host and use on their side, without relying on a central service. This approach allows organisations to test locally while still relying on a common testing model and reusable artefacts.
The Test Bed components are also designed to be easily customised, integrated and extended. Users can do a considerable amount through the available configuration, customisation and extension features without involving the core team. The team is usually contacted when the intended use moves towards a more novel service delivery model, allowing the project to verify whether the approach makes sense and whether it could benefit from the wider Test Bed community.
To understand how to comply with the obligations of the Interoperable Europe Act when adapting an interoperability solution to your specific needs, including when the obligation to reshare applies and under which conditions adaptations are permitted, consult Pathway 4 of the Guidelines: Sharing adapted interoperability solutions (Article 4(4)).
Open source model and community
The open source nature of the project contributes directly to this adaptability. The Test Bed is not only a hosted service, but also a reusable software asset. Its EUPL-licensed components, public source code, Docker images and documentation make it possible for organisations to reuse, install and customise the solution without depending solely on the Commission-hosted environment.
The user community around the Test Bed is generally open to contributing back. However, contributions do not always take the form of direct code submissions. More often, they emerge through interaction between users and the Test Bed team, when the team identifies that something a project wants to do could also be beneficial for the wider community and builds on that idea. This model allows user needs to feed into the product while avoiding fragmentation into project-specific forks.
In the context of the Interoperable Europe Act, when deciding on the implementation of interoperability solutions, Union entities and public sector bodies must prioritise solutions that do not carry restrictive licensing terms, where solutions are equivalent in terms of functionalities, total cost, user-centricity, cybersecurity and other relevant objective criteria.
If you are deciding whether to implement an interoperability solution, comparing candidate interoperability solutions, or determining the licensing approach for a solution you intend to make available for reuse, explore Pathway 1 of the Guidelines: Prioritising solutions without restrictive licensing terms (Article 4(6)).
Discovery, access, and support
The Test Bed is discoverable through the Interoperable Europe Portal, the EU OSS Catalogue and its presence on code.europa.eu and GitHub, with automation processes ensuring consistency across all channels. To access the software, the primary route is through published Docker images on the Docker Hub or source code on GitHub and code.europa.eu. SaaS versions are also available in the cloud operated by the Test Bed team, and the platform can be used through a shared online instance operated by DG DIGIT. Integration with EU Login simplifies access management, while users can execute tests and receive structured feedback through a user-friendly interface.
Publication of an interoperability solution may be the appropriate approach when broad discoverability and reuse are envisioned. To learn how to publish interoperability solutions, consult Pathway 2 of the Guidelines: Publishing interoperability solutions via the Interoperable Europe Portal or connected portals, catalogues, and repositories (Article 4(3)).
Supporting resources include installation manuals, Helm charts for Kubernetes deployments, structured tutorials on the Interoperable Europe Academy, and an AI assistant trained on the official documentation. In addition, the Test Bed now offers an MCP server – an open standard that provides AI agents with structured access to external data sources, tools and documentation - enabling developers to interact directly with their AI assistant and receive contextual, structured answers grounded in official resources.
Most organisations using the Test Bed are largely self-sufficient. For those that do contact the team, additional support is typically proposed through at least two meetings: an initial orientation meeting, and a quality checkpoint once the project has finished experimenting and before it fully implements its own solution. This approach not only helps users progress independently while giving the Test Bed team visibility over novel or complex reuse scenarios, but also provides users with an expert review of their work.
Direct sharing may be relevant where reuse takes the form of access to a centrally operated service, onboarding support, or the delivery of preconfigured testing packages for local deployment. In the case of the Test Bed, these models complement publication-based reuse by helping users access, configure and reuse the solutions according to their specific operational needs. To learn how interoperability solutions may be shared directly upon request, consult Pathway 3 of the Guidelines: Direct sharing upon request (Article 4(1)).
Technical architecture
At its core lies the GITB Test Bed software, developed within a CEN standardisation initiative and built on standardised APIs (REST and SOAP), enabling integration with external components such as domain-specific validators or simulators. The architecture also includes a Test Registry and Repository for managing test artefacts and enabling reuse.
Governance & Stakeholders
The Interoperability Test Bed is governed by the European Commission’s Interoperability and Digital Government Unit within DG DIGIT, which is responsible for its operation, maintenance and continuous development. The team provides the core infrastructure, ensures platform stability and steers its long-term evolution, while also supporting projects in designing and implementing testing approaches.
The Test Bed serves a broad ecosystem of stakeholders, including EU institutions, national administrations, EU agencies, international organisations, academia and private sector actors. Within this ecosystem, system owners define and configure test scenarios, while developers and operators execute tests and analyse results. The Commission maintains an overarching role, ensuring coherence and integrating feedback into the platform’s evolution.
Financially, the Test Bed is funded under the Digital Europe Programme and forms part of DG DIGIT’s broader effort to provide reusable interoperability solutions. The current delivery model does not rely on formal cost-sharing. Most organisations deploy and manage their own instances or use the Commission-hosted service, while contributing primarily through feedback and exchange, which directly informs the platform’s development.
A key aspect of the governance model is its user-driven approach. Priorities for new features and improvements are largely based on feedback collected through GitHub, code.europa.eu, functional mailboxes and direct interaction with users. While individual requests are considered, decisions also take into account relevance across multiple projects, long-term value and alignment with future developments. Strategic directions are decided within the core team at project management level.
If labelled as an Interoperable Europe Solution, the Test Bed would also be considered during the interoperability assessments that are mandatory under Article 3 of the Interoperable Europe Act.
Impact & Adoption
The Interoperability Test Bed has achieved broad adoption across EU and international contexts, demonstrating its flexibility and relevance across different domains. Its impact can be understood not only through the number of known projects and downloads, but also through the way it reduces duplication, supports trusted onboarding and helps organisations provide evidence that systems have implemented specifications correctly.
Efficiency gains
By replacing or complementing bespoke testing solutions, projects can reduce development effort and maintenance costs and focus on their core functionality. In many cases, the Test Bed is not used as a direct replacement, but as an additional layer that enhances existing tools with capabilities such as reporting, monitoring and orchestration.
Building trust through formal verification
At its core, the Test Bed’s impact lies in increasing trust in interoperability solutions. By providing structured, transparent and repeatable testing processes, it enables organisations to demonstrate conformance to third parties – for example during onboarding, procurement or certification. Two main types of scenarios illustrate this:
In EC-driven cross-border projects, Member States must prove that they have tested with the Test Bed and passed the relevant test before they are allowed to interoperate and engage in live exchanges in the production system. A similar approach is also applied in national contexts, where the entities being tested may be other actors (such as local data providers).
eInvoicing software vendors, for instance, had to prove conformance testing results on the Test Bed in order to apply for grants. Similarly, eDelivery access point vendors must formally test against the eDelivery conformance testing service and receive conformance certificates and badges that can be referenced in procurement.
In some cases, the Test Bed is already a requirement at procurement stage – including in the European Union Agency for Railways, the SIMPL programme, and the European Health Data Space.
International reach
Adoption extends well beyond the EU. The World Health Organisation (WHO) has officially adopted the Test Bed as its conformance testing solution, while initiatives such as RACSEL have used it to support cross-border eHealth interoperability in the Americas (specifically in the Caribbean, Central America and South America). In this case, the Test Bed was used for testing related to areas such as the issuing of yellow fever vaccination certificates. Additional usage is observed in other regions (such as USA, Canada and India) through community channels and usage statistics.
This international reach is supported by the Test Bed’s open source model, its backing by the European Commission, and its active user community – all of which contribute to confidence in its long-term sustainability. The Test Bed is the solution with the most subscribed members on the Interoperable Europe Portal and has a visible track record of releases, giving organisations confidence that the solution is actively maintained and worth investing in.
Lesson & Reuse
The experience of developing and scaling the Interoperability Test Bed highlights a set of conditions that are important for an interoperability solution to be genuinely reusable in practice.
A central lesson is that reuse must be designed deliberately from the outset. While many solutions may appear technically reusable, adapting them beyond their original context often requires additional effort. In contrast, the Test Bed was built as a domain-agnostic solution, with modular architecture, standardised interfaces and flexible deployment models - enabling its use across a wide range of scenarios.
A key enabler of reuse is the open source model, combined with permissive licensing and long-term institutional support. The Test Bed’s availability as free and open source software, backed by the European Commission, provides both accessibility and trust –reinforced by sustained funding under the Digital Europe Programme.
The emphasis on high-quality, publicly accessible documentation is another important factor. The Test Bed provides structured guides, tutorials and technical resources that allow users to work independently and progressively build their expertise. This reflects a broader principle: if a solution requires constant expert intervention to be used effectively, it is not fully reusable.
The Test Bed demonstrates that reusable interoperability solutions depend on more than platform code. Validators, test suites, schemas, configuration patterns, examples, documentation and governance practices all shape whether a solution can be adopted and maintained in another context.
Continuous feedback from the user community is the primary driver of improvement. Contributions typically take the form of ideas and requirements, which are then generalised and integrated into the core platform in a way that remains broadly applicable – allowing the Test Bed to grow without becoming tied to specific use cases.
Simplified installation and update processes, support for different deployment models, and backward compatibility guarantee reduce the effort required to adopt and sustain the solution over time.
The Test Bed also demonstrates that reuse does not necessarily mean replacing existing solutions. In many cases, it is most effective when used as a complementary layer, orchestrating or enhancing existing tools. This flexibility allows organisations to build on prior investments while progressively improving their testing capabilities.
Finally, the Test Bed’s position as a high-potential candidate for the Interoperable Europe Solution label supports wider awareness of conformance testing and encourages its consideration earlier in project lifecycles. More broadly, it reinforces the idea that demonstrating interoperability through structured testing is a key condition for enabling trust, sharing and reuse across administrations.
Discoverability and reuse may depend on interoperability between the Interoperable Europe Portal and connected portals, catalogues or repositories. To learn how to establish such connections, consult Pathway 6 of the Guidelines: Connecting portals, catalogues, and repositories to the Interoperable Europe Portal (Article 8(4)).
