X-Road® is open-source software for secure, standardised data exchange between organisations. It is the data exchange layer behind Estonia's e-government (there it is called X-tee), it is used nationally in Finland and Iceland, and it is maintained by the Nordic Institute for Interoperability Solutions (NIIS). Each participating organisation runs its own Security Server; data travels directly between Security Servers, signed, encrypted and logged on both sides, while a Central Server only keeps the registry of who is allowed to talk to whom. Unified Techs is an X-Road Technology Partner recognised by NIIS; this guide is what we tell organisations that are deciding whether, and how, to adopt it.
Where X-Road is used
The best-known deployment is Estonia's X-tee, which has been in national use for well over a decade and handles about 13 million queries a day across more than 4,500 data services (figures published by RIA, the Estonian Information System Authority). Finland runs the same software as Suomi.fi-palveluväylä and Iceland as Straumurinn; the three countries own NIIS, which has developed and published X-Road since 2018, with the Faroe Islands as a partner. X-Road is listed as a Digital Public Good, released under the MIT licence, and has been adopted or piloted by governments on several continents and by private organisations that need the same guarantees between companies.
The reason it travels well is that it solves an organisational problem, not just a technical one: how do hundreds of independent organisations exchange data with proof of who asked, who answered, and when — without a central database that sees everything?
How it works, in plain terms
Members, subsystems and services. An organisation joins an X-Road ecosystem as a member. A member registers one or more subsystems (for example "tax-portal" or "population-register-client"), and a subsystem publishes services — REST or SOAP APIs — or consumes services published by others.
The Security Server. This is the component you operate. It sits between your internal systems and the network, and for every message it:
- authenticates the other party with certificates (mutual TLS between Security Servers),
- signs the message with your organisation's signing key and timestamps it, so both sides hold evidence that stands up later,
- enforces access rights: a provider explicitly grants each consuming subsystem access to each service; nothing is open by default,
- writes a message log; the body of messages can be logged or not, per subsystem, and logs can be encrypted at rest.
Keys can live in software or in a hardware security module (PKCS#11), which regulated ecosystems usually require.
The Central Server. Operated by the ecosystem's governing authority — not by every member — it holds the list of members, subsystems, Security Server addresses and the global configuration, and it distributes that configuration to all Security Servers. It never sees business data. The same authority also runs or contracts the trust services: a certification authority that issues authentication and signing certificates (with OCSP for revocation checks) and a timestamping service.
Data flows peer-to-peer. Consumer Security Server → provider Security Server, directly. There is no message bus in the middle, which is why X-Road scales horizontally and why one organisation's outage does not stop the others.
Joining an ecosystem vs creating one
This is the first decision, and it decides most of the cost.
Joining an existing ecosystem (a national X-Road instance, or a sector consortium that already runs one) means you operate a Security Server, obtain certificates from that ecosystem's CA, register your subsystems, and connect your applications. The governing authority handles the Central Server and trust services. This is the normal case for a ministry, agency, municipality, hospital, bank or company that needs to exchange data with institutions already on the network.
Creating a new ecosystem means also operating the Central Server, selecting or running a CA and timestamping service, defining membership rules and the onboarding process, and keeping it all running. That is a programme, not a project; it is what a national authority, a regional body or a large group of organisations takes on. NIIS's documentation is explicit that Central Server operation needs Linux, networking and X-Road expertise.
If you are reading this as a buyer, you are almost certainly in the first case.
What you actually have to run
For a joining member the footprint is small:
- One Security Server to start. NIIS publishes packages for Ubuntu and Red Hat-family Linux, and a container image — the Security Server Sidecar — for Docker and Kubernetes. The documented minimum hardware is modest (on the order of a two-core server with a few gigabytes of RAM for the conventional install; check the installation guide for the exact figures for your version).
- A second Security Server when availability matters. X-Road supports several Security Servers per member for redundancy and load balancing; most production members add the second one once the first service is live.
- Certificates from the ecosystem's CA for authentication and signing, and, where required, an HSM to hold the keys.
- An adapter on your side: your application has to speak the X-Road message protocol. For REST services that is usually a thin layer or none at all; for legacy systems it is an adapter service that translates between the X-Road interface and whatever the system speaks.
- Monitoring and operations: certificate expiry, OCSP and timestamp availability, software updates (NIIS releases regularly; ecosystems set deadlines for upgrading), and log retention.
None of this is exotic for a team that already runs Linux services or Kubernetes. The parts that catch organisations out are the operational ones — expired certificates, missed upgrade deadlines, an adapter nobody owns after the project ends.
How an implementation goes
The sequence is the same whether we do it or you do:
- Scope — which services you will consume, which you will provide, in which ecosystem, under which rules (data protection, logging, availability).
- Membership and trust — apply to the ecosystem, obtain certificates, decide software keys or HSM.
- Security Server deployment — packaged install on a VM, or the Sidecar on Docker/Kubernetes; network rules; hardening; backups.
- Adapters and services — expose your APIs as X-Road services or build the adapter for the legacy system; register subsystems and services; request access rights from providers.
- Testing — most ecosystems have a test instance; use it before touching production.
- Go-live and operations — monitoring, upgrade policy, a second Security Server, and someone on call who knows X-Road.
Who runs it for you
Three options, in increasing order of what you hand over:
- In-house. Your platform or infrastructure team operates the Security Server. Right choice if you already run Linux or Kubernetes services with on-call cover and can spare the time to learn X-Road's specifics.
- A managed service provider. NIIS's own guidance for small organisations says it plainly: have a managed service provider operate the Security Server if you don't have Linux and security expertise in-house. The provider installs, monitors, upgrades and renews; you own the data and the member identity.
- An X-Road Technology Partner. NIIS lists companies with verified X-Road expertise on x-road.global. Unified Techs is one of them. We design and deploy Security Servers (packaged or on Kubernetes), build adapters for existing systems, take organisations through onboarding to an ecosystem, and operate the result as a managed service with AWS and Kubernetes engineers across CET, GMT and EST hours.
If you are weighing X-Road for a ministry, agency, hospital, bank or group of companies, the practical questions are: which ecosystem, how many services, what availability, and who is on call at 02:00 when a certificate expires. We are happy to go through those with you — see our X-Road practice page or write to business@unifiedtechs.net.
Frequently asked questions
Is X-Road only for governments? No. It was built for the public sector and that is where the national ecosystems are, but any group of organisations that needs signed, access-controlled, auditable data exchange can run or join an X-Road ecosystem, and private companies are members of the national ones.
Does X-Road replace our APIs? No. Your services stay REST or SOAP APIs. The Security Server wraps them with identity, access control, signing and logging; consumers call them through their own Security Server.
Can we run X-Road on Kubernetes or in the cloud? Yes. NIIS publishes the Security Server Sidecar for Docker and Kubernetes, and the packaged install runs on any Linux VM, including AWS. Keys can be kept in an HSM or a cloud HSM service through PKCS#11.
How long does it take to join an ecosystem? It depends mostly on the ecosystem's onboarding process and on how many legacy systems need adapters. Deploying and registering a Security Server is days of engineering work; the certificates, approvals and access-right requests from other members are usually what sets the calendar.
What does it cost? The software is free (MIT licence). The costs are the servers, certificates and any HSM, the adapter work for your systems, and the people who operate it — in-house or as a managed service, priced per engagement.
Sources: NIIS and X-Road documentation at x-road.global and docs.x-road.global; RIA, "Data exchange layer X-tee" (ria.ee); Digital Public Goods Alliance registry entry for X-Road. X-Road® is a registered trademark of NIIS.