X-Road implementation plan and cost

What an X-Road implementation involves

X-Road is open-source software published under the MIT license and developed by the Nordic Institute for Interoperability Solutions (NIIS). Because the software carries no licence fee, the cost of an implementation sits in governance, trust services, hosting, integration and member onboarding. The main components are the Central Server, the Security Servers and the Configuration Proxy. Each one needs servers, databases, certificates and people to run, and those costs recur for as long as the ecosystem operates.

There are two starting points. The first is creating a new ecosystem, which means deploying a Central Server, writing the governance rules that define members, roles and trust, and selecting the trust service providers that issue certificates and time-stamps. The second is joining an existing ecosystem as a member, which means deploying one or more Security Servers, obtaining the certificates the ecosystem requires, registering with its Central Server and onboarding your first services. Confirm early which of these you are doing, because the first one carries most of the governance work and the second carries most of the connection work.

Most organizations split the work: their own team keeps governance, day-to-day operations and member relationships, while a partner handles the initial build, hardening and onboarding. Whether a partner is needed depends mainly on the start point, the in-house Linux and PKI skills, and any hardware security module requirement. On versions, 7.8.3 is the current release, with 7.7.4 and 7.6.5 also supported. X-Road 8.0.0 Beta 2 is available for testing, and production release is scheduled for December 2026. Ask the ecosystem operator which version members must run, and check the support timeline before you commit to a version.

What the work includes

The written scope breaks an X-Road implementation into work packages. Each package ends in a named deliverable you keep, so you can check progress and hand over to your own team.

Governance and membership model

We design the trust model your ecosystem will run on: who may join, which member roles exist, how certificates and trust anchors are approved, and who signs off changes. Governance decisions shape the Central Server configuration, so they are settled before any server is built. Deliverable: a written governance and membership model with the operating rules agreed by your stakeholders.

Central Server and Configuration Proxy setup

We install and configure the Central Server and the Configuration Proxy in your environment, then set up the global configuration that member Security Servers download. Confirm which operating system and PostgreSQL option your infrastructure team will support before the build starts. Deliverable: a working Central Server with documented configuration and installation records.

Security Server builds

We build Security Servers on the supported Ubuntu Server 22.04 or 24.04 LTS (x86-64) or Red Hat Enterprise Linux 8 or 9 hosts, and check each host against the minimum memory and disk requirements in the installation guide. Ask the vendor or your platform team to confirm host sizing for monitoring add-ons. Deliverable: built and registered Security Servers with build records for each host.

PostgreSQL connection, local or managed

Each Security Server requires PostgreSQL, either on the same host or a remote instance, including managed services. The choice affects backup ownership, failover and network paths, so decide it per environment. Deliverable: a tested database connection for each Security Server and a note on who owns backups and restores.

HSM integration through PKCS#11

Where your policy requires hardware-backed keys, we connect the Security Server to the HSM through the PKCS#11 driver and the xroad-addon-hwtokens package, for RSA or EC keys. Confirm the HSM model is on your supported list and that your HSM vendor can supply the driver for your OS release. Deliverable: a verified signing key path on the HSM and a test record showing key use.

Member onboarding and test connections

We register member organizations, exchange the required certificates, and run test service calls between Security Servers before any production traffic flows. Onboarding often moves at the pace of the slowest member, so agree a member readiness checklist early. Deliverable: a test report per member connection and an onboarding checklist your registration team can reuse.

Monitoring, runbooks and handover

We set up monitoring for Central and Security Servers, write runbooks for routine tasks and incident response, and hand the environment to your operations team with a training session. Clarify early which admin roles and directory integrations your team will run, since they shape the runbooks. Deliverable: monitoring configuration, a runbook set and a signed handover record.

What drives effort and cost

The factors that move an X-Road quote, why each one matters and how to keep it under control, so you can compare written scopes from different partners on the same basis.

