They add new actors that hold credentials and can act on systems, so the threat model must list them like staff and contractors. Signalling safety rests on a strict separation between what can be changed and what cannot. Keep that boundary, and give any agent a narrow identity and no authority over safety functions.
What does railway cybersecurity standard work say?
CENELEC's technical specification CLC/TS 50701, "Railway applications, Cybersecurity," gives requirements and recommendations to handle cybersecurity in a unified way for the railway sector. It covers the communications, signalling and processing domain, rolling stock and fixed installations, and addresses risk assessment, security design, vulnerability management and security patch management. It considers the safety aspects in EN 50126, and draws on IEC 62443-3-3, adapted for rail.
We do not describe any real signalling incident here. Nothing in our sources requires one.
What actually changes with agents and robots?
Three things, none of them dramatic.
New identities. A maintenance robot, an inspection drone or a software agent that reads logs and files tickets needs an account or a token. Each one is a credential that can leak or be misused.
New inputs. An agent that reads text, such as work orders, manuals and emails, can be steered by that text. OWASP's guidance on prompt injection says the input may be invisible to humans, and that severity rises with how much agency the model has.
New paths. Robots and agents often bridge networks that were kept apart: a depot network, a maintenance laptop, a vendor cloud. A bridge is a zone boundary, and in ISA/IEC 62443 terms zones and conduits are where you place controls.
Which things stay the same?
The safety case. The safety argument for a signalling function does not change because someone adds an assistant to the maintenance workflow. If an agent proposes a configuration change, the change still goes through the existing approval and validation steps for that function. The agent does not get a shortcut.
What to do
- Add agents and robots to your asset and identity register, with an owner for each.
- Give each its own account, limited to read access where possible, with expiry.
- Place them in a defined zone and list the conduits they use. Make any link into signalling networks one way unless a design review says otherwise.
- Require human approval for any action that writes configuration, and keep that approval in the existing change process.
- Treat all text an agent reads as untrusted, and keep it away from tools that can act.
- Log every agent action to a store the agent cannot modify.
- Run a tabletop: what happens if the agent's token leaks, or if its inputs are poisoned?
- Update the threat model after each new use case, not once a year.
Where does software supply chain visibility help?
The agent runs on software too: frameworks, plugins, model runtimes. An inventory of those components, built from SBOMs in SPDX or CycloneDX, tells you what to patch. Safeguard's CLI can scan such files. It does not assess a signalling safety case, which belongs to rail safety engineers.
Quick check
Should an agent ever change signalling configuration?
Not without the same approval and validation as any other change. Start read only.
Is there a rail specific cybersecurity standard?
CLC/TS 50701 is a CENELEC technical specification for railway cybersecurity. Check its current edition before citing it in a contract.
Sources
- CENELEC, A major step for railways cybersecurity: the new CLC/TS 50701
- OWASP, LLM01:2025 Prompt Injection
- ISA/IEC 62443 series of standards
Last reviewed: 18 October 2026.
