Every time a new PLC or HMI vulnerability lands in CISA’s Known Exploited Vulnerabilities catalog, the same scramble happens on plant floors. Someone pulls a spreadsheet. Someone else walks the line with a clipboard checking firmware revisions. Controls engineers get pulled off real work to answer a question that should take minutes: are we running the affected version, and where? Software Bills of Materials are supposed to fix exactly this problem. CISA has spent the last few years pushing SBOM requirements from IT software into the OT vendor world, and 2026 is shaping up as the year that pressure actually shows up in your PLC and HMI vendor contracts rather than just in federal guidance documents. That’s worth taking seriously — but it’s also worth being clear-eyed about what an SBOM feed can and can’t do for you on the day a new CVE drops.
What’s actually changing
The mandatory SBOM ingestion push traces back to the software supply chain executive order and NTIA’s minimum-elements work, but it’s been an IT-software story mostly — think enterprise applications, not ladder logic. What’s shifting now is that federal procurement language and CISA’s own guidance are increasingly treating OT and ICS suppliers the same way they treat any other software vendor selling into government-adjacent environments. Critical infrastructure operators are starting to write SBOM delivery into vendor contracts as a condition of sale, not a nice-to-have. Some PLC, HMI, and industrial networking vendors are responding by publishing SBOMs in machine-readable formats like SPDX or CycloneDX alongside firmware releases, the same way software vendors have been doing for their applications.
This matters because OT firmware has historically been a black box. A PLC’s firmware image might contain a real-time OS, a TCP/IP stack, a web server for the HMI, some open-source crypto libraries, and vendor-proprietary code, and none of that was ever itemized anywhere you could see it. When a vulnerability in a widely used embedded TCP/IP stack or TLS library gets disclosed, you had no reliable way to know which of your field devices actually contained the affected component without vendor advisories catching up — sometimes weeks after the initial CVE.
What an SBOM actually buys you today
Where a real SBOM feed genuinely earns its keep is at the component-identification step. If a vendor publishes an SBOM for firmware version X.Y of a given controller, and a new CVE names a specific open-source library and version range, you can query that against the SBOM and get a fast, defensible answer: this firmware version does or doesn’t contain the vulnerable component. That’s a meaningful improvement over waiting on a vendor security advisory, and it’s especially valuable for the embedded open-source components — the OpenSSL variants, the lightweight web servers, the RTOS kernels — that show up across dozens of unrelated products and rarely get individually tracked otherwise.
It also changes who can do the first pass of triage. Right now, that first “are we affected” question usually has to go through someone with deep product knowledge, often the vendor’s own security team. With a structured SBOM and a CVE feed, a plant IT or OT security analyst can run that match themselves, at least for the component-level question.
What it doesn’t buy you
Here’s the part that gets glossed over in the vendor pitch decks: an SBOM tells you what’s in a piece of firmware. It does not tell you what firmware version is running on which asset on your floor, in which cell, feeding which line. That mapping — asset to firmware version to physical location to criticality — is still entirely on you, and it’s still mostly manual in most plants.
SBOMs also don’t resolve reachability. A vulnerable library being present in firmware doesn’t mean the vulnerable function is exposed or exploitable in your specific configuration — whether that web server module is even enabled, whether that port is open, whether you’re running the device in a mode that touches the affected code path at all. Vendors are inconsistent about publishing VEX (Vulnerability Exploitability eXchange) statements alongside SBOMs, and VEX is the piece that actually tells you “yes this component is present, but no, it’s not exploitable in this product configuration.” Without VEX, an SBOM match just generates a longer worry list, not a prioritized one.
And plenty of OT vendors, especially smaller ones and legacy product lines still in service, aren’t publishing SBOMs in any machine-readable format yet, mandate or no mandate. You’re going to be running a hybrid intake process — some assets covered by clean automated feeds, most still requiring the old manual advisory-reading grind — for a long stretch of time yet.
Building the intake process before you need it
The mistake plants make is treating SBOM ingestion as a future problem to solve once vendors get around to publishing them. Build the pipe now, even with partial data, so you’re not designing a process during a KEV deadline crunch with a 24-hour clock running.
- Inventory firmware versions, not just device models. Your asset register needs to track exact firmware and revision per device, kept current, or every downstream step is guesswork.
- Pick a format and stick to it. SPDX and CycloneDX are the two real options. Decide which your tooling will ingest and push vendors toward it in contract language rather than accepting whatever they hand you.
- Ask vendors for VEX, explicitly, not just SBOMs. An SBOM without exploitability context creates alert fatigue. Make VEX delivery part of the same ask.
- Assign ownership before the first real test. Decide now who receives new SBOMs, who runs the component match against new CVEs, and who has authority to schedule a patch window on an operational asset. That decision under deadline pressure is where things go sideways.
- Treat this as a supplement to, not a replacement for, your existing vulnerability management cadence. Network segmentation, compensating controls, and change-managed patch windows don’t go away because you have better data. Better data just makes your existing process faster and more defensible.
The honest read
SBOM ingestion from PLC and HMI vendors is a real, worthwhile improvement to the front end of vulnerability triage, and the direction CISA and federal procurement policy is pushing vendors is the right one. But it’s solving the component-identification problem, not the asset-mapping problem, and definitely not the exploitability problem. Plants that treat an incoming SBOM feed as the whole answer are going to be disappointed the first time a CVE drops and they still can’t say, in under an hour, which line goes down for the patch window. Plants that treat it as one better input into a process they already own — asset inventory, criticality ranking, change management, a named person with authority to act — are going to get real value out of it starting now, not whenever every vendor finally complies.
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.
