Cyber-security as the foundation of rail operational resilience

The problem

Rail systems that were historically mechanical and electrically isolated are now digital, networked, and in many cases wireless. Interlocking systems that once operated through relay logic now run on software platforms with networked maintenance interfaces. Onboard units communicate over GSM-R and increasingly over FRMCS/5G links. Trackside controllers, signalling systems, and passenger information systems sit on shared IP networks.

This digitalisation introduces a class of risk that these systems were never designed for. A signalling system that is functioning correctly but has been silently compromised is not available in any meaningful sense. Its integrity is unknown, and therefore its safety state is unknown.

In rail, resilience is no longer about patching or replacing equipment. It depends on knowing the state of every asset and spotting anomalies before they threaten safety or service.”

The core technical problem: how do you maintain assurance of system integrity in environments where OT assets are network-accessible, but cannot be patched, scanned, or hardened using standard IT methods?

Rail OT constraints

Rail OT environments violate the assumptions that conventional cyber-security tooling is built on:

1. No patching windows - A metro system running 20-hour service days cannot take interlocking systems offline for vulnerability remediation. Safety-certified systems (SIL 3/4) require re-certification after software changes, a process measured in months.
2. Protocol opacity - Rail-specific protocols like Subset-026 (ETCS) and TRDP (Train Real-Time Data Protocol) do not map to standard network monitoring signatures. A NIDS that cannot parse these protocols has no visibility into the traffic that carries operational commands.
3. Decades-long asset lifecycles - Trackside equipment routinely operates for 25-30 years. These systems were designed for safety and reliability in isolated environments. Retrofitting zero-trust architecture onto a relay-based interlocking from 2003 is not feasible without full re-engineering.
4. Safety-critical failure modes - In IT, the standard incident response is to isolate the compromised host. In rail OT, isolating a compromised trackside controller could strand trains or create an unsafe state. Containment actions must be evaluated against the system’s safety case before execution.

These constraints mean that rail requires its own security engineering discipline, one where safety analysis and threat analysis are performed together, not in separate silos.

Regulatory requirements

The EU’s NIS2 Directive classifies rail transport as an essential service, imposing mandatory risk management measures, incident reporting obligations, and supply chain security requirements. The EU Cyber Resilience Act requires manufacturers of products with digital elements (onboard computers, wayside controllers, communication gateways) to maintain documented security properties and vulnerability handling processes throughout the product lifecycle. In the U.S., TSA Security Directives mandate network segmentation and continuous monitoring for surface transportation operators.

The common requirement across all of these: continuous visibility into OT environments. Point-in-time assessments are no longer sufficient. Operators must demonstrate what is on their network, how traffic flows between zones, and how anomalous behaviour would be detected.

TS 50701 provides the technical framework for implementation. It requires threat analysis at the integrated system level, not just at the component level. In practice, this means understanding attack surfaces that span subsystems from multiple suppliers: the interfaces between them, the trust boundaries, and the assumptions each vendor made about the environment their equipment operates in.

This is structurally similar to how the industry already builds safety cases. The difference is that the threat model is adversarial rather than stochastic.

Why monitoring is the primary control

In IT environments, resilience comes from prevention: patching vulnerabilities, hardening configurations, segmenting networks, replacing end-of-life systems. In rail OT, most of these options are either unavailable or severely constrained. You cannot patch a SIL 4 interlocking on a quarterly cycle. You cannot replace trackside equipment that has 15 years of operational life remaining. You cannot isolate a compromised controller without evaluating the impact on train movements.

When prevention is limited, resilience depends on detection: knowing the state of your assets, identifying when something deviates from expected behaviour, and having enough context to respond without disrupting operations. Continuous monitoring becomes the mechanism through which operators maintain assurance of system integrity across environments they cannot fully harden.

Cyber-security must be part of operational practice, not a standalone compliance exercise. Monitoring, context, and coordinated response are the foundation of safe, reliable rail service.”

This is not monitoring as a compliance artefact. It is monitoring as the operational foundation for safe, continued service when threats are present.

Architecture principles for rail OT monitoring

Given these constraints, effective monitoring in rail OT environments must be built differently from IT security monitoring. Three principles are central:

1. Rail asset and context awareness - A monitoring system for rail OT must understand what it is looking at. That means identifying specific asset types (interlockings, RTUs, onboard units, communication gateways), their role in the network, their expected communication patterns, and their operational context. Without this understanding, a security system cannot differentiate between a legitimate configuration change to a wayside controller and an unauthorised one. Generic network monitoring sees packets. Effective rail OT monitoring sees assets, their functions, and their relationships to the operational environment.
2. Operational behavioural baselines - Rail networks have deterministic operational patterns: train movements follow timetables, signalling states follow interlocking logic, maintenance access follows schedules. Deviations from these baselines, whether caused by cyber-threats, misconfigurations, or equipment failures, are detectable when the monitoring system models expected behaviour from the railway’s operational logic. This is more effective than generic network anomaly detection because the baseline is grounded in the system’s functional specification, not statistical traffic norms.
3. Safety-constrained response - When an anomaly is detected, the response must be evaluated against the operational context. A suspicious connection to a lineside cabinet during a scheduled maintenance window has a different risk profile than the same connection during peak service. Automated responses must be constrained by safety requirements. The security system must never create a more dangerous state than the threat it is responding to.

Integration challenge

The remaining problem is largely organisational. Security monitoring, signalling engineering, and operations are typically separate functions with separate tooling and reporting structures. Effective rail OT security requires these groups to share a common operational picture and coordinated response procedures.

Operators who build this integration into their engineering processes will have better incident response, more accurate risk assessment, and stronger compliance posture. Those who treat cyber-security as a standalone compliance function will continue to have blind spots at the boundaries between systems.