Railway signalling systems are built to fail safe, but a compromised or vulnerable component can undermine that design. CLC/TS 50701 brings cybersecurity into the EN 50126 safety lifecycle so security threats are handled where hazards already are. For suppliers and operators, that means treating every software component as part of the safety case.
What does CLC/TS 50701 do?
Per the Estonian standards body's description, CLC/TS 50701 gives railway operators, system integrators and product suppliers guidance on managing cybersecurity within the EN 50126-1 RAMS lifecycle. It covers the Communications, Signalling and Processing domain, Rolling Stock, and Fixed Installations. It does not address functional safety requirements. Instead it adds requirements for threats and vulnerabilities, so that reliability, availability, maintainability and safety characteristics are not reduced, lost or compromised by intentional attacks.
The listing says the 2021 edition was withdrawn on 1 September 2023 and the 2023 edition is the newest. Its security models, concepts and risk assessment process are based on or derived from IEC 62443 and consistent with IEC 62443-2-1, which in turn draws on ISO 27001 and ISO 27002. Another listing adds that the 2023 edition names MITRE ATT&CK for ICS as an example threat library. Check the CENELEC catalogue for current status.
Why does supply chain matter more in rail?
Rail systems have long lives, specialised suppliers and strict certification. That has two effects.
- Slow change. A software update may need re-assessment before it reaches a trackside or onboard unit, so known flaws can stay in service.
- Deep dependency chains. An interlocking or train control product contains an operating system, communications stacks and libraries from many sources.
When a component flaw is announced, the first question is whether the product uses it and whether the flawed part is reachable. That needs a component list per product and release.
How does safety interact with security?
Safety engineers ask what happens if a part fails. Security engineers ask what happens if a part is made to fail. The two meet where an attacker can trigger a hazardous condition, or defeat the mechanism that detects one. This is why the specification works inside the safety lifecycle instead of beside it.
I found these standards details through the Estonian standards listing. I did not find a public record of a signalling incident for this post and make no such claim.
What to do
- Request a component list for every signalling and train control product, per release, and file it with the safety case.
- Add security to hazard analysis. For each hazard, ask whether a deliberate action could cause it.
- Define zones and conduits for trackside, onboard and control centre systems in the manner of IEC 62443.
- Write patch and assessment timelines into contracts, including how fast a supplier must assess a new advisory.
- Use exploited vulnerability lists to prioritise which supplier answers you chase first.
- Control remote maintenance access with named accounts, approvals and recording.
- Plan for components you cannot update soon: isolate, monitor and limit what they can reach.
- Test restoration of control systems from known good media.
- Keep evidence of each assessment so an assessor or regulator can follow the reasoning.
Safeguard's SCA inventory and reachability analysis help track components in software you develop, which is the starting point for the component lists in step 1.
Quick check
Does CLC/TS 50701 replace functional safety standards?
No. It does not address functional safety requirements. It adds cybersecurity requirements within the EN 50126-1 lifecycle.
Which general security standard is it based on?
Its security models and risk assessment process are based on or derived from the IEC 62443 series, according to the standards listing.
Sources
- Estonian Centre for Standardisation, CLC/TS 50701 listing
- DIN Media, CLC/TS 50701:2023 (found via search)
- ISA, ISA/IEC 62443 series of standards
Last reviewed: 18 October 2026.