Driver	Why it changes effort or cost	How to keep it down
Number of members and services	Each member needs its own Security Server configuration, certificates, access rights and service registration, and each service needs testing with its consumers. Effort grows with the member and service count, and with how many distinct service types they expose.	Start with a pilot group of members and a short list of high-value services. Agree a standard service description template so each new service follows the same steps.
New or existing ecosystem	Standing up a new ecosystem means building the Central Server, global configuration, trust anchors and governance from scratch. Joining an existing ecosystem shifts work toward onboarding, approvals and aligning with rules already set by others.	If joining, ask the coordinating body for its onboarding checklist and member requirements first. If building, reuse documentation and configuration patterns from established X-Road ecosystems where licensing and governance allow.
Governance complexity and decision makers	Each participant may need agreement on membership rules, service classes, data sharing terms, change control and incident responsibilities. More parties mean more review rounds, and slow decisions extend the project timeline more than the technical build does.	Assign one accountable owner per member and agree the decision log before technical design begins. Ask the partner to include governance workshops and document drafts in the written scope.
Trust service provider and certificate arrangements	Authentication and signing depend on certificates issued through the arrangements you select, and onboarding can wait on certificate approvals. Procedures, lead times and fees come from the provider, so they are not part of the implementation labor.	Confirm the provider, certificate profiles and approval steps early. Ask the partner to list which provider tasks are on the client side and which sit inside their scope.
Hardware security module requirements	If keys must be held in an HSM, the team needs compatible hardware, PKCS#11 driver setup with the xroad-addon-hwtokens package, RSA or EC key configuration and testing of failover. HSM purchase, hosting and vendor support are separate costs.	Confirm early whether policy requires an HSM and which key types apply. Check that the HSM vendor supports PKCS#11 on your chosen operating system before buying.
Hosting topology and operating system	Security Servers run on Ubuntu Server 22.04 or 24.04 LTS, or on Red Hat Enterprise Linux 8 or 9, and are also supported on Docker. Each platform changes packaging, hardening, monitoring and patching work, and multi-site or cloud layouts add network design and firewall rules.	Standardize on one supported operating system family across members where possible. Confirm the Docker or container approach with the NIIS documentation for your target release before committing.
PostgreSQL choice	Security Servers require PostgreSQL, either local or remote, including managed services. A local database is simpler to set up. A remote or managed database adds network, backup, credential and high-availability work that the quote must include.	Decide between local and remote PostgreSQL per environment. If using a managed service, confirm supported versions and connection requirements with the vendor and the installation guide.
Number of environments	Test, pre-production and production each need their own servers, configuration, certificates and member connections. Keeping them aligned, and rehearsing upgrades in test, is often a larger share of effort than the first production build.	Ask for a minimum viable test environment with the same operating system and database as production. Agree how configuration is promoted between environments and who approves each promotion.
Integration with existing point-to-point interfaces	Current direct interfaces must be inventoried, mapped to X-Road services and cut over without breaking member connections. The more undocumented interfaces you have, the more discovery and parallel running the work requires.	Start with an inventory of existing interfaces, owners, data classes and volumes. Prioritize a small set for the first cutover and keep the old interface running until consumers confirm.
Admin identity integration	Central Server and Security Server admin logins can be tied to LDAP or Active Directory through PAM and SSSD, with LDAP groups mapped to the five X-Road administrative roles. Directory design, group policy and testing with each role add effort.	Define the role-to-group mapping on paper before configuring it. Ask for the mapping and a test plan covering each role as deliverables.
Hardening requirements	The NIIS hardening guidelines cover account lockout, password length, key-only SSH, allowed-hostnames settings, HTTPS for global configuration from version 7.4, and firewall rules. Stricter controls for regulated environments require more evidence gathering and testing.	Agree the hardening baseline in writing at scoping. Ask for a hardening checklist mapped to your policy and for evidence to be collected as the build progresses, not at the end.

Project phases and outputs

The sequence moves from governance and trust decisions through a tested pilot to a handed-over production ecosystem, with each phase closing on a named output.

