Railways run on software that lives for decades: signalling, onboard computers, trackside units, ticketing links. CLC/TS 50701, "Railway applications, Cybersecurity," is the CENELEC technical specification meant to handle cybersecurity "in a unified way for the railway sector." The first edition appeared in 2021. Catalogue listings show a second edition in 2023, so confirm which edition a customer cites.
Safeguard does not run railways or certify against this specification. What follows is a reading of what the specification covers, and where a software inventory and vulnerability workflow supports a supplier answering it.
What's affected
According to CEN-CENELEC's announcement, the specification applies to the communications, signalling and processing domain, to rolling stock and to fixed installations. It was developed by CLC/TC 9X. It takes safety aspects into account by referencing EN 50126, and it draws on IEC 62443-3-3 and CSM-RA, adapted to the railway context.
It is a technical specification, not a law. Operators and infrastructure managers can still write it into tenders, which makes it binding on suppliers by contract.
How to check if you're exposed
CEN-CENELEC lists the topics it covers. Use them as a gap checklist for your product:
- Railway system overview and cybersecurity across the application life cycle
- Risk assessment
- Security design
- Cybersecurity assurance and system acceptance
- Vulnerability management
- Security patch management
For each row, write what evidence you could hand a customer tomorrow. For vulnerability and patch management that is usually a component list per product release, the date each component was last checked against known vulnerabilities, and the rule for how fast a fix reaches fielded units.
What to do now
- Build a component inventory for every release that reaches the field, not only the current one.
- Record which fielded fleets run which release, because patching on rail depends on maintenance windows.
- Scan each release's inventory for known vulnerabilities and mark which are on CISA's Known Exploited list.
- Decide, per vulnerability, whether the vulnerable code can be reached in your product. Reachability analysis helps here, since a fix in rolling stock needs testing and an outage.
- Keep the decision, the date and the reviewer in a log you can show an auditor or customer.
Why it matters
The specification treats vulnerability and patch management as life cycle topics, not one off tasks. A train in service for thirty years will outlive most of its components' support. The supplier who can say which libraries are inside each fielded version, and what was decided about each known flaw, answers tender questions in days rather than weeks.
Try it yourself
Import an SBOM for a product you ship and see which components carry known vulnerabilities, then mark one as not reachable and write down why.
Click through it at your own pace, or open it full screen.
Quick check
Is CLC/TS 50701 a law?
No. It is a CENELEC technical specification. It becomes binding when a contract or tender requires it.
Which two sources does it adapt to railways?
IEC 62443-3-3 and CSM-RA, with safety aspects referenced to EN 50126.
