X-Road security hardening guide

Why X-Road security hardening decides whether a member can exchange data safely

X-Road security hardening is the set of configuration changes that limit what an attacker, or a misconfigured client, can do to a Security Server and the keys it holds. The NIIS hardening guidance, version 0.6 dated 09.01.2025, names account lockout, password length, key-only SSH, the allowed-hostnames setting, HTTPS for global configuration from version 7.4, and firewall exposure as the controls to address. For a member organization, the Security Server is the gateway that every service call passes through, so its hardened state is effectively the member's exposure on the exchange. Security and compliance functions will expect to see that each control was considered, configured and tested, and they will ask for the evidence.

Hardening is harder than it looks because the controls span several layers that most teams manage separately. The operating system (Ubuntu Server 22.04 or 24.04 LTS, or Red Hat Enterprise Linux 8 or 9), the admin UI on TCP 4000, PAM authentication, the PostgreSQL database (local or remote), the network paths and the key storage each carry their own settings. A mistake in one layer can break member connections. For example (illustrative), restricting inbound access to TCP 5500 or 5577 too far stops message exchange and OCSP responses, and an allowed-hostnames value that omits a name clients use will cause requests to fail in ways that look like a partner problem. The hardening change therefore needs the same discipline as any change to a production gateway.

Account lockout and password policy are the controls most often copied from a template without checking how they behave in practice. The guidance recommends locking an account for 15 minutes after 3 failed logins and using passwords of at least 16 characters. Before applying these, confirm how the lockout is implemented on your chosen operating system and PAM configuration, and whether any automation, monitoring or scheduled job retries admin logins. A lockout that blocks a monitoring account during an incident can hide the very problem it was meant to surface. Decide, in writing, who holds the break-glass access path and how it is protected and tested.

The NIIS guidance is a starting point, not a complete control set for your environment. Map each recommended control to your own infrastructure, record any deviation with its reason and an accepted compensating measure, and confirm that each setting applies to the X-Road version you run, since the supported releases include 7.8.3, 7.7.4 and 7.6.5. Test the full set in a non-production environment that mirrors your network and member connections before a change window. Ask any partner for a written control mapping, a test plan and a rollback procedure as deliverables. Note that a mapping supports your assessment, but an independent auditor or certification body, not the implementer, decides whether your controls meet a given requirement.

Which hardening choices to settle before go-live

This table compares the six X-Road Security Server hardening decisions that teams must settle before go-live, with the conditions under which each option fits and the operational cost it carries. Read each row as a choice to make with your security and operations owners, not a default to accept. The main takeaway is that lockout thresholds, admin exposure and HSM placement each trade security against day-to-day operability, so settle them in writing before the first production deployment.

