X-Road cost of ownership

The infrastructure line is the part of X-Road cost of ownership that most teams can size early, because it is set by the Security Server platform requirements published by NIIS. The Security Server is supported on Ubuntu Server 22.04 and 24.04 LTS on x86-64, and on Red Hat Enterprise Linux 8 and 9. The installation guide sets a minimum of 3 GB RAM, rising to 4 GB when monitoring add-ons are running, and 3 GB of free disk space. Those are floors, not sizing advice. Your message volume, the number of services you publish and the monitoring you run will determine how much headroom you need, so confirm current sizing for your own volume with the NIIS Security Server installation guide and your hardware or cloud vendors before you write a quote.

Every Security Server also needs PostgreSQL, either local or remote. The installation guide names managed services such as AWS RDS and Azure Database for PostgreSQL as supported options. The choice is a real cost decision. A self-managed local database keeps the licence cost at zero but places patching, backup, failover, storage growth and restore testing on your staff or your partner. A managed database moves much of that work into a recurring service fee, and the fee scales with instance class, storage, backup retention and high-availability options. Ask whether the database sits in the same network zone as the Security Server, how it is backed up, and who owns the restore test. Those answers change the staff line more than the database price itself.

Hardware security modules are a separate line. X-Road supports HSMs through PKCS#11 drivers using the xroad-addon-hwtokens package, with RSA and EC keys. The software integration is open source, but the HSM hardware, its licences, its maintenance contract and the staff who administer partitions and keys are not. Decide early whether signing keys for your members will live on an HSM, in a cloud key service that exposes PKCS#11, or in software tokens on the Security Server. Each option moves cost between capital purchase, subscription, support and audit evidence. Confirm with your HSM vendor which PKCS#11 driver versions they support on your chosen operating system and whether they supply support for the X-Road integration.

When you request quotes, ask each vendor and partner to show servers or instances by role (Security Server, Central Server if you run one, Configuration Proxy if used), the database service tier and its backup terms, and the HSM model with maintenance years. Ask which items are one-time, such as hardware purchase and initial build, and which recur, such as cloud instances, database fees, HSM support and operating system subscriptions. Also ask what happens to these lines when you add members or move to a new X-Road release, because each upgrade or migration reruns part of this infrastructure work. Treat the figures you receive as your own estimate until they are checked against NIIS sizing and your environment.

For most X-Road deployments, the largest recurring cost is people, and the open-source license does not show it. Because the software is MIT licensed, the budget question shifts to who operates the ecosystem. An operator typically needs administrators who hold the five administrative roles of the Security Server: Security Officer, Registration Officer, Service Administrator, System Administrator and Security Server Observer. Beyond those roles, someone must run member onboarding and the onboarding tests a new member passes before going live. Each role is a line item, whether it is filled by internal staff, a partner or a mix. Ask any quote to name each role, the person or team that holds it, and whether the duty is a steady monthly load or a peak load.

Role counts grow with the number of member organizations, but not in a straight line. A small operator with a few members may cover all five roles with a handful of people, and separation of duties then becomes the constraint, since the people who approve a change often should not be the people who make it. As membership grows, registration and onboarding work rises with each organization admitted, while security officer work tracks the number of certificates, trust service relationships and incidents to handle. Your governance model sets the thresholds. Document who can approve a new member, who can revoke one, how many people must be available for each role and what hours of cover you need. Those answers determine when you need the next person.

Access management is where the platform choice affects effort most visibly. The Security Server authenticates admin users through PAM, and PAM can connect to LDAP through SSSD so that directory groups map to X-Road roles. With that in place, granting or removing an administrator becomes a group membership change in the directory, which removes the need to edit local accounts on each server. That lowers the cost of joiners, movers and leavers and makes access reviews easier to evidence. It does not remove work. Someone still owns the directory groups, the role mapping and the review schedule, and those tasks recur. The admin SSO topic covers the mapping in detail. Confirm with your identity team who runs the directory, how often access is reviewed and whether the mapping falls under their existing support.

Connecting a new member takes calendar time as well as staff time, and much of that time sits in steps that depend on the member's own environment. The operator typically registers the member, prepares or verifies its certificates and Security Server, and runs the onboarding tests before the member is allowed into production exchange. No duration is given here because it depends on the member's readiness, its network approvals and the trust service steps in your model. Ask the implementation partner for a plan that lists each step, the party responsible for it and the waiting time you cannot control. Each member then adds recurring work: certificate renewal, access changes, monitoring, incident contacts and retesting when a platform upgrade changes behavior.

Size these roles from your governance model and the decisions it requires. Start with the decisions: who approves members, who approves changes to trust settings and who signs off on access reviews. Then add the service expectations: the hours in which an incident must be handled and the number of people who must be reachable for each role. Finally, count the current members and their expected rate of change, because onboarding and renewal load follow membership. Ask for a quote that shows each role as a fixed cost or a per-member cost, and that states which costs are one-time and which recur every year. If the quote cannot separate them, the totals will be hard to compare across partners or against your own team's estimate.

Ask for the quote only after you can state the inputs that drive it. The number of member organizations and Security Servers you expect determines how many servers, certificates and onboarding sessions the work covers, so give a figure for the first year and another for the end of year three. Expected message volume matters as much, because it shapes how the Security Servers and their PostgreSQL database are sized. Give average and peak daily volumes, the main message types and the expected growth, even if the estimate is rough. Each Security Server host must meet the minimum of 3 GB RAM and 3 GB free disk space, with 4 GB RAM when monitoring add-ons run, so state your current host standard and whether it already meets that baseline.

Next, describe where X-Road will run and how it will connect. Cloud, data center and air-gapped deployments differ in who operates the infrastructure, how external traffic reaches TCP 5500 and 5577, and whether managed services are available at all. Network teams should confirm which internal networks reach the admin UI on TCP 4000 and the information system access ports 8080 or 8443. For the database, state whether each Security Server uses a local PostgreSQL instance or a remote one. If you prefer a managed service such as AWS RDS or Azure Database for PostgreSQL, name the team that owns its backups, patching and access. Also state whether a hardware security module already exists, its model, and who administers it, since keys held in an HSM are handled through the PKCS#11 driver path and the quote must reflect that work.

Certificates and time-stamping are the next inputs. Tell the provider which trust service providers you intend to use or already have contracts with, and whether you operate an internal certification authority that could issue component or member certificates under your policy. Confirm with those providers the lead times, fee structure and renewal terms, since the quote can only reflect them once they are known. Then describe identity arrangements for administrators. If you plan to centralize logins through PAM and SSSD, name the directory (LDAP or Active Directory), the group structure, and who approves the mapping of directory groups to the five X-Road roles: Security Officer, Registration Officer, Service Administrator, System Administrator and Security Server Observer.

Finally, name an owner for governance, security and operations, and list the member contacts who will approve onboarding. Governance decides membership rules and the trust model, security approves key handling, hardening baselines and HSM administration, and operations carries patching, backups and incident response. Without named owners, decisions stall and the quote cannot assign effort to a person. Any answer you cannot give becomes an assumption in the quote. Write each assumption down with the date and the person who accepted it, and ask the vendor to restate the full list in the written scope. When an assumption changes later, such as a new member wave or a different database arrangement, the change should go through a written change request so cost and timeline move with it.