Modern rolling stock depends on connected digital systems. Understanding operational technology (OT) is therefore essential to fleet performance, maintenance, cyber security and whole life support.
IT and OT failures can look the same. A screen freezes, a device stops responding or a connection drops. The difference is the consequence.
If an email platform fails, people lose access to a business service. If an onboard control system fails, the train may lose a function, need to be withdrawn and require engineering checks before it returns to service.
This is what makes railway OT different. Digital systems are part of the engineered asset, so decisions about how they are secured, changed and recovered can have operational consequences.
IT handles information. OT affects physical equipment
Information technology processes, stores and communicates business information.
IT services usually operate in managed environments where devices, networks and software can be controlled centrally. When they fail, the priority is normally to restore access, protect information and limit disruption.
Operational technology monitors or controls physical equipment and processes.
On rolling stock, OT ranges from systems that control braking and doors to train management to passenger information, CCTV and condition monitoring.
Not every OT system is safety critical, but each can affect how the train operates. The level of control should therefore reflect the consequences of failure, misuse or incorrect configuration.
IT and railway OT compared
| Aspect | IT | Railway OT |
| Focus | Business data and processes | Physical railway equipment and processes |
| Environment | Offices and data centres | Rolling stock, depots, control rooms and trackside |
| Typical priority | Confidentiality, data integrity and availability | Safety, availability, integrity, and confidentiality |
| Common communications | Ethernet, TCP/IP and standard enterprise protocols | Ethernet and TCP/IP alongside railway and industrial technologies such as MVB and CAN bus |
| Change | Regular updates, patches and shorter refresh cycles | Controlled testing, long lifecycle, minimum downtime |
| Governance | Usually led by IT and information security | Requires engineering, operations, safety and cyber security |
These are differences in priority, not absolute rules. The controls applied should reflect the risks and consequences in each environment.
Why rolling stock changes the rules
A train is a moving asset. It may remain in service for several decades, with equipment added or changed through time.
Its systems must work in demanding physical conditions, with variable connectivity and technology from different suppliers and generations. This means many standard IT assumptions do not apply without adaptation.
The physical environment is harder to control
Onboard equipment may be exposed to heat, vibration, shock, dust, moisture, restricted space and limited ventilation. Equipment may also be accessible to passengers, staff or maintainers.
Any control must work within the space, power and ventilation available on the vehicle. It must be compatible with existing equipment and meet relevant vehicle safety and fire requirements.
It must also be tested to confirm that it does not affect train functions, reduce reliability or undermine existing assurance.
Connectivity cannot be assumed
Train to shore communications often depend on mobile networks. Coverage can be affected by tunnels, cuttings, remote routes, network demand and handover between cells.
Essential onboard functions must continue or fail safely as designed when an off-train connection is slow, unstable or unavailable.
Other services may need to run in a reduced mode, store data securely onboard and transfer it when a reliable connection becomes available.
Controls designed around permanent connectivity may not work reliably on a train.
Different systems must work together
A train may use Ethernet alongside railway and industrial communication technologies such as Multifunction Vehicle Bus (MVB) and CAN bus.
Gateways allow these systems to communicate, but they also connect equipment with different functions, protocols and security capabilities.
This is not only a legacy fleet issue. New trains also bring together subsystems from several suppliers, while existing fleets may combine original equipment with later upgrades.
The result is a set of interdependent systems. A weakness or change in one area can affect interfaces and functions elsewhere on the train.
Why normal IT recovery and change processes are not enough
In IT, restoring a failed service quickly is usually the right aim. In OT, speed is only one part of recovery.
Before a railway system returns to service, the operator may need to confirm that:
- Its configuration and operating state are correct
- Its interfaces and communications are working
- Required testing and authorisation are complete
Restarting a system does not prove that it is ready for service. Recovery means returning it to a known and verified state, not simply restoring power or clearing a fault.
When patches, firmware updates or configuration changes could affect vehicle behaviour, system interfaces or existing assurance, they must be managed as engineering changes.
RSSB’s RIS-2700-RST includes software assurance and cyber security within the verification of engineering changes to rail vehicles.
Cyber security has operational consequences
Cyber security protects confidentiality, integrity and availability, but the immediate priorities can differ between IT and OT.
Information security often gives particular weight to confidentiality.
In railway OT, availability and integrity may have the more immediate operational effect, with safety as the overriding priority throughout. An unavailable system can remove a train function, while altered data or configuration can cause equipment to behave incorrectly.
Confidentiality still matters, but OT cyber security must also support reliability, maintainability and safety. An attack, accidental change or poor configuration can all leave equipment unavailable, unreliable or unsafe.
What good OT management looks like
Good OT management starts before equipment enters service and continues throughout its life.
Set the requirements before buying the system
Procurement should define:
- How remote and supplier access will be controlled
- How software, components and obsolescence will be supported
- Who owns configuration, vulnerabilities and updates
- What records, evidence, tools and unresolved risks will pass to the operator
The Department for Transport’s rolling stock procurement guidance places cyber security across the full asset lifecycle, from specification and design to operation, maintenance, upgrade and replacement.
Weak requirements at procurement become long-term problems for fleet teams.
Knowing the digital state of the fleet
Operators need a clear, up-to-date view of the onboard architecture, including what technology is fitted, how systems connect and where external or supplier access exists.
That view should be supported by an accurate asset record covering software versions, configurations, interfaces, dependencies and remote access routes.
Without this, it is difficult to control the system or confirm that it remains in the correct state.
NCSC guidance treats a definitive view of the OT architecture as a foundation for effective asset and configuration management.
Control access and connections
Every connection to OT should have a clear purpose.
Controls may include separating networks, restricting services, protecting system boundaries, securing remote access, recording activity and having a tested way to isolate connections during an incident.
The aim is not to prevent useful connectivity. It is to stop one compromised device or account from giving wider access to the train.
Manage vulnerabilities around railway risk
Vulnerability management starts with knowing which vulnerabilities affect the fleet, the risk they present and what updates or support are available from suppliers.
But an available update cannot always be applied immediately. On rolling stock, changes to software or firmware may affect connected systems, vehicle behaviour or existing assurance, so updates may need testing, approval and controlled implementation.
Where an update cannot be applied straight away, the vulnerability still needs to be managed. Other measures, such as restricting access, separating networks or increasing monitoring, may be needed until the issue can be resolved or the equipment replaced.
This risk-based approach is reflected in TS 50701, which applies IEC 62443 principles to rail, including risk assessment, security zones and controlled connections between systems.
Why railway OT needs specialist expertise
Railway OT brings together digital technology, rolling stock engineering, operations, safety, maintenance and whole life support.
The specialist challenge is understanding how a decision in one area affects the others. A cyber security control may reduce one risk but alter train performance, maintenance, system interfaces or existing assurance. It must therefore be assessed in the context of the whole train and, where relevant, managed through engineering change control.
IT and cyber teams provide essential expertise in networks, identity, cloud services, monitoring and information security. Railway OT adds another layer: understanding the asset, how it operates and the consequences if something fails or changes.
That is what makes railway OT distinct. It is not simply IT used on a train. It is digital technology embedded within an engineered railway asset, where failure, change and recovery can affect service, reliability and safety.
Managing it well depends on engineering, operations, safety, maintenance, cyber security and IT working together throughout the life of the train.
Railmind works across rolling stock, operational technology and cyber security. We help organisations understand how digital systems affect the railway asset, its operation and its whole-life support.
We publish insights like this to strengthen industry understanding of railway OT and support better-informed engineering, operational and cyber security decisions.