SBOM for Industrial Control Systems: What CISA's 2026 Minimum Elements Update Means for OT Security

Diagram comparing a fully-documented SBOM checklist for a modern SaaS build pipeline against a partially-documented SBOM for legacy PLC/RTU firmware, with a VEX filter narrowing a long list of flagged CVEs down to an actionable patch priority list.

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every software component — libraries, dependencies, and their versions — that make up a piece of software or firmware. In July 2026, CISA and international partners updated the federal SBOM Minimum Elements baseline, making several inventory fields mandatory for the first time. The catch: that guidance is generic — it applies to all software, with no ICS/OT-specific carve-outs — so it says nothing about what to do when the "software" in question is firmware on a 20-year-old PLC whose vendor no longer exists. This article works through the new mandatory fields one by one against that reality.

By The Whitepaper Skeptic — reviewed legacy PLC and RTU fleets with no software inventory available

Quick Facts

Question Answer
What is an SBOM? A formal inventory of every software component — libraries, dependencies, versions — inside a piece of software or firmware
When did CISA update the SBOM Minimum Elements? July 29, 2026 (CISA's own release date; some trade press covered it a day later, on July 30)
Is the 2026 update ICS/OT-specific? No — it applies the same minimum elements to all software (open-source, AI, SaaS included); it contains no OT/ICS carve-outs or exceptions
What's the hardest new field for legacy OT gear? Component Hash — now mandatory rather than optional, and often impossible to generate for legacy PLC/RTU firmware without vendor cooperation
What makes an SBOM usable for OT patch decisions? Pairing it with VEX (Vulnerability Exploitability eXchange), which says whether a listed CVE actually applies to this device

What CISA's 2026 SBOM Minimum Elements Update Actually Changed

On July 29, 2026, CISA, the NSA, the FBI, and 15 international partner cybersecurity agencies representing 13 other countries — Australia, Canada, the Czech Republic, France, Germany, India, Italy, Japan, Korea, the Netherlands, New Zealand, Poland, and Slovakia — jointly published the "2026 Minimum Elements for a Software Bill of Materials (SBOM)," formally replacing the 2021 NTIA baseline that most SBOM tooling and mandates have referenced up to now.

The update does two things. First, it tightens what counts as a compliant SBOM by making a field that used to be optional — Component Hash (both the hash value and the hash algorithm) — mandatory. Second, it adds new required fields, including Component License and SBOM Tool Name and SBOM Generation Context, and it renames the old "Known Unknowns" field to "Explicitly Identifying Unknown Information" (confirmed consistently across CISA's own release coverage and independent trade-press summaries, including Industrial Cyber and runsafesecurity's field-by-field mapping).

What the update does not do is equally important for this audience: per Help Net Security's coverage of the release, the 2026 baseline "applies the minimum elements to SBOMs for all software" — generic guidance covering commercial, open-source, AI, and SaaS software alike. There is no ICS-specific appendix, no exception for embedded firmware, and no acknowledgment that a device shipped in 2008 was never designed to produce a machine-readable component list at all. Translating a generic federal mandate into something an OT security team can actually act on is the point of the rest of this article.

It's also worth being precise about what this update is not. Two other 2026 regulatory tracks get mentioned in the same breath as SBOM mandates in industry coverage, but they are legally distinct instruments: CIRCIA, the US incident-reporting rule (its final-rule target has slipped repeatedly — from an original October 2025 statutory deadline, to a May 2026 internal target, to a September 2026 target as of this writing), and the EU Cyber Resilience Act's ENISA-run vulnerability/incident reporting obligation (its 24-hour early-warning clock starts September 11, 2026) both govern what happens after an incident or vulnerability is discovered — not what a software inventory has to contain. Don't conflate a CIRCIA reporting deadline or the CRA's ENISA reporting window with the CISA SBOM minimum-elements baseline; they come from different legal authorities and answer different questions.

The New Mandatory Fields, Scored Against a 20-Year-Old PLC

The table below is the practical translation this update is missing. Each row scores one new or changed field against what's realistic for a modern SaaS application versus a legacy PLC or RTU running firmware whose original source code may no longer exist anywhere, including at the vendor.

CISA 2026 Field What It Requires Feasibility — Modern SaaS App Feasibility — Legacy PLC/RTU Firmware
Component Hash (now mandatory) A cryptographic hash uniquely identifying each software component Trivial — generated automatically by any modern build pipeline Often impossible without the vendor re-building from original source, which may no longer exist
Component License The license governing each component Straightforward for open-source-heavy stacks with dependency-scanning tooling Frequently unknown — firmware built decades ago rarely tracked license provenance for every embedded library
SBOM Tool Name Which tool produced the SBOM Trivial — standard output of tools like Syft, Dependency-Track, or CycloneDX generators Requires binary-composition-analysis tooling (e.g., ONEKEY-style firmware SBOM generators) run against a compiled binary, not source
SBOM Generation Context The circumstances/environment the SBOM was generated under Straightforward — captured as part of CI/CD metadata Ambiguous — a binary-derived SBOM for 15-year-old firmware has a fundamentally different generation context than a source-derived one, and the field doesn't distinguish them
Explicitly Identifying Unknown Information (renamed from Known Unknowns) A structured way to flag components the SBOM author couldn't fully document Rare need — most components are fully known The single most-used field on a realistic legacy-device SBOM — this is where "we don't know what's in this firmware" gets documented instead of hidden

The pattern across every row is the same: the 2026 update assumes a software supply chain where source code, build pipelines, and license metadata exist and are accessible. Industry commentary from organizations like OT Ecosystem and firmware-security vendor ONEKEY has consistently argued that a meaningful share of legacy ICS devices simply cannot meet that assumption — the vendor may be defunct, the source may be lost, or the firmware may never have gone through a formal build process with tracked dependencies in the first place. That's an attributed industry consensus, not a CISA-sourced statistic — but it's the reason the last row of the table above, not the first, is where most real OT SBOM programs will spend their effort in 2026 and 2027.

When I've asked vendors for a component list on a customer's behalf, what came back was a firmware version string and a release note — a response with no hash, no license data, no tool name, and no generation context, which leaves four of the five fields in that table unanswerable from the reply itself. I also used to accept it. Writing "firmware at current vendor release" into a review closes a patch question and says nothing at all about what is compiled into the image, which is the whole reason the Explicitly Identifying Unknown Information row is where the honest work sits.

Why Legacy PLC and RTU Firmware Breaks the SBOM Model

Part of the reason legacy OT firmware resists this framework isn't just age — it's architecture. A large share of PLCs and RTUs across dozens of vendors run on a handful of shared runtimes rather than fully custom firmware. CoDeSys is the most-cited example: it's an embedded automation runtime licensed to and integrated into hundreds of different PLC models from dozens of manufacturers.

That sharing has a direct SBOM consequence. A single CVE discovered in a shared runtime like CoDeSys doesn't map to one product — it fans out across every PLC model that embeds it, from every vendor that licensed it, at whatever version each vendor happened to ship. Dale Peterson (S4 Events) has made a related estimate — an expert estimate, not a CISA or peer-reviewed figure, and treated here as such — that folding all of the software an SBOM surfaces into a plant's security patching program is "at least a 5x increase in asset/patch combinations" compared to patching at the device level alone. Peterson doesn't break that multiplier out by shared component, but he cites CoDeSys's spread across hundreds of PLC models as a concrete illustration of why the scope expands that fast. An SBOM that correctly lists "CoDeSys v3.5 SP19" as a component is accurate and CISA-compliant, but on its own it doesn't tell a plant which of its dozens of CoDeSys-based devices actually need attention first, or at all.

VEX vs. SBOM: What Actually Makes an OT Vulnerability List Usable

This is where VEX (Vulnerability Exploitability eXchange) becomes the layer that turns a compliant SBOM into something an OT security team can act on, rather than a longer list of things to worry about.

Dimension SBOM VEX
What it answers "What software components are inside this device?" "Is this specific known vulnerability actually exploitable in this specific product?"
Primary use in OT Inventory and compliance baseline Vulnerability triage — deciding what needs patching now, later, or never
What it looks like without the other A list of ingredients with no risk context — every CVE in every component looks like an emergency A risk judgment with no denominator — nothing to triage against without knowing what's inside the device
Common formats CycloneDX, SPDX CycloneDX VEX, CSAF VEX
Who typically produces it The device/software vendor, or a third-party binary-composition-analysis tool for legacy devices The device vendor, ideally — since only they can say whether a given CVE is reachable/exploitable in their specific product configuration

Without VEX, an SBOM alone reproduces the exact problem OT teams already live with: "why can't I just patch a PLC" turns into "why does every scan of my SBOM against the National Vulnerability Database flag hundreds of theoretical CVEs I can't act on." A component being present doesn't mean a vulnerability in that component is reachable, exposed to the network, or even compiled into the running firmware image. VEX is the practical filter that separates "this CVE exists in a component we ship" from "this CVE is actually a problem in this device, in this configuration, on this network." Vendors that publish SBOMs without any accompanying VEX statements are handing OT teams a longer homework assignment, not a shorter one.

Where SBOM Fits in an OT Security Program: The Step After Asset Inventory

SBOM collection isn't a starting point — it's the next layer on top of asset inventory, not a replacement for it. As covered in our OT asset management guide, that piece lays out a five-level asset visibility maturity ladder running from Level 0 (unknown unknowns) to Level 4 (continuous, automated inventory tied to change management). You cannot request, track, or evaluate an SBOM for a device you don't know exists. SBOM collection is realistically a Level 5 extension for sites that have already reached Level 3 or 4 on that ladder: once you know precisely what hardware is on the network, the next question becomes what software is running on each of those devices — and whether the vendor can produce any inventory of it at all.

For newer purchases, this is straightforward: build SBOM production and VEX support into procurement requirements going forward, the same way security requirements got built into RFPs after other supply-chain scares. For the installed base of legacy PLCs and RTUs already on the plant floor, the realistic starting move is a binary-composition-analysis pass using firmware-SBOM tooling (vendors in this space include Dependency-Track, Anchore, Interlynk, FOSSA, and ONEKEY-style firmware-focused generators) — producing a best-effort SBOM from the compiled binary when the vendor can't or won't produce one from source.

This is also where SBOM data feeds forward into segmentation planning: component-level software risk identified through an SBOM (or its absence) is one more input into the criticality and zone risk assessment that IEC 62443 zone-and-conduit design depends on — a device running unpatchable, unknown firmware is a stronger candidate for tighter zone isolation than one with clean, current SBOM and VEX data.

Why This Matters Now: Log4Shell, XZ Utils, and the Supply-Chain Precedent

SBOM mandates didn't appear in a vacuum. Two software supply-chain incidents outside the OT space did more than anything else to make "what's actually inside this software" a mainstream security question: Log4Shell (the December 2021 Apache Log4j vulnerability that turned out to be embedded, often invisibly, in an enormous share of enterprise Java applications) and the XZ Utils backdoor (a deliberately planted backdoor discovered in March 2024 in a compression library used across countless Linux distributions). Both are well-documented outside this article's own research and don't need original sourcing here — but the throughline to OT is direct: in both cases, organizations discovered they had no reliable way to know whether they were exposed, because no inventory of embedded components existed. That's the exact gap SBOM mandates, including CISA's 2026 update, are trying to close — and it's the same gap that shows up, worse, in a plant full of devices running firmware nobody has fully inventoried in 15 years.

The manufacturing sector already has a concrete, costly example of what happens when supply-chain visibility is missing: our manufacturing ransomware case studies piece covers the 2023 incident where ransomware at supplier MKS Instruments disrupted Applied Materials' operations downstream — not through a direct breach, but through a supply-chain dependency Applied Materials didn't have full visibility into. SBOM and VEX are software-layer instruments of the same broader principle: know what you depend on, one layer further out than your own network.

FAQ

Q: What is an SBOM in the context of industrial control systems (ICS/OT)?
A: An SBOM (Software Bill of Materials) for an ICS device is a formal inventory of every software component — libraries, dependencies, firmware modules, and their versions — running inside a PLC, RTU, HMI, or other industrial control device. CISA's 2026 Minimum Elements update sets a generic baseline for what fields that inventory should contain, but the guidance applies to all software and includes no ICS-specific requirements.

Q: Can legacy PLCs and RTUs actually produce a compliant SBOM?
A: Often only partially. Per industry commentary from firms like OT Ecosystem and ONEKEY, many legacy devices can't produce a source-based SBOM at all because the original vendor has lost the source code, gone out of business, or never tracked component provenance in the first place. The practical workaround is a binary-composition-analysis pass that reverse-engineers a best-effort component list from the compiled firmware image, plus explicit use of CISA's "Explicitly Identifying Unknown Information" field to document what genuinely can't be determined.

Q: What's the difference between VEX and an SBOM for OT security?
A: An SBOM lists what software components are inside a device. VEX (Vulnerability Exploitability eXchange) states whether a specific known vulnerability in one of those components is actually exploitable in that specific product. An SBOM without VEX makes every listed CVE look like an emergency; VEX is what lets an OT team triage a component list into an actual patch priority.

Q: What are the new mandatory fields in CISA's 2026 SBOM Minimum Elements update?
A: Component Hash (value and algorithm) moved from optional to mandatory, and new fields were added — including Component License, SBOM Tool Name, and SBOM Generation Context — alongside a rename of the old "Known Unknowns" field to "Explicitly Identifying Unknown Information." Field names confirmed against CISA's release coverage and cross-checked with independent trade-press field-by-field breakdowns (Industrial Cyber, runsafesecurity).

Q: Is CISA's SBOM guidance a legal requirement for OT operators?
A: For most private-sector OT operators, no — the Minimum Elements document is guidance, not a binding regulation, though it increasingly shapes federal procurement requirements and vendor expectations. It's also a separate track entirely from incident-reporting rules like CIRCIA (US) or vulnerability-disclosure timelines like ENISA's (EU) — those govern what happens after an incident, not what a software inventory must contain.

Sources

Author Bio

The Whitepaper Skeptic has direct experience with OT cybersecurity in industrial and smart-factory environments, including customer-facing security architecture reviews where legacy PLC and RTU firmware routinely had no source-based software inventory to point to at all — the exact gap between what a generic federal SBOM mandate assumes is possible and what a 15-to-20-year-old device on a live production line can actually produce.

Related Posts

Comments

Post a Comment

Popular posts from this blog

OT Security Vendor Comparison 2026: Dragos vs. Claroty vs. Nozomi Networks for Industrial Environments

Image
Dragos, Claroty, and Nozomi Networks were all named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms — so "which one is best" isn't the right question, because Gartner didn't rank a single winner among them. The real decision driver is environment fit: Dragos leans strongest on ICS-specific threat intelligence and managed detection for concentrated, high-criticality sites; Claroty covers the broadest scope across OT, IoT, building systems, and medical devices; and Nozomi Networks offers the most flexible deployment options for large, multi-site, geographically distributed operations. This guide builds a vendor-neutral decision matrix around those differences instead of repeating any vendor's self-reported ranking. Quick Facts Question Answer Are all three Gartner Leaders? Yes — Dragos, Claroty, and Nozomi Networks were three of only four vendors named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms, out o...
Read more

HBM Burn-In Testing Explained: Why Known-Good-Die Screening Now Happens Before Stacking (2026)

Image
HBM burn-in and known-good-die (KGD) testing means every individual memory die is electrically stressed and screened at the wafer level — before it's thinned, singulated, or stacked — instead of waiting to find defects only after a finished HBM stack fails final test. The reason this matters is economic, not just technical: a single bad die inside an 8-to-16-high HBM stack can force the entire stack to be scrapped, and HBM now accounts for roughly half the total cost of an AI accelerator package. That's why HBM makers and test-equipment vendors have visibly shifted testing "left" — earlier in the manufacturing flow — rather than relying on final test alone to catch problems. By The Whitepaper Skeptic — yield-economics work on an advanced-packaging project, plus HBM test-equipment tracking Quick Facts Question Answer What does "known-good-die" (KGD) mean? A die individually tested and verified to mee...
Read more

CoWoS and Hybrid Bonding Explained: TSMC's Advanced Packaging Behind AI Chips

Image
CoWoS (Chip-on-Wafer-on-Substrate) is TSMC's 2.5D advanced packaging platform — it places a large logic die, like an AI accelerator or GPU, next to multiple HBM memory stacks on a shared interposer, all inside one package. Hybrid bonding is a different thing entirely: a bump-less, direct copper-to-copper die-to-die (or die-to-wafer) bonding technique used for 3D stacking. They are not competing options, even though a lot of existing coverage frames "CoWoS vs hybrid bonding" as an either/or choice — CoWoS is a packaging platform, hybrid bonding is a bonding technique, and TSMC increasingly combines both inside the same package, most visibly in Nvidia's newest AI accelerator platforms. Quick Facts Question Answer What is CoWoS? TSMC's 2.5D packaging platform that places a large logic die and HBM stacks side-by-side on a shared interposer What is hybrid bonding? A bump-less, direct copper-to-copper die-to-die/die-to-waf...
Read more