Ask most controls engineers to produce a software bill of materials for the PLC running a critical line, and you’ll get a pause, a shrug, or a promise to “check with the vendor.” Ask for the same thing on the HMI, the managed switch, or the VFD firmware, and the pause gets longer. This isn’t a knowledge gap in the workforce. It’s a structural gap in how OT environments have been built and maintained for the last three decades. Now regulatory pressure is arriving faster than that gap can close on its own.
CISA’s direction is not subtle. Between the Secure by Design attestation push aimed at software and device manufacturers, the CIRCIA reporting rulemaking working through sector-specific requirements, and repeated public guidance tying incident response maturity to asset visibility, the agency is signaling that “we know roughly what’s on the network” is no longer an acceptable answer. The expectation is shifting toward machine-readable, component-level inventories — what’s running, what version, what libraries are baked into the firmware, and whether any of it maps to a known vulnerability the moment one is disclosed.
Most plants are nowhere close. And the honest reason isn’t laziness — it’s that OT hardware was never designed to tell you what’s inside it.
Why PLCs and HMIs Break the SBOM Model
SBOM tooling and the standards behind it (CycloneDX, SPDX) grew up in the software world, where a build pipeline can enumerate dependencies automatically. A PLC is a different animal. Its firmware is a monolithic blob assembled by the vendor, often built on top of a real-time OS and third-party libraries the vendor itself may not fully track across firmware revisions. Field devices frequently run for a decade or more without a firmware update, sitting on hardware families where the vendor’s own build records may have changed hands, changed teams, or simply not been retained at that level of granularity.
That’s the honest baseline going into these mandates: not “plants are behind schedule,” but “the artifact being demanded often doesn’t exist yet in a form the vendor can hand over.” That distinction matters, because it changes what a responsible OT security program should actually do this year — and it isn’t wait for perfect vendor compliance.
A Maturity Model That Doesn’t Assume You’re Starting From Zero
Trying to boil the ocean — full SBOMs for every asset on day one — is how these programs die. A staged model gets you defensible progress and gives auditors and incident responders something real to work with at each stage.
Level 0: Asset List Exists, Isn’t Trustworthy
A spreadsheet or a CMMS record with make, model, and maybe a firmware version last updated whenever someone remembered to walk the floor. No linkage to vulnerability data, no confidence the list matches reality. This describes a large share of OT environments today, and it’s not an insult — it’s where nearly everyone starts.
Level 1: Verified, Machine-Readable Asset Inventory
This is the actual foundation, and it’s more attainable than a full SBOM program. Passive network monitoring tools built for OT (using protocol-aware deep packet inspection on Modbus, EtherNet/IP, PROFINET, and similar) can identify device make, model, firmware version, and communication patterns without touching the control loop. The output needs to live in a structured format — a database or asset management platform, not a document — so it can be queried programmatically when CISA or a sector regulator asks “do you run anything affected by this CVE.” An inventory nobody can query fast is functionally the same as no inventory.
Level 2: SBOM Coverage Where Vendors Can Provide It
Newer HMI software, PC-based control platforms, and IT-adjacent OT components (historians, engineering workstations, some newer PLC families) increasingly do have CycloneDX or SPDX documents available, or vendors participating in Secure by Design attestation programs. Level 2 means you’ve inventoried which of your assets fall into this category and you’re actually pulling and storing those documents, not just noting that they theoretically exist somewhere on a vendor portal.
Level 3: Compensating Documentation for Legacy Devices
For the PLC that’s been running since before the vendor had an SBOM program — and there will be a lot of these — you build a compensating record instead of chasing a document that doesn’t exist. That means: firmware version and build date, known component families (OS kernel, common protocol stacks) as best documented by the vendor’s security advisories, and a record of every CVE the vendor has publicly acknowledged against that firmware line. It’s not a true SBOM, but it’s a defensible artifact that shows due diligence and gives incident response a starting point.
Level 4: Inventory Feeds Response, Not Just Compliance
The real test of maturity isn’t whether the inventory exists — it’s whether it does anything. When a vendor discloses a vulnerability in a specific firmware line, can your team query the inventory and get an answer in minutes about which lines, which cells, which specific assets are affected? If that answer requires someone manually searching folders or calling plant supervisors, the program is still a compliance artifact, not an operational capability.
What to Actually Demand From Vendors Now
Procurement leverage matters more than most plants use it. Contract language and RFPs for new OT equipment should specifically require SBOM availability in a standard machine-readable format as a condition of purchase, not a nice-to-have. For existing installed base, plants should be formally requesting SBOMs or component disclosures from incumbent vendors now, even if the answer comes back incomplete — a documented request creates a paper trail that matters for audit and for CIRCIA-style reporting, and it puts pressure on vendors who are weighing where to invest their own Secure by Design efforts.
Where This Actually Bites
The plants that get caught out won’t be the ones with no SBOM program — regulators and CISA guidance generally acknowledge legacy OT is a known hard problem. The ones that get caught out are the plants that can’t demonstrate they tried: no documented vendor requests, no passive monitoring deployed, no structured inventory, nothing beyond a stale spreadsheet last touched during the last capital project. Reasonable, staged progress with real documentation is defensible. Nothing is not.
Start with Level 1. A trustworthy, queryable asset inventory is worth more on the day of an incident than a partial SBOM program that never got past the spreadsheet stage. Build the plumbing first, then let SBOM coverage fill in as vendors catch up — because on legacy iron, they will catch up slower than the regulatory calendar wants them to, and your program needs to survive that gap.
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.
