A software bill of materials for railway signalling equipment is a supplier provided list of the software and firmware components inside a product. It lets an operator ask whether a newly published vulnerability affects its installed base. Rail standards do not need to say "SBOM" for the request to be reasonable.
Rail is a good case because equipment lives for decades and changes are tightly controlled.
Which standards frame rail cybersecurity?
CEN-CENELEC describes CLC/TS 50701 as a technical specification for railway cybersecurity, developed by CLC/TC 9X. It applies to communications, signalling and processing, to rolling stock and to fixed installations. It covers lifecycle, risk assessment, security design, assurance and system acceptance, and vulnerability and security patch management.
Its security models draw on IEC 62443, in particular IEC 62443-3-3 adapted to rail, and take safety aspects of EN 50126 into account. The aim is that the duty holder can identify, monitor and manage residual security risk to an acceptable level.
At product level, IEC 62443-4-1 sets process requirements for secure development of industrial automation products. Its lifecycle runs from security requirements and design through verification, defect and patch management, to end of life. It applies to hardware, software or firmware, and only to the developer and maintainer, not to integrators or users.
We read summaries from the standards bodies and not the standards themselves, which are paid documents. Check the text before you cite a clause.
Where does an SBOM fit?
Nothing we fetched says CLC/TS 50701 or IEC 62443-4-1 mandates an SBOM. CISA's SBOM page, for its part, does not discuss operational technology or hardware. So treat an SBOM as a practical way to support requirements that are stated: vulnerability management, patch management and supplier assurance.
NIST frames supply chain risk across information and operational technology, naming counterfeit components, tampering, and malicious software or hardware insertion. Its SP 800-161r1 is the foundation publication.
Why is firmware harder than web software?
Because the usual loop of scan, patch and deploy is slow. Safety related equipment is usually changed under tight control, so patches are rarely quick. Operators therefore need to know early whether a vulnerability matters, so they can plan, apply compensating controls and talk to the supplier, instead of discovering the question during an incident.
The inventory also has a gap on the other side. A supplier may bundle an operating system, a network stack and open source libraries into one firmware image. Without a list, the operator sees one opaque version number.
What should operators ask suppliers?
- A component list for each product and firmware version, in SPDX or CycloneDX, with versions.
- A commitment to update the list when firmware changes.
- A statement of how the supplier handles vulnerability reports and patches, linked to the secure development process they follow.
- End of support dates for the product and its key components.
- A statement of whether a reported vulnerability is actually exploitable in the product, which is what a VEX document conveys. CISA describes VEX as an attestation that states whether a product is affected by known vulnerabilities.
What to do
- List your signalling and control equipment by product and firmware version.
- Add SBOM delivery to procurement and contract terms for new and renewed equipment.
- Request SBOMs for the highest risk existing equipment first, such as anything reachable from other networks.
- Store them in a system you can query by component name.
- Subscribe to supplier and national advisories, and match them against the stored lists.
- Agree with suppliers who decides, and how fast, when a component is flagged.
- Align the process with your cybersecurity specification and risk assessment under the standards that apply to you.
Safeguard can ingest and analyze SBOMs and has a third party risk module for requesting them from vendors. It does not replace rail safety assessment, and no part of this post is a statement of compliance.
Quick check
Does CLC/TS 50701 require an SBOM?
We found no source saying so. It covers vulnerability and patch management, which an SBOM supports. Read the specification itself for exact wording.
Why ask suppliers for firmware component lists?
So you can tell quickly whether a published vulnerability affects equipment you operate, before you plan patches or compensating controls.
Sources
- CEN-CENELEC: CLC/TS 50701 railway cybersecurity
- IEC 62443-4-1:2018 on the IEC webstore
- CISA Software Bill of Materials
- NIST Cybersecurity Supply Chain Risk Management
Last reviewed: 18 October 2026.