Agree governance and trust design
Your organization and its partners agree the member roles, the trust service providers for certificates and time-stamping, and the security officer and registration responsibilities. The output is a set of signed decisions covering membership rules, trust anchors and operating responsibilities. The phase closes when every party that will operate or join the ecosystem has signed them.
Design architecture and size servers
DeployOpen maps Central Server, Security Server and Configuration Proxy placement, PostgreSQL, HSM use and network paths against the supported operating systems and minimum resource requirements. Sizing follows expected message volume and monitoring needs. The output is an architecture record with sizing, firewall rules and HSM decisions, approved by your infrastructure owners.
Build non-production Central and Security Servers
DeployOpen builds the Central Server and Security Servers in a non-production environment inside your infrastructure, using the release your architecture record specifies, with PostgreSQL and any HSM configured as designed. Admin access, hardening settings and backups are applied and tested. The phase closes with a tested environment and a build record that lists versions, configuration and known gaps.
Prove a pilot connection between members
Two member organizations, typically your side and one partner, exchange a test service request through their Security Servers using the agreed trust services. DeployOpen records the test cases, including certificate handling, access rules and failure behavior, and both parties confirm results. The output is pilot evidence: test logs, a defect list and a signed go or no-go for onboarding.
Onboard members in controlled waves
Members join in waves grouped by readiness and integration type, each following the same checklist for certificates, Security Server installation, service publication and access approval. Registration and connection steps are logged per member. The output is onboarding records for each member, showing the date of registration, the services published and the tests passed before the member moved to production traffic.
Go live and hand over
Production Central and Security Servers go live under the agreed change plan, with rollback steps rehearsed beforehand. DeployOpen hands over runbooks for backup and restore, upgrades, certificate renewal and incident response, and your staff confirm they can use them. The output is a go-live record and accepted runbooks. Timing depends on the drivers covered on this page and is fixed in the written scope.

What to keep in-house and what to outsource

This table compares the X-Road work most organizations keep under their own control with the build and setup work they often hand to a partner, along with the skills each part requires.

Work area	Usually kept in-house	Often outsourced	Skills the work requires
Governance decisions	Choosing the member roles, trust model and ecosystem rules, and deciding who may join and on what terms	Drafting governance options and workshop material for the decision makers	Public sector or industry governance, risk ownership, legal review of member terms
Member agreements	Signing, approving and maintaining the agreements that bind each member to the ecosystem rules	Preparing technical annexes and onboarding checklists that reference the agreements	Contract and legal literacy, data-sharing policy, familiarity with trust service requirements
Business ownership of services	Defining which services are published, who owns each one and who approves consumers	Documenting service descriptions and interface contracts from the owner's decisions	API service design, data classification, service lifecycle management
Operational on-call	Running daily monitoring, incident response and change windows for Central and Security Servers	Writing runbooks, alert thresholds and an initial handover to the internal team	Linux administration, monitoring tools, incident management, change control
Security Server builds	Approving host standards, network placement and the final build before production use	Installing and configuring Security Servers on the chosen Ubuntu or RHEL hosts	Linux administration, package management, X-Road installation and configuration
PKI and certificate handling	Owning certificate policy, trust service provider relationships and renewal accountability	Setting up certificate requests, signing flows and token enrollment during the build	PKI and certificate handling, OCSP and time-stamping concepts, key lifecycle management
PostgreSQL and HSM setup	Providing the database service, backup policy and HSM custody arrangements	Configuring the Security Server database connection and PKCS#11 integration with the HSM	Database operations, PKCS#11 drivers, RSA and EC key handling, backup and restore testing
Network and firewall work	Approving firewall rules and exposure of external and internal ports	Mapping the required ports and writing rule sets for review and testing	Network and firewall administration, TLS, routing and DNS for internal and external networks
Hardening and pilot testing	Accepting the hardening baseline, pilot scope and go-live criteria	Applying the hardening guidance, running pilot message exchanges and documenting results	Security hardening, SSH and PAM configuration, test design, interoperability testing

What usually goes wrong

Most X-Road delays and rework trace back to a few decisions and checks made too late or not at all. Each card names a failure point and the step that prevents it.

Governance decided after build starts

Membership rules, approval of new members, who holds the Security Officer role and who operates the Central Server are often settled only once servers are running. Rework then reaches configuration, onboarding and access. Settle these decisions in writing before the build starts, and confirm them with each prospective member.

