SBOM for OT: What to Ask Vendors Before the 2027 Procurement Mandates Land

A software bill of materials is an inventory of the components inside a piece of software, including third-party and open-source libraries and their versions. In enterprise IT it has been an established practice for several years. In operational technology it has been largely aspirational, because the vendors were not producing them and the operators were not asking.

That is changing through regulation rather than through best practice, and it is changing across several jurisdictions at once. Operators who start asking vendors now will be specifying from a position of choice. Operators who wait until a mandate applies will be negotiating with an installed base that cannot answer the question.

 

Why This Is Arriving Now

Four regulatory currents are converging on the same requirement, and each approaches it from a different direction.

• Bill C-8 in Canada. The Critical Cyber Systems Protection Act requires designated operators to mitigate supply chain and third-party risks, following guidance developed by the Communications Security Establishment.
   
• Executive Order 14420 in the United States. Grid equipment provenance is now subject to national emergency authority, covering not only hardware but associated software, firmware and digital services. See our guide to what EO 14420 requires.
   
• The EU Cyber Resilience Act. Products with digital elements placed on the EU market carry SBOM obligations, which reaches North American manufacturers exporting to Europe.
   
• IEC 62443-4-1. The secure development lifecycle requirements already expect component management and vulnerability handling from product suppliers, which is the same discipline an SBOM documents.

 

Why SBOM Is Harder in OT Than in IT

The concept transfers cleanly. The practice does not.

Long asset lifecycles are the first problem. A DCS commissioned in 2008 may still be in service, and no SBOM exists for it because the practice did not exist when it was built. Reconstructing one after the fact is generally not possible without vendor cooperation that may no longer be available if the product is end-of-life.

Embedded firmware is the second. Much OT software is not an application running on an operating system but firmware compiled into a device, where component transparency is limited by design and by the vendor commercial position.

And the volume problem is the third. CISA published 508 ICS advisories covering 2,155 CVEs in 2025, the first year above 500, with average severity trending upward. An SBOM tells you which of those advisories touch components inside your assets. Without one you are matching advisories against product names and hoping.

 

 

What an SBOM actually buys you operationally Speed at the moment it matters. When a widely used library is found to have a critical vulnerability, the question every operator asks is whether it is present in their environment. With SBOMs the answer is a query. Without them it is a round of emails to a dozen vendors, most of whom will take weeks to respond, during which your exposure is unknown rather than managed.

 

What to Ask OT Vendors

• Do you provide an SBOM for this product, in a machine-readable format such as SPDX or CycloneDX?
   
• How often is it updated, and are we notified when it changes after a firmware release?
   
• Does it cover firmware components, or only application-layer software?
   
• What is your process for notifying customers when a component in the SBOM has a disclosed vulnerability?
   
• What is your remediation commitment when a component vulnerability is confirmed as exploitable in your product?
   
• For end-of-life products in our installed base, will you provide an SBOM retrospectively?

The last question is where most conversations become interesting. A vendor unwilling to answer it for equipment you already own is telling you something useful about your remediation options for the remainder of that asset lifecycle.

 

What to Do With SBOMs Once You Have Them

An SBOM sitting in a procurement folder achieves nothing. The value comes from connecting it to the vulnerability process.

 

Step	What It Involves	Connects To
Store centrally	SBOMs held against asset records rather than in contract files	OT asset inventory
Match to advisories	Cross-reference component versions against CISA and vendor bulletins	Vulnerability management
Assess exploitability	Component presence is not exposure; assess network reachability	OT risk assessment
Feed remediation	Route confirmed exploitable findings into the patch or compensating control queue	Patch management

 

That chain is what turns an SBOM from a compliance artefact into an operational capability. Our guide to OT vulnerability management covers the prioritization methodology, and OT patch management covers what happens when the answer is that you cannot patch.

 

Start With Procurement, Not With the Installed Base

Retrofitting SBOM coverage across an existing OT estate is slow, expensive and partially impossible. Requiring it in new procurement is none of those things.

Add SBOM provision to your technical specification for every new OT asset, and treat vendor willingness as a selection criterion alongside price and capability. Over a normal replacement cycle, coverage builds without a dedicated program. For the existing estate, prioritize the assets where an SBOM would change a decision: internet-reachable systems, assets with active vendor connections, and anything protecting a safety function.

 

Why Choose Arista Cyber

Arista Cyber helps operators write SBOM requirements into OT procurement specifications and connect the resulting data to a working vulnerability management process rather than a filing cabinet.

We build the asset inventory the SBOMs attach to, assess exploitability against your actual network architecture rather than CVSS alone, and map the requirement across the frameworks that apply to you, whether that is Bill C-8 supply chain duties, NERC CIP, or IEC 62443. Because we also work in functional safety, we can identify which assets warrant the strictest scrutiny.

 

Next Steps

The cheapest version of this is adding a clause to your next procurement specification. Explore our OT assessment and analysis services, read about OT vulnerability management, or contact the Arista Cyber team.

 

Common Questions

Is SBOM legally required for OT equipment yet?

Not universally, and not yet as a standalone OT requirement in North America. The obligations arrive indirectly: Bill C-8 requires supply chain risk mitigation, EO 14420 concerns equipment and software provenance, and the EU Cyber Resilience Act imposes SBOM duties on products with digital elements placed on the EU market. The direction is consistent across all of them, which is why procurement specifications are the sensible place to start rather than waiting for a specific mandate.

What formats should we ask for?

SPDX and CycloneDX are the two widely adopted machine-readable formats. Either is acceptable; what matters is that it is machine-readable rather than a PDF list, because the operational value comes from querying it against advisories automatically. A PDF SBOM satisfies a contract clause and very little else.

Our vendors will not provide SBOMs. What now?

Record the refusal and treat it as a risk input rather than a dead end. A vendor unable or unwilling to describe what is inside their product limits your remediation options for that asset, which is a factor in replacement planning and in compensating control design. In the meantime, manage those assets through network reachability controls, since segmentation reduces exposure regardless of what components are inside.

 

Writing your next OT procurement specification? Arista Cyber helps operators build SBOM requirements into procurement and connect the output to a working vulnerability process. Book a Free Consultation