To build SBOMs for plant machines and firmware, start with an asset list of every programmable device and maintenance tool, ask each supplier for a component list in SPDX or CycloneDX, and record what you cannot get. Then connect the list to a change and patch process owned by engineering, not only by IT.
This post is general guidance. It describes no specific plant, incident or regulator requirement. Nuclear operators work under national regulators and site licenses, so confirm obligations with your own compliance team.
Why does maintenance create an SBOM problem?
Maintenance brings software into places that otherwise change slowly. Technicians connect laptops, calibration tools and test benches to controllers. Vendors send firmware updates with release notes that rarely list every library inside. Over a long plant life, the same device model may exist in four firmware versions across units.
CISA lists nuclear reactors, materials and waste among the sectors that rely on industrial control systems and operational technology, the systems and devices that interact with the physical environment. NIST's guide to OT security, SP 800-82 Revision 3, covers how to secure such systems while addressing their performance, reliability and safety requirements. The key phrase for plant work is that last one: security measures must not undermine safety functions.
What should the first inventory contain?
Keep it humble. For each device or tool record: make and model, serial or tag, location, firmware version, purpose, network connections, who maintains it and the supplier contact. Add the maintenance laptops and portable media, since they are the path by which software arrives.
An SBOM then adds one layer below that: the software components inside the firmware or application. CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. For a device, ask the supplier for the list that matches the exact firmware build you run.
What do suppliers need to provide?
The ISA/IEC 62443 series separates responsibilities. Part 4-1 sets secure product development lifecycle requirements for suppliers, and Part 4-2 covers technical security requirements for components. Part 2-4 covers security program requirements for service providers, and Part 2-3 is a technical report on patch management in the industrial automation environment. We read these titles on ISA's page and did not read the standards themselves, so check the text before quoting requirements in a contract.
Practical contract language to ask for: a component list for each firmware release, notification when a component in that list gets a known vulnerability, a statement on exploitability for your configuration, and a support period.
What if the supplier cannot or will not?
Say so in the record. Some legacy devices will have no component list. In that case your options are narrower: network isolation, strict change control, and watching advisories for the vendor and product line. Write the gap down and give it an owner. An honest gap is manageable. A blank is not.
For firmware you can sometimes extract a partial inventory with analysis tools, but treat the result as a hint to confirm with the vendor, and never run unvetted tools on live safety equipment.
How does this connect to patching?
A list without a process is a spreadsheet. Define who reviews a new advisory, who judges safety impact, how a change is tested on a non-production unit and when it may be applied. NIST's OT guidance exists because a patch that is routine on an office laptop can be unacceptable on a controller. The SBOM tells you whether you are affected. Engineering decides what to do about it.
What to do
- Build the asset list for one unit first, including maintenance laptops and portable media.
- Record firmware and application versions exactly as shown on the device.
- Request a component list per firmware build from each supplier, in SPDX or CycloneDX.
- Mark each device as supplier provided, partially known or unknown.
- For unknown devices, add compensating controls and name an owner.
- Subscribe to supplier and CISA advisories and match them against the list weekly.
- Define a safety reviewed change process before any update is applied.
- Re-inventory after every outage or maintenance campaign.
Quick check
Is an SBOM enough to secure a plant?
No. It tells you what is inside your devices. You still need segmentation, change control, monitoring and a safety reviewed patch process.
Which standards are relevant?
NIST SP 800-82 Rev. 3 for OT security guidance and the ISA/IEC 62443 series for supplier and operator responsibilities. Read the texts themselves before quoting them.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, fetched 18 October 2026
- ISA/IEC 62443 series of standards, ISA, fetched 18 October 2026
- Industrial Control Systems, CISA, fetched 18 October 2026
- Software Bill of Materials (SBOM), CISA, fetched 18 October 2026
Last reviewed: 18 October 2026.