Keys, certificates and time-stamping unplanned

Certificate arrangements, time-stamping and HSM key handling are often treated as procurement details. Without a documented procedure for key generation, backup, access and rotation, no one can show who controls the signing keys. Confirm the trust service providers, the PKCS#11 driver and the HSM operating steps before go-live.

Hosts and databases below baseline

Security Servers need at least 3 GB RAM (4 GB with monitoring add-ons) and 3 GB free disk on supported Ubuntu Server 22.04 or 24.04 LTS, or Red Hat Enterprise Linux 8 or 9. PostgreSQL, local or remote including managed services, often gets no backup schedule or restore test. Size hosts above the minimum and name the owner of database backups and restore drills.

Firewall rules blocking X-Road ports

Message exchange and OCSP use TCP 5500 and 5577 from external networks, while the admin UI on TCP 4000 and information system access on 8080 or 8443 stay on internal networks. Generic firewall templates often block one of these flows, and the fault appears only when a test call fails. Map each flow to its source network and test every port before onboarding.

Members onboarding at different speeds

Some members have mature change control and connect quickly, while others need approvals, hosting and certificates first. If the platform team waits for the slowest member, early members lose momentum. If it does not wait, services go live without tested endpoints. Agree an onboarding order, entry criteria and a test plan for each member.

Version chosen without an X-Road 8 plan

X-Road 7.8.0 is the last new-feature release of X-Road 7, and NIIS has not decided how long X-Road 7 will receive bug fixes and security patches beyond 2026. X-Road 8 is in beta testing, with production scheduled for December 2026. Choose a supported 7.x release, such as 7.8.3, and record when the move to X-Road 8 will be assessed.

How the work changes by starting point

Joining means your organization becomes a member of a Central Server that another party operates. Governance is already in place, so the effort centers on your Security Server and onboarding.

Scope: one or more Security Servers, member registration and connection tests against the operator's existing services.
Effort drivers: the number of information systems you publish or consume and the number of environments (test, pre-production and production) you must connect.
Confirm with the operator: approved Security Server platforms, the trust service provider and certificate process, and registration steps with their lead times.
Confirm: which X-Road version the ecosystem runs and whether your servers must match it.

What the client needs to provide

The client's inputs set the start date more than any other item in an X-Road plan. Before installation begins, name one accountable owner for each of three decisions: governance (who approves the rules of the ecosystem), membership (who may join and who signs membership agreements) and trust (which trust service providers issue the certificates and time-stamps). Without these owners, the Central Server configuration and the first member onboarding stall, because each later step needs an approved answer to one of these questions.

Next, confirm the hosts. Each Security Server needs a supported OS, either Ubuntu Server 22.04 or 24.04 LTS on x86-64 or Red Hat Enterprise Linux 8 or 9, with at least 3 GB RAM (4 GB if monitoring add-ons are used) and 3 GB free disk. Ask who provisions the hosts in your cloud accounts or data centers and how long that takes. Decide the PostgreSQL model early: a local database or a remote one, including managed services such as AWS RDS or Azure Database for PostgreSQL. If you use a hardware security module, provide its model, PKCS#11 driver and key type (RSA or EC), since the drivers must be tested on your hosts. Finally, name the owner with authority to open the firewall ports (5500 and 5577 from external networks, 4000 and 8080 or 8443 from internal networks). Change approval often takes longer than the build itself.

Two items need access before configuration. If administrators will sign in through LDAP or Active Directory, provide a service account and read access to the groups that will map to the five X-Road administrative roles, and confirm who owns those groups. Also prepare a list of the services each member will publish, with the system owner, the interface type and the consuming organizations, because service descriptions and access rules are built from it. Finally, collect a named technical contact and an escalation contact at every member organization. Onboarding tests need both people available at the same time, so missing contacts push back the test window for the whole ecosystem.

Questions buyers ask

What drives the cost and timeline of an X-Road implementation?

