In railway signalling, finding a vulnerable library does not lead to an immediate patch. The fix goes through the safety lifecycle first. CLC/TS 50701, the railway cybersecurity specification built on IEC 62443 ideas, covers vulnerability and patch management inside that lifecycle. An SBOM helps you find affected equipment fast, so the right people can decide.
This post describes no incident. It draws on standards bodies' descriptions and leaves engineering and safety decisions to the people accountable for them.
What is the railway cybersecurity specification?
CENELEC announced CLC/TS 50701 in 2021, and the 2023 edition is current according to our search, with the 2021 edition withdrawn from September 2023. It gives railway operators, system integrators and suppliers guidance on managing cybersecurity within the EN 50126 RAMS lifecycle, which covers reliability, availability, maintainability and safety. It applies to the communications, signalling and processing domain as well as rolling stock and fixed installations.
Its security models, concepts and risk assessment process are based on or derived from the IEC 62443 series, according to the sources. It does not cover functional safety. Instead it adds requirements around threats and vulnerabilities, so that RAMS characteristics are not lost to a cyberattack. Topics include risk assessment, security design, assurance and system acceptance, vulnerability management and security patch management.
What does a vulnerable dependency mean there?
Suppose a library inside a signalling or trackside component has a published vulnerability. Four questions come before any patch.
- Is the component affected? You need an inventory down to library and version. An SBOM from the supplier is how you know.
- Is the vulnerable code reachable in this product? A library may be present but not used in a way that triggers the flaw. The supplier is best placed to say, and a written statement is the evidence.
- What is the exposure? Where does the device sit, and what can reach it? IEC 62443 style zoning and network separation reduce exposure even when a patch cannot be applied soon.
- What does a change do to the safety case? In a safety lifecycle, a software change may need assessment and re acceptance. NIST SP 800-82 makes a similar point for OT in general: performance, reliability and safety requirements shape how you update.
So the choice is often between a supplier patch with proper acceptance, a mitigation such as tighter separation, or a recorded acceptance of the risk for a defined period.
What an SBOM adds
An SBOM does not decide any of this. It speeds up question one, and the quality of the answer to question two. Without it, an operator waits for suppliers to respond one by one. With it, you can match a new advisory against your whole fleet's components the same day and send supplier questions to the right place.
What suppliers should be asked for
- An SBOM per product release, including firmware and third party libraries.
- A statement process for new vulnerabilities, with expected response times.
- Clarity on how patches are validated against safety requirements.
- How long each release is supported.
IEC 62443 describes patch management in its own part and puts secure development lifecycle requirements on product suppliers, which gives you a hook for these requests.
Where Safeguard fits
Safeguard validates and scans SBOMs in SPDX and CycloneDX form and keeps them matched against vulnerability data, and the CLI scans source directories, repositories and container images used in back office and support tooling. It does not run on trackside equipment or replace safety assessment, and it does not certify any product.
What to do
- List equipment by supplier and ask for current SBOMs.
- Record zone and exposure for each asset class.
- Agree with each supplier how vulnerability notices and patches are validated.
- Match new advisories to the inventory on a schedule.
- Record each decision: patch, mitigate or accept, with an owner and a review date.
- Read CLC/TS 50701 alongside IEC 62443 with your safety engineers.
Quick check
Can a railway operator patch a signalling component immediately?
Usually not. A change typically goes through the safety lifecycle and supplier validation first. Mitigations such as separation may come sooner.
Does CLC/TS 50701 replace IEC 62443?
No. Per the sources we read, it builds on IEC 62443 concepts and adapts them to the railway safety lifecycle.
Sources
- CENELEC: A major step for railways cybersecurity, the new CLC/TS 50701, found by search 18 October 2026
- EVS: CLC/TS 50701 listing, found by search 18 October 2026
- ISA: ISA/IEC 62443 series of standards, fetched 18 October 2026
- NIST SP 800-82 Rev. 3, fetched 18 October 2026
- Safeguard CLI documentation, fetched 18 October 2026
Last reviewed: 18 October 2026.
