Ask your controls integrator for a software bill of materials on the PLC you’re about to buy. Go ahead. In most cases you’ll get a pause, a forwarded email to someone in product security, and eventually either silence or a PDF that lists the firmware version and not much else. That gap — between what CISA and federal procurement policy now expect and what ICS/OT vendors can actually produce — is about to become an expensive problem for plant IT teams, because it’s landing directly in 2026 renewal cycles and capital RFPs.
The pressure is real and it’s not going away. CISA’s secure-by-design pledge pushed vendors toward concrete, measurable commitments rather than marketing language, and SBOM production has become one of the clearest yardsticks for whether a vendor is following through. Updated NIST guidance on software supply chain transparency has reinforced the expectation that SBOMs aren’t just a nice-to-have artifact but a standard deliverable, in formats like SPDX or CycloneDX, attached to a product release. Sector-specific agencies covering water, energy, and manufacturing are increasingly referencing SBOM attestation in their procurement language. None of this is theoretical anymore. It’s showing up as a line item in vendor questionnaires and RFP boilerplate that plant engineering teams are being asked to fill out or evaluate, often without much guidance on what “good” looks like.
Why an IT SBOM and an OT SBOM aren’t the same document
Most of the SBOM tooling and policy language in circulation was built for enterprise software — web apps, cloud services, general-purpose servers where the component tree is open-source libraries, container images, and application dependencies. That model translates poorly to a PLC, an HMI, or a managed switch sitting at Purdue Level 1 or 2.
An OT-relevant SBOM has to account for firmware, not just software. That means the real-time operating system or RTOS variant baked into the device, the bootloader, any embedded open-source components (a lot of ICS firmware quietly carries OpenSSL, BusyBox, lwIP, or similar libraries with their own vulnerability histories), the vendor’s proprietary control logic runtime, and any third-party protocol stacks handling Modbus, EtherNet/IP, or PROFINET. It also needs versioning granular enough to map to a specific firmware release, not just a product family, because a vulnerability disclosed against one firmware branch may not apply to another running on the same hardware.
A vendor handing you a spreadsheet of “software components” without firmware-level detail hasn’t given you an OT SBOM. They’ve given you something that looks like one and won’t help you during the next advisory.
The actual payoff: cutting patch-triage time
This is where a working SBOM stops being a compliance artifact and starts earning its keep. When CISA publishes an ICS advisory — and the volume of these has been substantial for years now, covering everything from HMI software to safety instrumented systems — the first question every plant security or controls team asks is: are we affected, and where?
Without an SBOM, that question gets answered by manually checking vendor part numbers and firmware versions against the advisory, device by device, often by someone walking the floor with a laptop or querying an asset inventory of uncertain accuracy. With a real SBOM tied to your asset register, you can match the affected component — say, a specific version of a TCP/IP stack named in the advisory — against your fleet in minutes instead of days. That’s the entire value proposition. It’s not about generating a document for an auditor. It’s about collapsing the time between “CISA published something” and “we know our exposure,” which is exactly the window attackers and opportunistic scanning tools exploit.
Getting there requires your asset inventory and your SBOM data to actually talk to each other, which most plants haven’t built yet. A pile of vendor-supplied SBOM files sitting in a shared drive, disconnected from your CMMS or OT asset database, is barely better than nothing.
What to put in your next RFP
If you’re heading into a capital purchase cycle or a vendor renewal, here’s a checklist worth attaching to the RFP itself rather than negotiating after the fact:
- Require SBOM delivery in a standard machine-readable format (SPDX or CycloneDX), not a narrative PDF.
- Require firmware-level granularity — components tied to a specific firmware version, updated with each release, not a one-time snapshot.
- Ask for the vendor’s process for updating the SBOM when they patch or when a third-party component they embed gets a CVE.
- Ask how the vendor maps their own products to CISA ICS advisories — do they publish a VEX (Vulnerability Exploitability eXchange) statement alongside the SBOM saying whether a given CVE is actually exploitable in their product context, or do they leave you to guess?
- Ask for a named point of contact or portal for product security disclosures, not a generic sales inbox.
- Ask what happens at end-of-support: will SBOM updates stop when the product is sunset, and how will you be notified?
That last question matters more than it looks. A lot of vendors will produce a clean SBOM for a current product line and go quiet the moment a device rolls off active support — which brings us to the part of this exercise that nobody wants to say out loud.
Where this falls apart: the Level 1-2 legacy fleet
Here’s the honest problem. Walk any brownfield plant and you’ll find PLCs, drives, and HMIs that are ten, fifteen, twenty years old, still doing real work, with vendors that have long since stopped supporting the product line or, in some cases, no longer exist in their original corporate form. There is no SBOM coming for that hardware. There’s no vendor security contact to ask. The firmware was never designed with component transparency in mind, and reverse-engineering a bill of materials for it isn’t a realistic ask for most plant teams or even most vendors.
This is where SBOM policy, written with modern software supply chains in mind, runs face-first into the reality of industrial asset lifecycles that routinely outlast the companies that built them. The honest answer isn’t to pretend you’ll get an SBOM for that gear. It’s to treat SBOM coverage as a fleet-segmentation exercise: new and actively-supported assets get real SBOM data folded into your vulnerability management process; legacy Level 1-2 devices without vendor support get compensating controls instead — network segmentation, strict east-west traffic restrictions, monitoring for anomalous protocol behavior, and a documented risk acceptance rather than a false promise of visibility you can’t deliver.
Asset owners who insist on SBOM-or-nothing for their entire legacy fleet will burn time chasing something unattainable while the actual risk — a flat, unsegmented network where one compromised HMI can talk to everything — goes unaddressed. SBOMs are a tool for the assets that can support them and a forcing function for procurement going forward. They are not a retrofit strategy for a control system installed before the standard existed.
The practical move for 2026 is to split your capital and vendor-management strategy accordingly: bake SBOM and VEX requirements hard into every new purchase and every renewal where the vendor is still actively developing the product, and stop pretending the same requirement is achievable for the fleet that’s been quietly running your process since before “software supply chain” was a phrase anyone used.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