Scope drives both. Cost follows what is agreed in writing: whether you stand up a Central Server or join an existing ecosystem, how many Security Servers and environments (test and production) you run, how many member organizations you onboard, and how much governance work sits with you. Hardware, databases, hardware security modules, certificates and time-stamping come from your infrastructure and trust service providers, and some of these recur or renew. Timing depends on the same factors plus agreements that other parties must sign. Compare quotes line by line: deliverables, environments, onboarding volume, hardening, handover, and who buys each third-party item.

Can our own team run an X-Road implementation without a partner?

Yes, if the skills and decisions are in place. Your team needs Linux administration, PostgreSQL, PKI, network security and identity skills, plus the authority to make governance decisions. The software is open source and the installation guides cover Ubuntu and RHEL hosts, but the harder work is usually agreements with other members, trust service provider onboarding, hardware security module integration and hardening. Assess those gaps honestly. Many organizations keep operational ownership in house and bring in a partner for specific phases, such as a hardening review or member onboarding.

Should a new X-Road build use version 7 or version 8?

For a production build today, X-Road 7 is the practical choice. The current release is 7.8.3, and 7.8.0 is the last new-feature release of the 7 line. NIIS intends to maintain X-Road 7 with bug fixes and security patches beyond 2026, but it has not decided how long that period will be. X-Road 8 is available as 8.0.0 Beta 2 for testing, with its production release scheduled for December 2026. Confirm which version your ecosystem governance and other members run, and plan a migration path from the start.

What does X-Road need from our organization before work starts?

Named people and decisions matter most. You need an executive sponsor, a governance contact who can sign membership and trust agreements, and an owner for each Security Server host. Technically, you need hosts that meet the supported operating systems and minimum resources, a PostgreSQL database (local or remote), network rules for the required TCP ports, identity decisions for admin logins, and access to your certificate and hardware security module processes. Gather these before the scope is agreed so the quote reflects your actual environment.

Is X-Road free to use, and what does that cover?

The software is free to use under the MIT license. The code is published in the nordic-institute GitHub repository, so there is no license fee for the software itself. That does not cover running costs: servers, databases, hardware security modules, certificates and time-stamping from trust service providers, the staff who govern and operate the ecosystem, member onboarding, and support. The license also does not decide which ecosystem you can join, since that depends on its governance and agreements. Review the license terms with your legal team before you rely on them.

Can DeployOpen issue X-Road certificates or trust status for our members?

No. DeployOpen does not issue certificates, trust status or other ecosystem credentials. Member certificates and trust status sit with the X-Road ecosystem that governs your deployment and with the trust service providers it recognizes, which issue certificates and time-stamps under their own processes. DeployOpen can prepare your Security Servers, key storage, certificate request steps and supporting evidence so that onboarding with your trust service provider is well prepared. Ask your ecosystem governance which providers it accepts and what each one requires.

How DeployOpen scopes and delivers X-Road work

DeployOpen plans, implements, hardens, documents and supports open-source platforms inside your own infrastructure, and X-Road work follows the same written-scope method. The sequence below shows what you receive at each stage of an X-Road implementation plan and cost engagement.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope states whether you are standing up a new ecosystem or joining an existing one.
Scope should name the Central Server, Security Servers, Configuration Proxy and member onboarding count to be covered.

How we build

Build covers Security Server hosts on Ubuntu Server 22.04 or 24.04 LTS, or Red Hat Enterprise Linux 8 or 9, as agreed in scope.
Database design includes local or remote PostgreSQL, including managed services, with the choice confirmed against your environment.
Key storage planning covers software tokens or hardware security modules through PKCS#11, with RSA or EC keys, and firewall rules for the required ports.

How we hand over

Handover documents the installed components, configuration decisions, network ports and role assignments for your operators.
Admin access is set up with the five X-Road roles and, where agreed, LDAP group mapping through PAM and SSSD.
Hardening follows the NIIS security hardening guidelines, with account lockout, key-only SSH and password policy recorded as evidence.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope should confirm which X-Road 7 release line is covered and how X-Road 8 planning is handled.
Ask in the quote whether backups, certificate renewal and patch windows are included in the recurring service.