Why should electrical utilities ask for SBOMs on field equipment?

Utilities should ask for SBOMs on field equipment because relays, inverters, meters, gateways and controllers all run vendor firmware built from third-party libraries. When one of those libraries is found vulnerable, an SBOM tells you which devices are affected, so you can plan compensating controls and outage windows instead of guessing.

What is the business reason?

Utility equipment stays in service for many years and cannot be updated casually. A firmware change may need testing, a maintenance window and sometimes regulatory notice. That makes the question "do we have this flaw anywhere" valuable, since the answer decides how much planning follows.

NIST SP 800-161 describes the underlying issue: limited visibility into how acquired technology is built and deployed, and products that may be vulnerable because of poor development practices. CISA describes an SBOM as a nested inventory of the components that make up software.

What does the North American rule say?

NERC's CIP-013 standard on supply chain risk management was developed in response to FERC Order 829 of July 2016. From NERC's text and summaries: requirement R1 asks the responsible entity for a documented supply chain risk management plan covering procurement and deployment of vendor products and services for BES Cyber Systems, R2 requires implementing the plan, and R3 requires review and approval of the plan by the CIP Senior Manager or delegate at least every 15 calendar months. Summaries note that the standard does not require renegotiating existing contracts. We did not fetch the full text of R1, so read the standard before you map your program to it. Utilities outside North America will have different rules.

CIP-013 does not, in what we read, name SBOMs. An SBOM is one practical way to support the vendor risk questions the plan has to answer.

What should you request from vendors?

1. A machine readable SBOM for each product and firmware version, in SPDX or CycloneDX.
2. A statement on how often it is updated and what triggers an update.
3. A vulnerability disclosure contact and a target time to notify customers.
4. A way to say whether a listed vulnerability actually affects the product, such as a VEX statement. CISA describes VEX as an advisory-style attestation on whether a product is affected.
5. The firmware update method, including how updates are signed and verified.

How do you use what you receive?

Load SBOMs into an inventory keyed by device model and firmware version. Match components against vulnerability data on a schedule. When a new advisory appears, query the inventory and produce a list of affected device types and counts. Then decide using the OT lens: what does the device do, can the vulnerable code be reached from the networks it sits on, and what is the compensating control.

NIST SP 800-82 Rev. 3 frames OT security around reliability and safety as well as confidentiality, which is why a quick patch is not always the right answer. ISA/IEC 62443 includes requirements for product suppliers and for service providers, which you can cite in procurement.

What are realistic limits?

Some vendors will not provide an SBOM. Some firmware is a sealed binary whose contents even the vendor cannot fully list. SBOMs can be out of date or incomplete. Treat them as a starting point, and ask hard questions where the equipment is critical.

What to do

1. Add SBOM, VEX and disclosure contact requirements to procurement templates.
2. Request SBOMs for the highest criticality device families first.
3. Build an inventory of device model, firmware version and components.
4. Match against advisories on a schedule and when new ones are published.
5. For each hit, record exposure, compensating control and the outage window for a fix.
6. Review the process with your compliance team against the rules that apply to you.

Quick check

Sources

• NERC CIP-013-2
• CISA SBOM
• NIST SP 800-161 Rev. 1
• NIST SP 800-82 Rev. 3
• ISA/IEC 62443 series overview

Last reviewed: 18 October 2026.