A software bill of materials for plant equipment is a list of the software components inside a controller, instrument or skid, supplied by the maker. It lets the plant ask "do we run the affected component?" when a vulnerability appears. Ask for it in procurement, because retrofitting it later is slow.
The facts below come from public standards and CISA pages. They are a framing for a conversation with your suppliers, not a checklist that any regulator requires.
Why does a chemical plant care about software lists?
Plants run programmable systems that touch the physical process. NIST SP 800-82 Rev. 3 defines operational technology as programmable systems and devices that interact with the physical environment, and covers industrial control systems, building automation and physical access control among others. It gives guidance on securing them while accounting for performance, reliability and safety requirements.
That last phrase is the reason inventories matter. You often cannot patch a controller on the day a fix appears. You need to know whether you are exposed so you can decide between patching, isolating or monitoring. Without a component list, that question takes a phone call to the vendor.
What does the standard framework say about suppliers?
The ISA/IEC 62443 series sets requirements for four groups: asset owners, automation product suppliers, integrators and service suppliers. ISA says it applies across industries, with process industries such as chemicals named. Part 4-1 covers the secure product development lifecycle requirements for suppliers, and Part 4-2 covers technical security requirements for components.
For a buyer, the useful reading is that the series gives you a vocabulary to put in a purchase specification, and that responsibility is split. The supplier documents how the product is built. The owner and integrator document how it is deployed. An SBOM sits in the supplier's half.
What does CISA offer on SBOMs?
CISA publishes a general SBOM baseline, titled on its SBOM page as the 2026 updates to the minimum elements for an SBOM, described as including new data fields, practices and processes. I could not confirm a publication date or the field list from that page, so read the document itself. CISA also has an SBOM Sharing Primer, which describes how SBOMs move between parties, from vendors who send them by email to open source projects that publish them in repositories.
I did not find OT specific SBOM guidance on those pages, and the CISA SBOM page does not mention hardware or OT. If you need firmware specific fields, ask your suppliers what format they provide rather than assuming one.
What should you ask a supplier for?
Reasonable asks, based on the ideas above:
- A component list for each firmware and software release, in a machine readable format such as SPDX or CycloneDX.
- Updated lists when a new release ships.
- A named contact and a stated process for reporting a vulnerability in their product.
- Notice of the support period, so you know when updates stop.
- A statement about whether their development process follows IEC 62443-4-1.
Be ready for mixed answers. Some suppliers will not have this yet. That is information too, and it belongs in the risk register.
What can you do without supplier help?
You can still build a partial picture. Record make, model, firmware version and network location for every programmable device. Then match those identifiers against vendor advisories as they are published. It is slower than a component list, but it gives you a starting inventory.
What to do
- Inventory programmable devices with make, model, firmware version and location.
- Add an SBOM request clause to purchase specifications for new equipment.
- Ask for a machine readable format and a refresh on each release.
- Reference ISA/IEC 62443 parts 4-1 and 4-2 in the supplier questionnaire.
- Ask each supplier for a vulnerability reporting contact and support period.
- Store received SBOMs where your security team can search them.
- Record suppliers who cannot provide one as a known gap.
For the software side of your own estate, you can see what a dependency inventory looks like in the demo below.
See it full screen.
Quick check
Is an SBOM for plant equipment required by a standard?
I did not find a requirement in the sources fetched. IEC 62443 sets supplier lifecycle and component requirements, and CISA publishes general SBOM guidance. Check your regulator and contracts.
Does an SBOM tell me a vulnerability is exploitable in my plant?
No. It tells you what components are present. Exposure depends on configuration and network placement, which you assess separately.
Sources
- NIST SP 800-82 Rev. 3
- ISA/IEC 62443 series
- CISA: Software Bill of Materials
- CISA: SBOM Sharing Primer
Last reviewed: 18 October 2026.
