The X-Road 8 “Spaceship” development began in January 2024 with a proof of concept (PoC) completed in five months. At the beginning of the PoC project, the main question was: Can X-Road be transformed into a data space technology in a backwards-compatible manner? Based on the outcome, the short answer was yes.
After the initial phase, the development work concentrated on topics and areas identified during the PoC that required further investigation. The work continued through the second half of 2024. This phase was necessary to ensure that the actual implementation could begin with sufficient knowledge of the technical details.
The implementation phase was kicked off at the beginning of 2025. In practice, this meant abandoning the codebase from the PoC phase that had been used to experiment with different approaches and solutions. As a result, the PoC deliverables were less suitable as a basis for a production-level implementation. Therefore, the production-level implementation was initiated by taking the latest X-Road 7 release version (X-Road 7.6.0 at the time) as the foundation and implementing the required changes on top of it.
The first X-Road 8 beta version was released in October 2025, giving users their first opportunity to try out the new version and provide feedback on the changes. The second beta version was released in May 2026, introducing additional enhancements. However, neither beta version included any dataspace-specific changes. Instead, both focused on changes to the X-Road architecture.
In December 2026, X-Road 8 “Spaceship” is scheduled for launch, marking the first production release of X-Road 8. The exact release date has yet to be confirmed, but the launch is planned for week 51. The release will include all the changes introduced in the beta versions, along with several long-awaited dataspace-related enhancements.
Next, let’s take a closer look at what’s included in the release!
Support for the dataspace protocols
X-Road 8 transforms X-Road into a dataspace solution by adding support for the Data Space Protocol (DSP), the Decentralised Claims Protocol (DCP), and the Data Plane Signaling (XPS) protocol. Together, these protocols extend X-Road’s capabilities beyond secure data exchange to support interoperable data sharing across dataspaces, automated contract negotiation, and decentralised identity and trust management. The implementation of the dataspace capabilities is based on the open-source Eclipse Dataspace Components (EDC) project.
In addition, XPS standardises communication between the Security Server's control plane and data plane, enabling a more modular and extensible architecture. The first data plane implementation in X-Road 8 is based on the existing X-Road Message Transport Protocol. Support for additional data planes will be introduced in future minor releases.
Figure 1. Data exchange protocols in X-Road 7.
The dataspace protocols provide standardised mechanisms for establishing trust, cataloguing and discovering data assets, and negotiating data usage agreements. Although X-Road already supports some related capabilities, such as establishing trust and discovering services, the new dataspace capabilities extend rather than replace the existing functionality. In particular, negotiating data usage agreements introduces a new capability that goes beyond X-Road's existing access rights management.
For example, usage agreements can define various conditions for accessing data, rather than simply allowing or denying access based on an organisation's identifier. In addition, usage agreements can specify policies governing how data may be used after it has been exchanged. While traditional access permissions determine who is allowed to access data, they do not specify how the data may be used after it has been transferred.
Figure 2. Dataspace protocol stack in X-Road 8.
Despite the significant changes to the protocol stack, the message protocols between connected information systems and Security Servers remain unchanged. Similarly, the X-Road Message Transport Protocol used for communication between Security Servers remains unchanged. DSP and DCP have been integrated with the existing protocols in a way that is transparent to connected information systems. Achieving this level of backward compatibility was one of the biggest challenges during implementation.
Changes in the component names and terminology
As part of the dataspace transformation, X-Road’s vocabulary is also being updated to align with dataspace terminology. The changes will affect user interfaces, documentation, and the names of components, services, and container images. The changes include, but are not limited to, renaming Security Server to Connector, Central Server to Registry, X-Road instance to dataspace, and member to participant.
The changes will be implemented in two phases. The first phase is included in X-Road 8.0, while the second phase is planned for X-Road 8.1. The second phase will cover the Central Server and Security Server administration APIs, introduce a new version of the SOAP message protocol, and rename internal code and database structures.
Architectural changes
X-Road 8 introduces significant architectural changes at both the component and deployment levels. These changes affect all X-Road components: Central Server, Configuration Proxy, and Security Server.
In X-Road 8, the application architecture has been redesigned to enable better support for containers and cloud as well as more flexible deployment options and improved scalability. The new architecture allows a Security Server instance to run across multiple containers instead of requiring all modules to run in a single container. This deployment model can be managed and orchestrated using Kubernetes-based tools.
However, multi-container deployment will not be available in the initial X-Road 8.0 release and is instead planned for X-Road 8.1. X-Road 8.0 will support native installations on Ubuntu and Red Hat Enterprise Linux (RHEL), as well as containerised deployments using the Security Server Sidecar container image.
Support for the dataspace protocols has also brought new dataspace-related modules in the Central Server and Security Server architecture. The modules are responsible for dataspace-related activities, such as service discovery, contract negotiation, and credential issuance and exchange. They will affect the required network connections between different X-Road components and they will also introduce additional keys and certificates to the architecture.
In addition to the changes described above, X-Road 8 introduces several other improvements. Nearly all configuration data has been moved from the filesystem to the database. Configuration properties that previously required shell access to the host can now be managed through the UI and management API. Secrets are stored in OpenBao, the new secrets management module. And these are just a few examples. The complete list of changes is significantly longer.
Changes to the trust framework
Until now, X-Road’s trust framework has been based on X.509 certificates issued by trusted Certificate Authorities (CAs). X-Road 8 introduces W3C Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) as additional elements of the trust framework. However, this does not mean replacing the existing trust mechanisms. Instead, the new capabilities build an additional layer on top of them.
In X-Road 8, each member has one DID per Security Server on which the member or any of its subsystems is registered. In other words, a member using multiple Security Servers has multiple DIDs.
The Issuer Service running on the Central Server issues membership credentials to X-Road members. These credentials contain the member's identifier and can be used to verify the member's identity and confirm its membership in a specific X-Road ecosystem. A member using multiple Security Servers has a separate membership credential for each Security Server. However, all these credentials contain the same member identifier, as each member has only one identifier within the ecosystem.
The identifier included in the credential is derived from the member's signing certificate, preserving the CA that issued the certificate as the root of trust. The DID documents and credentials are stored in the new IdentityHub module.
At first glance, an X-Road membership credential may not seem to offer much beyond the existing signing certificate. In practice, however, membership credentials can be used in contract negotiation and access control. Furthermore, the dataspace protocol stack relies on verifiable credentials, making their support essential for X-Road 8. Supporting verifiable credentials also opens new possibilities for X-Road, as their use does not have to be limited to membership credentials. Various other types of credentials could be introduced in the future.
For example, an X-Road operator could automatically scan the network ports of all Security Servers registered in the ecosystem and issue a security credential to each Security Server that meets the defined security requirements. Member organisations could then use these credentials to demonstrate to other members that their Security Servers comply with the ecosystem's security requirements. This information could also be used when making service access control decisions. Furthermore, credentials could be issued by other trusted parties, not just the X-Road operator, significantly expanding the range of potential use cases.
High availability
High availability and fault tolerance are important requirements for all X-Road components. Although the X-Road architecture includes centralised components, such as the Central Server and the OCSP service, it has been designed so that the temporary unavailability of one or more of these components does not interrupt data exchange between member organisations.
X-Road 8 introduces a new centralised component, the Issuer Service, which is responsible for issuing credentials and supporting their verification. The Issuer Service follows the same architectural principle as the other centralised components: its temporary unavailability does not interrupt data exchange between member organisations.
X-Road also supports high availability through clustering, available for both the Central Server and the Security Server. Clustering was already supported in X-Road 7, but X-Road 8 introduces some changes to its implementation due to the architectural changes.
For example, a Central Server cluster requires a shared cluster DNS name that provides access to all Central Server nodes through a load balancer. However, the cluster DNS name is used only to access the Issuer Service and the Automated Certificate Management Environment (ACME) challenge port. Other Central Server services continue to be accessed using node-specific addresses, as in X-Road 7.
Another change concerns Security Server clustering. In X-Road 7, a Security Server cluster could use either database replication or a shared database. In X-Road 8, only the shared database approach is supported.
There are also several other changes that will be covered in the release notes and migration guides.
Backward compatibility
X-Road 8 is fully backwards compatible with X-Road 7 at the interface level. In practice, this means the interfaces between Security Servers and connected information systems that act as service consumers or providers remain unchanged. In other words, no changes to connected information systems are required when migrating to X-Road 8. This applies to all supported platforms.
Interface-level backward compatibility also means that X-Road 7 and X-Road 8 Security Servers can communicate with each other. Consequently, different Security Server versions can coexist within the same X-Road ecosystem and communicate across different X-Road ecosystems through federation. However, X-Road 8 Security Servers require an X-Road 8 Central Server and are not compatible with an X-Road 7 Central Server. Therefore, when upgrading an X-Road ecosystem, the Central Server must always be upgraded before the Security Servers.
The upgrade process is largely automated, but some manual configuration changes are still required. The number and nature of these changes depend on the platform (native or containerised) and deployment model (single instance or cluster, local or remote database). X-Road 8 includes an upgrade wizard that automates many of the required changes, although some manual steps may still be necessary. Detailed step-by-step upgrade instructions will be provided with the release.
New documentation platform
As part of the X-Road 8 release, both the documentation and the documentation platform will be updated. The aim is to make the documentation more user-friendly and better meet users' needs. In practice, this means improving the documentation structure, visualising maintenance processes, providing more background information about different features, and explaining key concepts in greater detail.
For example, the new documentation will describe different deployment options, including their advantages and disadvantages, rather than simply providing installation instructions for individual components. In addition, the visual design and overall look and feel of the documentation platform will be refreshed.
What’s next?
Despite the extensive changes introduced in X-Road 8.0, several features have been deferred to future minor releases. For example, full container support (running a Security Server across multiple containers on Kubernetes), technical interoperability with the Gaia-X Trust Framework, and support for “light context” (accessing services without a Security Server on the consumer side) are planned for X-Road 8.1, scheduled for Q3 2027. In addition, interoperability with at least one non-X-Road-based dataspace and phased support for post-quantum cryptography are included in the roadmap.
X-Road 8 “Spaceship” introduces significant changes across all technical layers of the system. These changes transform X-Road into a dataspace solution and lay the foundation for interoperability with other dataspace technologies. This marks the beginning of a new era for X-Road. 🚀
