Why does software supply chain risk become a safety risk at a utility?

At an electric utility, software does physical work: it operates breakers, runs protection systems and talks to field devices. A tampered vendor update, a compromised remote support tool or an unpatched component can therefore affect equipment and the people near it. NERC's CIP-013 standard sets the supply chain baseline for the bulk electric system.

Where does software touch the physical world?

Control rooms use software to operate switching equipment from afar. The CISA alert on the December 2015 attacks in Ukraine describes attackers using remote administration tools and industrial control system client software to open breakers at distribution companies. They also corrupted firmware in serial-to-Ethernet devices at substations, which made those devices unusable and complicated restoration.

That account is about intrusion, not supply chain compromise. It still shows the stakes: in operational technology, a software or firmware change can mean a physical device stops responding. Anything that arrives through the supply chain, such as a patch, a driver, an engineering workstation tool or a vendor's remote session, has the same reach as the software it replaces.

What does the standard ask for?

CIP-013-2, Cyber Security, Supply Chain Risk Management, states its purpose as mitigating cyber security risks to the reliable operation of the Bulk Electric System by implementing supply chain risk management controls for BES Cyber Systems.

Requirement R1 asks each responsible entity to develop documented plans for high and medium impact BES Cyber Systems and their associated access control and monitoring systems. The plans must cover procurement planning that assesses risk from installing vendor equipment and software, and from moving from one vendor to another. They must also address, as applicable:

• vendor notification of incidents tied to the products or services;
• coordination of responses to those incidents;
• vendor notification when remote or onsite access should end;
• vendor disclosure of known vulnerabilities;
• verification of software integrity and authenticity for all vendor software and patches;
• coordination of controls for vendor-initiated remote access.

Requirement R2 requires the entity to implement the plans it wrote. The standard also lists exemptions and scoping rules, so confirm which of your assets are in scope with your compliance team.

What is the gap between a plan and practice?

Writing the plan is the easy part. The hard part is proving each line on a real Tuesday.

Integrity and authenticity of patches. The standard asks for verification, which means someone must actually check signatures or hashes before an update reaches an operational network, and record that they did.

Vendor remote access. Controls must be coordinated, and the vendor must tell you when access should stop. That is hard if you cannot list which vendor accounts and tunnels exist. The 2015 alert's guidance goes further: no persistent vendor connections into the control network, and access that is operator controlled and time limited.

Vulnerability disclosure. A vendor's promise to disclose is only useful if you can match it to your installed versions. That needs an inventory of software and firmware down to component level.

Transitions. Moving from one vendor to another is named explicitly. It is a moment of elevated risk: new tooling, new accounts, new integration work.

Why do software bills of materials matter here?

A bill of materials answers the question you ask when a vulnerability is disclosed: do we run it, and where? For long-lived operational equipment, where devices may run for years, the answer is often unknown. Asking vendors for component lists at procurement, and refreshing them with each update, turns the disclosure requirement into something you can act on. We make no claim that this alone satisfies a requirement. It supports the evidence.

What to do

1. Confirm which of your systems fall under CIP-013 scope and which vendors serve them.
2. Add the six R1 topics as contract language and procurement questions.
3. Build a verification step for every vendor update: check signature or hash, log it, and only then stage it.
4. List every vendor remote access path, name an owner for each, and close always-on ones.
5. Request component lists for operational software and firmware, and store them with your asset records.
6. Match vendor disclosures against that inventory on a schedule.
7. Plan vendor transitions as projects, with a risk review and an access cleanup.
8. Rehearse manual operation for the case where a field device or console is lost.

Quick check

Sources

• NERC, CIP-013-2 Cyber Security: Supply Chain Risk Management
• CISA, ICS Alert IR-ALERT-H-16-056-01: Cyber-Attack Against Ukrainian Critical Infrastructure

Last reviewed: 18 October 2026.