In February 2024, CISA, the NSA, and international partners issued a joint advisory revealing that Volt Typhoon actors had been embedded inside US critical infrastructure operational technology networks, in some cases for more than five years without detection. That disclosure crystallized a question most operators had been avoiding: what software actually runs on the programmable logic controllers, human-machine interfaces, and historian servers keeping water utilities, power grids, and manufacturing lines online? ICS SCADA SBOM requirements exist precisely to answer that question — a structured, machine-readable inventory of every component, library, and firmware module inside industrial control software. Unlike cloud-native IT stacks, most OT environments were engineered assuming physical isolation, not supply chain scrutiny. As mandates from CISA, TSA, and IEC 62443 converge on software transparency, asset owners running SCADA and ICS deployments are discovering they can't produce — or even request — a basic component inventory for systems that have run untouched for a decade.
What Do ICS SCADA SBOM Requirements Actually Cover?
ICS SCADA SBOM requirements cover a structured list of every software component — open source library, proprietary module, firmware binary, and third-party dependency — bundled into a control system product, delivered in a machine-readable format like SPDX or CycloneDX. For SCADA and ICS specifically, that scope extends further than a typical enterprise application: it includes the real-time operating system running on the PLC, the ladder-logic runtime, the HMI middleware, and often bundled communication stacks like Modbus, DNP3, or OPC UA libraries. Executive Order 14028, signed in May 2021, first pushed federal buyers toward requiring SBOMs from software vendors, and CISA's July 2021 "minimum elements" guidance defined the baseline fields — supplier name, component name, version, and dependency relationships — that any compliant SBOM must include. IEC 62443-4-1, the process requirements standard for secure product development in industrial automation, formalized this further with practice SM-9, which explicitly requires vendors to maintain and provide a bill of materials for components used in their products. The gap most asset owners hit immediately: a SCADA product shipped in 2014 was built years before any of these standards existed, so an accurate SBOM often has to be reconstructed after the fact through binary analysis rather than pulled from a build pipeline.
Why Do OT Environments Need a Software Bill of Materials If They've Run Fine for Years?
OT environments need a software bill of materials because "running fine" and "running safely" are unrelated facts once a vulnerability surfaces in a component nobody knew was there. The average industrial control system stays in service for 15 to 20 years, compared to a 3-to-5-year refresh cycle for typical IT infrastructure, which means patch windows are measured in maintenance outages scheduled a year out, not sprints. Log4Shell, disclosed in December 2021, is the clearest case study: Schneider Electric, Siemens, and Rockwell Automation each published advisories over the following twelve months identifying HMI, engineering workstation, and historian products that bundled a vulnerable Log4j version — some confirmations arriving more than six months after the initial CVE because vendors had to manually audit legacy builds rather than query an existing SBOM. Without a software bill of materials in hand beforehand, every subsequent disclosure — Log4Shell, the 2023 curl vulnerabilities, the XZ Utils backdoor in March 2024 — forces the same reactive scramble: emailing vendors, waiting on advisories, and hoping the affected component isn't buried three dependencies deep in a firmware blob.
Which Regulations Actually Mandate an Industrial Control System Software Bill of Materials?
Several overlapping regulations now mandate an industrial control system software bill of materials, though none yet apply universally across every OT sector. In the United States, TSA Security Directive Pipeline-2021-02, issued after the May 2021 Colonial Pipeline ransomware attack, requires pipeline operators to build cybersecurity implementation plans that increasingly reference software provenance and vulnerability management, while federal executive branch software procurement under EO 14028 and NIST SP 800-161 requires SBOMs as a contractual condition of sale. In the EU, NIS2 came into force with a transposition deadline of October 17, 2024, extending supply chain security obligations to operators of essential services including energy, water, and manufacturing, and the Cyber Resilience Act — adopted in 2024 with staggered enforcement through 2027 — will require SBOMs for any product with digital elements sold into the EU market, industrial control equipment included. None of these frameworks currently force a water utility running 20-year-old SCADA hardware to retroactively demand SBOMs from a vendor that may no longer exist, which is the compliance gap most asset owners are quietly navigating today.
What Makes SCADA Vendor Security Different From a Typical IT SBOM Program?
SCADA vendor security differs from a typical IT SBOM program because the artifacts being inventoried are frequently firmware images and proprietary real-time operating systems rather than containerized applications with clean dependency manifests. A standard IT SBOM pipeline built around a package manager like npm or pip has little to parse in a compiled ladder-logic runtime or a vendor's custom RTOS binary — generating an accurate SBOM for that class of product usually requires binary composition analysis, firmware unpacking, and cross-referencing known component signatures rather than reading a manifest file. It also means vendor accountability looks different: Rockwell Automation, Siemens, Schneider Electric, GE Vernova, and Honeywell each maintain their own product security advisory programs and disclosure timelines, and asset owners often have no contractual leverage to demand an SBOM for equipment purchased a decade ago through a systems integrator rather than directly from the manufacturer. Strong SCADA vendor security programs now publish SBOMs alongside major firmware releases and issue VEX (Vulnerability Exploitability eXchange) statements clarifying which disclosed CVEs actually apply to a given product build — a practice Siemens and Schneider Electric have both expanded since 2022 specifically to cut down false-positive vulnerability alerts hitting their customers' OT security teams.
How Should Asset Owners Verify the OT Software Supply Chain Instead of Trusting Vendor Claims?
Asset owners should verify the OT software supply chain through contractual SBOM delivery requirements, independent binary verification, and continuous monitoring rather than accepting a vendor's word at time of purchase. That starts with procurement language: requiring SBOM delivery in SPDX or CycloneDX format as a condition of any new ICS or SCADA contract, with update obligations tied to firmware releases, not just the initial sale. For the installed base already in the field — often the larger and riskier population — independent firmware and binary analysis can reconstruct a component inventory even when the original vendor never generated one, surfacing embedded OpenSSL versions, bundled web servers, or outdated Linux kernels that predate any formal SBOM practice. Continuous monitoring matters just as much as the initial inventory: a 2023 Dragos assessment found that a significant share of ICS asset owners still lack real-time visibility into which of their deployed devices are affected when a new CVE drops, meaning the SBOM becomes a static document nobody revisits until the next incident. Mapping every reconstructed SBOM against live vulnerability feeds — and against the OT-specific advisories CISA publishes through its ICS-CERT program on a near-weekly cadence — turns a one-time compliance exercise into an operational security control.
How Safeguard Helps
Safeguard was built for exactly this gap between what ICS SCADA SBOM requirements ask for and what OT environments actually have on hand. Rather than assuming a clean SPDX file already exists, Safeguard generates accurate software bills of materials directly from binaries and firmware images, so legacy PLCs, HMIs, and SCADA servers that predate any vendor SBOM program can still be inventoried without waiting on a manufacturer that may be slow to respond — or no longer in business. Those SBOMs are continuously matched against live vulnerability intelligence, so when the next Log4Shell-scale disclosure hits, security teams get an immediate, asset-level answer instead of a weeks-long email chain with vendors. For teams managing vendor risk across a fleet of SCADA products, Safeguard also tracks component-level provenance over time, flagging when a firmware update quietly introduces a new dependency or removes a previously verified one — giving OT security and compliance teams the audit trail that IEC 62443-4-1, NIS2, and emerging Cyber Resilience Act obligations increasingly expect, without requiring every plant to become its own reverse-engineering shop.