What should defenders inspect first in railway signalling?

Inspect four things first in railway signalling: what equipment and software you actually have, every path that reaches it from outside, how vendors and maintainers connect, and how a security patch gets approved and installed. Standards for rail and for operational technology agree that you cannot protect what you have not listed.

This is a planning checklist built from published standards. It describes no specific incident and no specific system.

Which standards apply?

CLC/TS 50701 is the CENELEC technical specification for railway cybersecurity. Its scope covers the communications, signalling and processing domain, rolling stock and fixed installations. It does not set one fixed rule set. It provides reference models and concepts from which operators derive requirements, covering risk assessment, security design, assurance and acceptance, and vulnerability and patch management. CENELEC states it draws on IEC 62443-3-3 and takes account of safety aspects in EN 50126.

NIST SP 800-82 Revision 3, the Guide to Operational Technology Security, was published on 28 September 2023. It treats transportation systems as one kind of OT, describes typical topologies, threats and vulnerabilities, and recommends safeguards. It also adds an overlay of SP 800-53 controls for low, moderate and high impact systems.

Neither document is a rail signalling manual for your exact setup, so use them as frames, and your safety case as the authority on what you may change.

What is the first thing to inspect?

The asset and software inventory. List interlockings, controllers, field equipment, communications links, engineering workstations and the software and firmware on each, with versions and suppliers. Include the open source libraries inside supplier software, which you may need to request as a software bill of materials. Without this list, a vulnerability notice cannot be answered with "yes, we run that".

What is second?

Every path in from outside. Draw the connections between corporate IT, operational networks and signalling equipment. Look for remote access, shared accounts, modems, remote support tools and any link added for convenience years ago. NIST SP 800-82 treats architecture and segmentation as central for exactly this reason.

What about vendors and maintainers?

Maintenance laptops and supplier access. Engineers plug into safety related equipment. Check who owns those laptops, what software is on them, how they are updated, whether access is time limited and logged, and what happens to credentials when a contract ends.

How does patching work here?

Differently from office IT. A change to safety related equipment may need assessment, testing and approval before it goes live, so a patch can take months by design. CLC/TS 50701 names vulnerability and security patch management as a topic for this reason. Inspect the process, not just the speed:

• Who receives supplier vulnerability notices?
• Who decides whether a flaw is relevant to your configuration?
• What do you do while a patch waits, such as segmenting, restricting access or monitoring?
• Is that decision recorded?

What about monitoring and recovery?

Check what is logged at the boundaries, who looks at it and how an alert reaches someone who can act. Then check whether you can fall back to a known good configuration and whether anyone has practised it. Keep it calm and rehearsed. Fearful guesses do not help an operations room.

Where can software tooling help?

For software you build or integrate, a dependency inventory and vulnerability scan is a starting point. Safeguard's CLI generates SBOMs and scans many package managers locally. It does not replace the signalling safety process, and it does not assess embedded firmware you cannot run it against.

What to do

1. Build the asset and software list, including supplier versions.
2. Request SBOMs or component lists from suppliers.
3. Map every connection between IT, OT and signalling equipment.
4. Review remote access and shared accounts, and remove what has no owner.
5. Audit maintenance laptops and supplier credentials.
6. Write down the patch decision process and the interim protections.
7. Check boundary logging and rehearse a fall back.

Quick check

Sources

• CENELEC: A major step for railways cybersecurity, the new CLC/TS 50701
• NIST: Guide to Operational Technology Security, SP 800-82 Revision 3

Last reviewed: 18 October 2026.