Decision	Option	When it fits	Operational cost
Admin login authentication	Local PAM accounts	Small estates with few administrators and no central directory, or as a break-glass path	Accounts are created, rotated and removed on each server, so offboarding is easy to miss and must be audited per host
Admin login authentication	Directory-backed PAM via SSSD	Organizations that already run LDAP or Active Directory and want one joiner and leaver process	Needs directory connectivity, group-to-role mapping upkeep and a documented fallback if the directory is unavailable
Admin UI on TCP 4000	Reachable only from a management network	Most production estates, where administrators work from a dedicated jump path	Administrators need VPN or bastion access, and firewall rules must be reviewed when networks change
Admin UI on TCP 4000	Reachable from the general internal network	Lab or pilot environments where the admin population is small and trusted	Wider exposure of the admin surface, which the hardening guidance asks teams to limit and assessors will look for
Account lockout threshold	Strict lockout (for example, the guidance's 3 failed logins with a 15 minute lock)	Environments with a high security posture and a documented unlock procedure	Operators get locked out after typos or clock issues, and someone must be on hand to unlock accounts
Account lockout threshold	Looser lockout with monitoring of failed logins	Teams with 24-hour operations staff who need fast recovery and strong alerting	Weaker brute-force resistance, so alerting on failed logins becomes the main control to build and test
Signing and auth key storage	Software keys on the Security Server	Pilots, test environments or deployments where the threat model and procurement accept file-based keys	Lower hardware cost, but key protection depends on host hardening, backups and access controls
Signing and auth key storage	Keys on a PKCS#11 HSM via the hardware token add-on	Production estates where key custody must be demonstrable to assessors	Hardware and support contracts, driver compatibility checks during upgrades, and a tested recovery path for token loss
PostgreSQL placement	Local PostgreSQL on the Security Server host	Single-host deployments with a small operations team and simple backup routines	Database patching, backup and sizing share the host's lifecycle, which complicates OS upgrades
PostgreSQL placement	Remote PostgreSQL, including a managed service	Estates with an existing database platform, managed backups and separate patch cycles	Network paths, TLS and credentials must be hardened, and the database becomes a dependency to monitor
Global configuration transport	Published over HTTPS	Any production member that publishes or consumes global configuration from version 7.4 onward	Certificate lifecycle and trust chain upkeep for the endpoint, which must be planned before go-live
Global configuration transport	Plain HTTP for a controlled test network	Isolated test or training networks with no production trust material	Configuration integrity depends on network controls alone, so it should not carry into production

How to sequence X-Road security hardening without breaking member connections

The sequence starts from a supported baseline and moves from low-impact account controls to changes that affect traffic and keys. Each step closes with a test that the setting took effect and that member message exchange still flows, so any fault can be traced to a single change.

Confirm the baseline and record member traffic
Confirm the Security Server runs on a supported platform: Ubuntu Server 22.04 or 24.04 LTS on x86-64, or Red Hat Enterprise Linux 8 or 9. Record the installed X-Road version and check it against the hardening guidance, which covers publishing global configuration over HTTPS from version 7.4, so confirm your version is at or above that. Take a configuration backup and a copy of the current firewall rules, then run a test message exchange with a known member. Closing check: the backup restores in a test environment, and the test exchange succeeds and is logged as the baseline for every later step.
Set account lockout and password policy
Apply the lockout guidance from the hardening guide: lock an account for 15 minutes after 3 failed logins. Set the password policy to at least 16 characters for all administrative accounts. Admin users authenticate through PAM, so confirm which PAM configuration the Security Server uses, and if you use LDAP through SSSD, confirm where the policy is enforced. Closing check: a test account locks after the third failed attempt, unlocks after 15 minutes, and a new password shorter than 16 characters is rejected. Then confirm a member message exchange still succeeds, since this step changes only administrative logins.
Move SSH to key-only access
Install a public key for each administrator, then disable password authentication for SSH. Keep one existing session open while you change the SSH daemon configuration, and reload the service only after a second session confirms that key-based login works. Confirm that console or out-of-band access is available before the change, so a lockout can be recovered without a rebuild. Closing check: key-based login succeeds from the management network, password login is refused, and the Security Server services and member message exchange are still running.
Set allowed-hostnames against host header injection
Set the allowed-hostnames setting to the host names that administrators and information system clients actually use to reach the Security Server, and to no others. Build the list from DNS records and the operations team's connection inventory, because a missing name will block legitimate access to the admin UI and endpoints. Closing check: requests using each listed host name succeed, a request with an unlisted host header is refused, and member message exchange through the configured address still works. Record the final list in the change record so later renames are reviewed against it.
Publish global configuration over HTTPS
Configure the Security Server so that global configuration is published over HTTPS, following the hardening guidance for version 7.4 and later. Confirm the certificate chain the Security Server trusts for the configuration source, and schedule the change in a window where the configuration refresh can be watched. Closing check: the Security Server retrieves the current global configuration over HTTPS, the configuration timestamp updates, and a member message exchange succeeds after the next refresh. Ask your governance authority to confirm which endpoints the ecosystem uses before the change.
Restrict the admin UI to management networks
Before tightening access, add firewall allowances from internal management networks to TCP 4000, so administrators keep a working path to the admin UI. Then restrict TCP 4000 to those networks only. The admin UI does not carry member message exchange, so this step has low direct impact on member connections, but it is the step most likely to lock out your own team. Closing check: the admin UI loads from a management host, is unreachable from an ordinary user network, and member message exchange is unaffected.
Limit firewall rules to required ports
Allow TCP 5500 for message exchange and TCP 5577 for OCSP from external networks. Allow the internal ports for admin UI access (TCP 4000) and information system access (TCP 8080 or 8443) only from the networks that need them. Set the default inbound policy to deny and record the rule set in version control. Closing check: a port scan from an authorized external test host shows only TCP 5500 and 5577 reachable, a member exchange with another organization succeeds, and internal service consumers still reach the information system endpoint.
Move signing and authentication keys to an HSM
Install the xroad-addon-hwtokens package and the PKCS#11 driver supplied by your HSM vendor, then confirm the HSM supports the RSA or EC keys X-Road uses. Plan the key move with your trust service provider, because moving a signing or authentication key can require certificate registration and a coordinated window, so confirm the requirements for your ecosystem before starting. Closing check: the Security Server lists the token, the keys appear on the HSM, a signed test message verifies at a member organization, and member message exchange still flows after a service restart. Keep the previous key material available until these checks pass.

How X-Road security hardening changes by deployment model

On a single host, the Security Server, its PostgreSQL database, the admin UI and the signing keys share one operating system boundary. The network exposure is the smallest of the four models, so hardening concentrates on the host itself. The NIIS hardening guidance covers account lockout, SSH and password policy, admin UI exposure and host header protection, and each of these applies directly to the one machine.

Controls that shift: Database access is controlled by local authentication and host-level permissions, so the database does not add an external attack path.
Admin access: Restrict TCP 4000 to administrator networks, apply the lockout guidance (15 minutes after 3 failed logins), require key-only SSH and enforce the password length in the guidance (at least 16 characters).
Host header protection: Confirm the allowed-hostnames setting so that requests with unexpected host headers are refused.
New dependencies: The PostgreSQL service and its patch cycle now sit on the same host as the Security Server, so both must be patched together.
Checks: Confirm that TCP 5500 and 5577 are the only ports open to external networks, that 8080 or 8443 are reachable only from internal systems, and that the settings were verified on the running system, not only in the configuration files.

Before sign-off, check the host firewall rules, the admin UI binding and the lockout settings against the NIIS guidance for your X-Road release (7.8.3, 7.7.4 or 7.6.5).

Which access, network and secrets controls matter most in X-Road security hardening

A Security Server sits between your information systems and the wider X-Road ecosystem, so a weakness in any one control area can expose both internal services and trusted exchange. The cards below cover the control areas that deserve the most attention, each with the threat it addresses and what to verify in your own environment.

Administrative roles and who holds them

The Security Server defines five roles: Security Officer, Registration Officer, Service Administrator, System Administrator and Security Server Observer. The main risk is one person holding roles that should be separated, such as registering members and also changing services. Check the named holder of each role, confirm that no account carries every role, and confirm that observer access is read-only.

Admin logins through PAM

Admin users authenticate through PAM, so the account policy applied to the underlying host governs who can sign in to the admin interface. Weak lockout or password rules on the host therefore weaken the X-Road admin plane directly. Verify that lockout thresholds, password length and account removal are enforced on the host itself, and that any LDAP integration maps directory groups to the intended roles.

Admin UI exposure and host header protection

The admin UI listens on TCP 4000 and should be reachable only from administrator networks, never from the internet or from information system networks. Host header injection can redirect or spoof requests if the server accepts arbitrary host names, so the allowed-hostnames setting should list only the names operators actually use. Check the listening address, the allowed host names and the source networks that can reach the port.

SSH access and OS account policy

SSH is the main route for operators to reach the host, so it is a common target for credential attacks. The hardening guidance recommends key-only SSH, which removes password guessing against the login. Confirm that password authentication is disabled, that root login is restricted, that named accounts are used for operators, and that account lockout after repeated failed logins is active.

Firewall scoping by network zone

A Security Server accepts different ports from different zones: TCP 5500 for message exchange and TCP 5577 for OCSP from external networks, and TCP 4000 for the admin UI plus TCP 8080 or 8443 for information system access from internal networks. Mixing these zones lets internal administration reach external listeners or exposes the admin UI to partners. Review each rule against its zone and remove any port that is open to a wider range than its purpose requires.

TLS for global configuration

Global configuration distributes trust anchors and member data to every Security Server, so its integrity matters for the whole ecosystem. The hardening guidance recommends publishing global configuration over HTTPS from version 7.4. Verify that the published endpoint uses HTTPS with a valid certificate chain, that clients are configured to fetch it over HTTPS, and that plain HTTP access is disabled.

Database credentials and key material

The Security Server stores its data in PostgreSQL, whether local or a managed remote service, and signing and authentication keys can sit in hardware security modules through PKCS#11 drivers. Credentials or keys stored in plain configuration files or shared scripts are a frequent source of exposure. Confirm where each database credential and key lives, who can read those files, whether HSM-backed keys are used where your risk model requires them, and how credentials are rotated.

How HSM-backed keys change the X-Road security hardening plan

Moving X-Road signing and authentication keys onto a hardware security module (HSM) changes the hardening plan more than any single setting. Keys that sit in software on the Security Server disk can be copied by anyone with root access to the host. Keys held in an HSM are generated and used inside the device, so the Security Server asks the HSM to sign rather than reading the key itself. X-Road supports this through PKCS#11 drivers, with the xroad-addon-hwtokens package providing the integration, and supports both RSA and EC keys. The first decision is therefore which keys move, and whether your HSM model and PKCS#11 driver are on the compatibility list for your X-Road version.

Confirm two things before design work starts. First, check HSM vendor compatibility and the required driver versions with the HSM vendor and with NIIS, because a driver that works with one X-Road 7 release may not be the one you need for another. Second, confirm how your trust service provider handles certificates and time-stamping for keys generated in an HSM. The key type, where the key was generated, and how it is exported or attested can change what the provider accepts. Settle these with the provider early, since changing the key path after certificates are issued means re-issuing them.

An HSM also adds an operational dependency that a software key does not have. If the HSM is unreachable, the Security Server cannot sign messages, so message exchange stops for every service it hosts. Plan the HSM's network path, redundancy and failover with the same care you give the database connection. Ask the HSM vendor what happens during a network partition, how many clients can connect at once, and how the Security Server behaves when a sign operation times out. Monitoring should alert on HSM reachability as a separate signal from Security Server health, so the team can tell a device fault from an application fault.

Key ceremony and backup procedures become part of the security plan. Document who generates the keys, under which dual control, on which HSM partition, and where the recovery material is stored. Test restore from backup into a non-production HSM before go-live, because a backup that cannot be restored is not a control. Ask the HSM vendor which backup mechanisms apply to your model and whether keys can be exported at all. Some organizations choose non-exportable keys, which removes the copy risk but makes hardware replacement a re-issuance exercise. Record that trade-off in the risk register.

Restrict HSM access to the Security Server service account and nothing else. Limit the PKCS#11 token permissions and the HSM user credentials to that account, keep the HSM client configuration readable only by it, and keep administrator access to the HSM under a separate, audited role. Review the existing hardening controls in light of this change, including the SSH and admin UI restrictions covered elsewhere on this page, because an administrator who can log in to the host could still use the HSM session. Verify the result by attempting access as other local accounts and confirming that each attempt is denied and logged.

What drives X-Road security hardening effort and how to keep it down

This table lists the factors that most change how much work it takes to harden X-Road Security Servers, with a way to reduce each one. Read it before you scope the work, because most drivers multiply across hosts and environments. The main takeaway is that a single build, one hardening baseline and evidence agreed up front usually matter more than any single technical choice.

Driver	Why it changes effort	How to keep it down
Number of Security Servers and hosts	Each host needs its own account lockout, SSH, password, firewall and admin UI settings checked and recorded, so effort grows with host count.	Build one golden image or configuration template and apply it through the same automation to every host. Ask any partner to quote per host and per shared step separately.
OS mix (Ubuntu versus RHEL)	The Security Server runs on Ubuntu Server 22.04 and 24.04 LTS or Red Hat Enterprise Linux 8 and 9. Two operating systems mean two sets of package, PAM, SSH and firewall steps to write and test.	Pick one supported OS family for the whole estate where policy allows. If both must run, keep one baseline with OS-specific sections kept short and tested on each.
Admin login: centralized or local	Local accounts must be locked out, rotated and reviewed on every host. Centralized login through PAM and SSSD against a directory moves that control to one place but adds an integration to build and test.	Decide the login model before hardening starts. If the directory integration is planned, harden the local fallback account once and document it, rather than tuning each host by hand.
Network zones and firewall paths	Ports 5500 and 5577 face external networks, while 4000 and 8080 or 8443 serve internal networks. Each zone and each allowed path needs its own rule, test and evidence.	Write the port matrix once, covering every source, destination and zone. Generate firewall rules from that matrix and test each path with the same script in every environment.
PostgreSQL location	The database can run locally or remotely, including managed services. A remote database adds network paths, TLS and credential handling that must be hardened and evidenced separately from the Security Server host.	Confirm early whether the database is local or remote and whether it is a managed service. Use one connection and credential standard for all Security Servers that point to the same database.
HSM count and vendor	X-Road supports HSMs through PKCS#11 drivers with the xroad-addon-hwtokens package, for RSA and EC keys. Each HSM model needs its own driver setup, key handling procedure and verification.	Limit the number of HSM models in the estate. Document one key-handling procedure and one verification checklist per model, and confirm driver and firmware compatibility with the HSM vendor before work starts.
Global configuration HTTPS and certificates	The hardening guidance recommends publishing global configuration over HTTPS from version 7.4. If new certificates must be bought or issued, procurement and issuance lead times sit outside the technical work.	Start certificate requests as early as possible and confirm who issues them and how long your procurement process takes. Reuse the same certificate profile across hosts where your policy allows.
Environments (test, staging, production)	Each environment needs the same hardening applied and checked, and drift between them is a common source of rework and failed reviews.	Treat the baseline as code and promote it through test, staging and production unchanged. Record each environment's differences in one table so reviewers can see them.
Evidence required by your compliance team	Assessors may ask for configuration exports, screenshots, test results or change records. Discovering these needs late in the project means re-running checks and rebuilding records.	Agree the evidence list before hardening starts, including format, owner and storage location. Collect evidence automatically during each build, not after the fact. DeployOpen prepares evidence for assessors but does not issue audit reports or attestations.

How to verify X-Road security hardening holds and fails safely

Each hardening control needs two tests: one that proves it blocks what it should, and one that proves the server still serves members when the control is active. Run both in a staging copy of the Security Server before changing production. For account lockout, make three deliberate failed logins against a test administrator account and confirm the account locks, then confirm it unlocks after the 15 minutes the NIIS hardening guidelines describe. Repeat the check through the login path your administrators actually use, because PAM-based authentication may behave differently for SSH and the admin UI. For passwords, attempt to set one under 16 characters and confirm it is rejected.

For SSH, attempt password authentication from an allowed administrator host and confirm the server refuses it, then confirm key-only login succeeds with a named administrator key. Keep one existing session open during the change so a lockout does not cut off your only route in. For network exposure, test the admin UI on TCP 4000 from a machine inside the management network and from a user network, where it should be unreachable. Send requests with a host header that is not on the allowed-hostnames list and confirm they are rejected, then send one that is listed and confirm it succeeds. Fetch global configuration over HTTP and HTTPS and confirm only HTTPS responds.

For firewall rules, run a scan from outside your network and confirm TCP 5500 and 5577 are reachable from external networks while the internal ports, including 4000 and the information system ports 8080 and 8443, are not. Compare the results with the firewall's own logs so you can tell a rule problem from a service problem. For HSM-backed signing, confirm the PKCS#11 driver from the xroad-addon-hwtokens package loads and that the key type your HSM holds, RSA or EC, is supported. Run a test message exchange that signs successfully, then make the HSM unavailable in staging and confirm signing fails with a visible error in logs and monitoring rather than quietly falling back to another key.

After every change, run a member connectivity test: a test service call from a member system across the external path, with the OCSP check on TCP 5577 included. Change one control at a time and record the previous setting so you know exactly what to revert. If member traffic breaks, roll back the most recent change first, confirm the connectivity test passes again, and only then diagnose. Avoid reversing several controls at once, and do not disable lockout or the firewall rules broadly to find the fault. Before production work, confirm with your hosting provider how to reach the server through console access if SSH or the network path fails.

What to monitor, back up and re-check after X-Road security hardening

Hardening settles a configuration on a given day, but X-Road Security Servers drift as admins log in, certificates age, OS patches land and X-Road itself moves between releases. The cards below cover what to watch, what to protect and when to test again, with each control tied to a setting, an owner and evidence.

Failed logins and lockouts

The NIIS hardening guidance recommends locking an account for 15 minutes after 3 failed logins, so the lockout itself is a signal worth alerting on. Collect authentication failures and lockout events from the Security Server host and PAM, and review them for repeated attempts against the System Administrator and Security Officer accounts. Confirm that the lockout threshold still applies after any directory or PAM change.

Firewall and SSH configuration drift

The hardened state depends on a short list of open ports, including TCP 5500 and 5577 for external traffic and TCP 4000 for the admin UI, plus key-only SSH and the allowed-hostnames setting. Compare the live firewall rules, sshd configuration and X-Road settings against the approved baseline on a schedule. Treat any unexplained change as an incident until the owner signs off.

Certificate and key expiry

Security Server authentication, TLS for global configuration and the signing and authentication keys all have validity periods that expire without warning. Build an inventory that lists each certificate, its issuer, its expiry date and the person responsible for renewal. Check the inventory before each maintenance window, and confirm the renewal path with your certificate authority or trust service provider.

HSM health and key availability

When keys sit in an HSM through the xroad-addon-hwtokens PKCS#11 integration, a failed HSM link stops signing even though the Security Server process is running. Monitor the HSM connection, token login status and the key slots the Security Server depends on. Ask the HSM vendor which health checks and logs its driver exposes, because this depends on the device and driver version.

PostgreSQL connectivity

The Security Server depends on PostgreSQL, whether local or a managed service, so a database outage or credential change breaks message processing. Monitor connection availability, connection failures and the database account's permissions after each hardening change. For remote or managed databases, also confirm that TLS settings and network paths were reviewed when the hardening baseline was set.

Configuration and key material backups

Backups of Security Server configuration and key material are sensitive, so store them encrypted, restrict access to named custodians and keep them separate from the hosts they protect. Test restores on a non-production host and record the result, because a backup that has never been restored is unverified. Agree with your HSM and certificate providers how keys are recovered if the HSM is lost.

Hardening re-checks after changes

OS patches, X-Road upgrades and changes to firewall or SSH settings can silently reverse hardening. Re-run the hardening checks after each of these changes, and before any upgrade to a supported release such as 7.8.3, 7.7.4 or 7.6.5. X-Road 7 receives security patches beyond 2026 with no decided end date, so track the supported versions and retest after every release.

Control mapping documentation

Maintain a register that maps each hardening control to its exact setting, its owner and the evidence that shows it works, such as a configuration export or a test log. Review the register at each re-check, and update it when a setting or owner changes. This register is the material your internal auditors or assessors will ask for, although DeployOpen prepares the evidence and does not issue audit opinions.

How much effort does X-Road security hardening take, and what do we need to provide?

How much effort does X-Road security hardening take and what drives it?

Effort depends mainly on how many Security Servers and Central Servers are in scope, how standard their hosts are, and how many change approvals the work needs. The NIIS hardening guidelines cover several areas: account lockout, password and SSH policy, admin UI exposure, host header protection, TLS for global configuration, firewall ports and HSM-backed keys. Each area touches a different team, so coordination is often the largest cost. Other drivers include the OS and PostgreSQL setup, whether a hardware security module is already in use, how much existing configuration needs to be tested, and how much evidence the client wants captured. Ask any partner for a written scope that lists hosts, areas and deliverables, since that is what the quote should follow.

Can our internal team harden X-Road on its own using the NIIS guidance?

Yes, a capable internal team can work from the NIIS guidance, provided it has the access and time to test changes. The X-Road security hardening guidelines (version 0.6, dated 09.01.2025) give concrete recommendations, such as locking accounts for 15 minutes after 3 failed logins, passwords of at least 16 characters, key-only SSH, the allowed-hostnames setting, and publishing global configuration over HTTPS from version 7.4. The harder parts are verifying that each change does not disrupt member connections, documenting the result, and agreeing exceptions with the security owner. An external partner is useful when the team lacks X-Road operations experience or cannot spare people for a structured test cycle.

What must our team provide before hardening work can start?

The team should provide access, approvals and a named owner for the evidence. Typical inputs include access to the Security Server and Central Server hosts with OS-level privileges, the ability to change firewall rules through an approval process, access to the PostgreSQL database and to any hardware security module, and the certificates and keys the servers use. Someone must also own the evidence, meaning the person who signs off on configuration records, test results and exceptions. Confirm the exact list with your partner before work starts, including whether test or staging hosts exist, because changes should be proven there first.

How long does X-Road security hardening take?

The duration depends on the same drivers as effort: the number of servers, the variation between hosts, and how long approvals take. Work on a single standard Security Server moves much faster than a set of servers that differ in OS release, database setup or firewall design. Lead times for firewall change approvals, HSM access and maintenance windows often set the calendar more than the technical work does. Ask for a timeline in the written scope that shows which steps depend on client approvals, so you can see where delays would come from.

Does hardening X-Road break connections to other members?

It can, if firewall rules, TLS settings or host header rules change without testing against the connections that depend on them. The Security Server accepts message exchange on TCP 5500 and OCSP on TCP 5577 from external networks, and the admin UI on TCP 4000 from internal networks, so changes to these ports or to the allowed-hostnames setting can affect other members or internal systems. Reduce the risk by testing each change on a non-production server, keeping a documented rollback, scheduling changes in a maintenance window and checking member connections before and after. Confirm with your X-Road governance contacts which members and information systems depend on each port.

Does DeployOpen issue an X-Road compliance certification?

No. DeployOpen does not issue audit reports, attestations or certifications. Its work is to configure, harden and document the systems and to prepare the controls and evidence that an assessor will review. Independent auditors and certification bodies perform the assessment and decide the outcome. Ask any partner to state this in the scope, and ask your assessor which evidence they expect so the hardening records match what they need to see.

How DeployOpen scopes, hardens, hands over and supports X-Road security

DeployOpen plans, implements, hardens, documents and supports open-source platforms inside the client's own infrastructure, and X-Road security hardening follows the same arc. We agree a written, fixed scope, apply the NIIS hardening guidelines to your Central and Security Servers, then hand over evidence and runbooks your team can keep operating.

How we scope

Inventory every Central Server, Security Server and Configuration Proxy, with its host OS, PostgreSQL location and network zones.
Map each NIIS hardening item to a current setting, so the written scope states what changes and what is left for your team.
Agree in writing which items touch member connections, admin access and HSM-backed keys, and who approves each change window.

How we build

Apply account lockout, password policy and key-only SSH settings on each host, recording the before and after configuration.
Restrict admin UI exposure on TCP 4000 and set the allowed-hostnames value to block host header injection.
Enable HTTPS for global configuration distribution and confirm firewall rules for TCP 5500, 5577, 4000, 8080 and 8443 against your network design.

How we hand over

Deliver a hardening report that maps each guideline item to the setting applied, the test performed and any accepted deviation.
Document HSM token configuration, key custody steps and the procedure for rotating admin credentials and certificates.
Walk your administrators through the runbooks and record which checks they will repeat after each X-Road upgrade.

How we support

Support is available as a retainer that covers re-checking hardening after patches and X-Road version changes.
Retainers can include planned re-testing of admin exposure, firewall rules and lockout behavior against the current guideline version.
Ask any provider to confirm response times, release tracking for supported 7.x versions and how they will plan for the X-Road 8 transition.