Software Supply Chain Security for Electric Utilities: A 90-Day Plan

An electric utility secures its software supply chain by knowing exactly what software runs in its control systems, verifying where every installer and patch came from before it goes in, and holding vendors to written commitments on incidents, vulnerabilities and remote access. NERC CIP-013-2 makes that a documented plan for high and medium impact BES Cyber Systems, and CIP-010-4 Part 1.6 makes source and integrity checks part of every baseline change. With FERC Order No. 912 directing NERC to tighten the supply chain standards, the next 90 days are a good time to turn a plan on paper into evidence you can show.

This guide is for the CIP Senior Manager or CISO, OT engineering, the NERC CIP compliance manager, procurement, field operations and the team that builds the integrations nobody lists on the asset register. The first two thirds work with whatever tools you already have.

Key takeaways

• CIP-013-2 is a plan, an implementation and a review cycle. R1 requires a documented supply chain risk management plan, R2 requires you to follow it, and R3 requires CIP Senior Manager approval of the plan at least once every 15 calendar months.
• CIP-010-4 Part 1.6 is where software integrity becomes daily work. Before a baseline change, verify the identity of the software source and the integrity of the software, when the source gives you a way to do so.
• FERC Order No. 912 (issued 18 September 2025, effective 24 November 2025) directs NERC to file new or modified supply chain standards within 18 months of issuance, covering the sufficiency of supply chain plans and how the standards apply to Protected Cyber Assets.
• The incidents are not hypothetical. CISA's February 2024 advisory on Volt Typhoon names the energy sector, and CERT Polska's January 2026 report describes destructive attacks on grid connection points at more than 30 wind and solar farms in December 2025.
• The fastest win is an SBOM of what you build and integrate, not only of the vendor appliances you buy.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM with SBOM requests, CSAF and VEX upload, the compliance and GRC suite with a NERC CIP framework, the Safeguard CLI and local runner, and air-gapped deployment.

The situation

The trigger is usually one of four things: the CIP-013 plan is due for its 15-month review; a Regional Entity audit will sample CIP-010 change tickets for integrity checks; a vendor has published an advisory for a product inside the Electronic Security Perimeter; or the board has read about Volt Typhoon and asked whether it could happen here, and how you would know.

Order No. 912 adds a fifth. FERC has told NERC to come back with stronger supply chain standards, so the plan that passed your last audit is the floor, not the ceiling.

A bad week looks like this. A patch for an EMS server arrives, the hash on the vendor portal does not match the file because the vendor re-released it, and nobody knows who to call. An ICS advisory names a component that may or may not be inside the historian, and the only way to find out is a support case. The 35-day patch evaluation clock from CIP-007-6 is already running.

What software an electric utility runs

Utility software ranges from vendor appliances you cannot open, to commercial applications with open source inside, to scripts your own engineers wrote.

Two points matter. First, vendor software is rarely only vendor software: a control center platform ships with operating system packages, databases, runtimes and open source libraries the vendor did not write either, and only the vendor can tell you what is inside the parts you cannot see. Second, the integration glue is where many utilities carry their least tracked software. A Python job that moves historian data across a boundary can pull in dozens of open source packages, never went through procurement, and often sits next to systems in CIP scope.

For a shorter, earlier overview of NERC CIP and software, see Energy sector software security under NERC CIP. For the OT side shared with factories, see manufacturing OT software supply chain, and for device firmware, IoT firmware SBOM requirements.

The regulations and frameworks that apply

This section summarises the primary texts as fetched on 25 October 2026. It is not legal or compliance advice; your Regional Entity and compliance counsel are the authorities for your registration.

NERC CIP-013-2: supply chain risk management

CIP-013-2 applies to high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). FERC approved version 2 on 18 March 2021, and Order No. 912 describes it as part of the currently effective supply chain standards.

• R1 requires one or more documented supply chain cyber security risk management plans.
  • Part 1.1 covers procurement planning: identifying and assessing risks to the Bulk Electric System from (i) procuring and installing vendor equipment and software and (ii) transitions between vendors.
  • Part 1.2 covers the procurement itself, with six items: 1.2.1 vendor notification of vendor-identified incidents; 1.2.2 coordination of responses to those incidents; 1.2.3 vendor notification when remote or onsite access should no longer be granted to vendor representatives; 1.2.4 disclosure by vendors of known vulnerabilities in their products or services; 1.2.5 verification of software integrity and authenticity of all software and patches the vendor provides; and 1.2.6 coordination of controls for vendor-initiated remote access.
• R2 requires you to implement the plan. It does not require renegotiating existing contracts, and contract terms and vendor performance are outside its scope.
• R3 requires review and CIP Senior Manager (or delegate) approval of the plan at least once every 15 calendar months.

NERC CIP-010-4: baseline changes and software integrity

CIP-010-4 Requirement R1 deals with configuration change management. Part 1.6 applies to high impact BES Cyber Systems and medium impact BES Cyber Systems, along with their associated EACMS and PACS. Before a change that deviates from the existing baseline for operating system or firmware, commercially available or open source software, or security patches, and when the method is available from the software source, the entity must:

• 1.6.1 verify the identity of the software source; and
• 1.6.2 verify the integrity of the software obtained from the software source.

Example evidence is a change record showing verification before the change, or a documented automatic mechanism. If a vendor publishes no hash or signature, Part 1.6 does not let you invent one, but your CIP-013 plan should push the vendor for one under Part 1.2.5.

NERC CIP-007-6 R2: the 35-day patch clock

CIP-007-6 R2 is the patch management requirement that sets the tempo for most utility security teams. Part 2.2 requires that at least once every 35 calendar days you evaluate security patches released since the last evaluation, from the sources identified in Part 2.1. Part 2.3 requires that within 35 calendar days of completing the evaluation you apply the applicable patches, create a dated mitigation plan, or revise an existing one. You cannot track a patch source for a component you do not know is there.

NERC CIP-005-7 and CIP-003-9: vendor remote access

Vendor remote access is where supply chain risk turns into a live connection. CIP-005-7 R2 Parts 2.4 and 2.5 require methods to determine active vendor remote access sessions and methods to disable them, including Interactive Remote Access and system-to-system remote access, for high impact BES Cyber Systems and medium impact systems with External Routable Connectivity. R3 extends vendor remote access management to EACMS and PACS.

For low impact assets, CIP-003-9 adds Section 6 to Attachment 1: a process to mitigate risks from vendor electronic remote access, with methods for determining it (6.1), disabling it (6.2) and detecting known or suspected inbound and outbound malicious communications (6.3). NERC's November 2024 implementation plan for CIP-003-11 states that CIP-003-9 becomes effective 1 April 2026, with CIP-003-10 and CIP-003-11 then pending regulatory approval. Check NERC's current effective dates before planning around a version.

FERC Order No. 912: what is coming next

FERC issued Order No. 912 on 18 September 2025, and it became effective on 24 November 2025. It directs NERC to submit new or modified Reliability Standards within 18 months of issuance, which points to a filing around March 2027. The order names CIP-005-7, CIP-010-4 and CIP-013-2 as the current supply chain standards and asks NERC to address two gaps: the sufficiency of entities' supply chain risk management plans in how they identify and respond to supply chain risks, and how the supply chain standards apply to Protected Cyber Assets.

A plan that says "assess vendor risk" without saying how, how often and what triggers a reassessment is the kind of plan Order No. 912 is aimed at.

DOE Supply Chain Cybersecurity Principles

In June 2024 the Department of Energy's Office of Cybersecurity, Energy Security, and Emergency Response (CESER) published Supply Chain Cybersecurity Principles, developed with input from ICS manufacturers and asset owners and drawing on research at Idaho National Laboratory. It is voluntary and mirrors each principle for suppliers and end users. End users are asked to engage suppliers on product security features and to include contractual language for terms, conditions and testing; suppliers are asked for transparency about software and hardware composition, security patches until announced end of life, and coordinated vulnerability disclosure. That maps neatly onto CIP-013 Part 1.2 and gives procurement language vendors have already seen.

NIST SP 800-161 Rev. 1 and CISA's 2026 SBOM minimum elements

NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, was published in May 2022 and updated on 1 November 2024. It is the deep reference for building a supply chain risk program.

On 29 July 2026, CISA, NSA, FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials, which builds on and replaces the NTIA 2021 minimum elements. CISA lists new baseline fields including Component Hash, License, SBOM Tool Name and SBOM Generation Context. The component hash field is directly useful for CIP-010 Part 1.6, because it gives you something to verify against.

How the rules fit together

Real public incidents from the last three years

These are public incidents with primary reporting. The summaries stay with what the sources say.

Volt Typhoon pre-positioning in US critical infrastructure (February 2024)

On 7 February 2024, CISA, NSA, FBI and partner agencies published advisory AA24-038A on Volt Typhoon, a group the advisory attributes to the People's Republic of China. The US authoring agencies said they had confirmed compromises of IT environments at multiple critical infrastructure organizations, primarily in the Communications, Energy, Transportation Systems, and Water and Wastewater Systems sectors. The agencies assess with high confidence that the actors were pre-positioning on IT networks to enable lateral movement to OT assets, and in one confirmed compromise they moved laterally to a control system. The advisory notes that some victims were smaller organizations with limited cybersecurity capabilities that serve larger ones, which fits many municipal utilities and cooperatives.

The XZ Utils backdoor (March 2024)

On 29 March 2024 CISA reported that malicious code had been embedded in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094. XZ Utils is data compression software that may be present in Linux distributions, and CISA said the malicious code may allow unauthorized access to affected systems. CISA advised developers and users to downgrade to an uncompromised version such as 5.4.6 Stable and to hunt for malicious activity.

No utility was named. The question for every operator that week was whether 5.6.0 or 5.6.1 was installed anywhere: control center Linux servers, in-house container images, vendor appliances built on Linux. An inventory answers that; without one, the answer waits on support cases.

Destructive attacks on Polish energy facilities (December 2025)

On 30 January 2026, CERT Polska published a report on coordinated attacks that took place on 29 December 2025. They were directed at more than 30 wind and photovoltaic farms, a manufacturing company and a large combined heat and power plant supplying heat to almost half a million customers. CERT Polska describes the objective as purely destructive.

At the renewable sites, the attacks targeted grid connection points, the substations that move power from wind and solar plants into the distribution system. CERT Polska lists the devices of interest as RTUs used for telecontrol, local HMIs, protection relays and other industrial automation equipment. The attacks disrupted communication between the farms and the distribution system operator but did not affect ongoing electricity production. The attack on the heat and power plant did not achieve its intended effect of disrupting heat supply.

On how the attackers got in, the report says each affected renewable facility had a perimeter device serving as both VPN concentrator and firewall, with the VPN interface exposed to the internet and accounts that could authenticate without multi-factor authentication. Some of those devices had been vulnerable in the past, including to remote code execution flaws, and CERT Polska notes that reusing the same accounts and passwords across facilities is a common industry practice that would let one compromised account open many sites. CERT Polska says the infrastructure overlaps with a publicly tracked activity cluster known for interest in the energy sector; that attribution is its own assessment.

The supply chain angle is vendor and integrator access (CIP-013 Parts 1.2.3 and 1.2.6, CIP-005 R2), and the reminder that perimeter devices are software with their own patch history.

For guidance on reconstructing what happened after an incident like these, see the software supply chain forensics guide.

The personas who own the problem

Supply chain security at a utility usually fails at the handoffs: procurement signs a contract compliance never reads, engineering installs a patch security never saw, and in-house developers never appear in the CIP program.

CIP Senior Manager or CISO

Their name is on the plan, because CIP-013 R3 makes them approve it every 15 calendar months. They need a defensible answer to "are we exposed, and how would we know?" at the R3 review, before an audit, and the day a joint advisory names the energy sector. What helps is one page per cycle: systems in scope, the vendors behind them, which vendors met each Part 1.2 commitment, open exceptions with expiry dates, and how long the last "are we affected" question took to answer.

Director of EMS, SCADA or OT engineering

They need fewer surprises during outage windows, every 35-day patch cycle and every time a vendor asks for remote access to troubleshoot. What helps is a standard CIP-010 Part 1.6 routine the field team can follow without calling security, and a decision table for when the vendor provides no hash.

NERC CIP compliance manager (GRC)

They need evidence by requirement part when the audit notice arrives. Auditors sample: they pick change tickets and ask for the verification step, pick purchases and ask for the risk assessment, pick vendors and ask for the Part 1.2 language. What helps is a register tying each in-scope system to its vendor, contract language, patch source and last verified installation, with links to evidence rather than narrative.

Procurement and vendor risk

They need RFP and contract language and a way to track whether the vendor delivered, at every purchase, renewal and vendor transition (CIP-013 Part 1.1 names transitions explicitly). What helps is a clause library mapped to Parts 1.2.1 to 1.2.6, an SBOM request with a deadline and a format, and tiering that puts BES Cyber System vendors first.

Substation, protection and field operations

They need to know which firmware and engineering software versions are deployed at each site when a relay or RTU advisory lands, and a rule that no file reaches a field device without the Part 1.6 check.

Software engineering lead for in-house tools

They need to know which open source packages their integrations and portals pull in, on every pull request and rebuild. What helps is an SBOM on every build, a CI gate that blocks known critical vulnerabilities, and upgrade pull requests instead of spreadsheets of findings.

Step by step: a 30/60/90-day plan that works with or without Safeguard

The plan assumes a CIP program and a CIP-013 plan already exist. It makes them provable and brings untracked software into view.

Days 1 to 30: inventory and the plan you actually have

1. Pull the CIP-013 plan and the last R3 approval. Note the approval date and count forward 15 calendar months. That is your hard deadline for the next review.
2. List every vendor behind a high or medium impact BES Cyber System, EACMS or PACS. Include integrators and managed service providers, not just original manufacturers. Mark which ones have remote access.
3. For each vendor, check the six Part 1.2 items in the contract, purchase order or security addendum. Record present, partial or absent. Do not renegotiate yet; the standard does not require it for existing contracts.
4. Refresh the CIP-010 R1 baseline with exact versions, not ranges or "current version".
5. Find the software nobody bought: every script, service and container on or next to in-scope hosts. Put each in source control.
6. Generate an SBOM for everything you build, in SPDX or CycloneDX, for in-house code and container images. These are the components you can fix yourself.
7. Time your "are we affected" answer for a recent widely reported vulnerability across in-scope systems. This is the metric you will improve.

Day 30 checkpoint for the CIP Senior Manager: vendor list with Part 1.2 coverage, baseline with exact versions, first SBOMs for in-house code, and a baseline "are we affected" time.

Days 31 to 60: procurement, intake and the Part 1.6 routine

8. Adopt a clause library mapped to Part 1.2. Use the template below for every new purchase and renewal from now on.
9. Send SBOM requests to your top-tier vendors. Ask for SPDX or CycloneDX, the product versions you run, component hashes as described in CISA's 2026 minimum elements, and a named contact for security advisories. Set a deadline.
10. Ask for CSAF advisories and VEX statements, so you can check exposure without a support case and record a vendor's "not affected" per product version.
11. Standardise the CIP-010 Part 1.6 pre-install routine with the checklist below, and add it as a required step in the change ticket template.
12. Inventory vendor remote access paths: how each vendor connects, who approves sessions, how sessions are disabled and how misuse would be detected. Include low impact sites for CIP-003-9 Section 6.
13. Gate your own builds. Add a check in CI that fails a build when a critical known vulnerability is present in an in-house integration or portal, with an exception process that requires a justification and an expiry date.

Days 61 to 90: evidence, drills and the next review

14. Run a tabletop (illustrative scenario): an open source library inside your EMS vendor's platform is reported compromised. Time the answers to: is it here, which versions, what has the vendor said.
15. Run a second tabletop (illustrative scenario) on the CERT Polska pattern: a remote site perimeter device with an internet-exposed VPN and shared credentials, walked through CIP-005 R2.4 and 2.5 and CIP-003-9 Section 6.
16. Build the requirement-to-evidence register. One row per requirement part, with links to the evidence. The compliance manager owns it.
17. Measure again: the "are we affected" time, change tickets with a completed Part 1.6 check, and vendors with full Part 1.2 coverage.
18. Update the CIP-013 plan to describe how you identify and respond to supply chain risk, how often you reassess vendors, and what triggers a reassessment. That is the sufficiency question Order No. 912 raises.
19. Take it to the CIP Senior Manager for R3 approval if the review is due, or as an interim update if it is not.

Template: procurement language mapped to CIP-013 Part 1.2

This is a starting point for your counsel and procurement team, not contract text.

Checklist: CIP-010 Part 1.6 before any baseline change

• The file came from the source listed in the patch source register.
• The source identity was checked (vendor portal account, signed download or signing certificate).
• The hash or signature came through a different channel from the file where possible.
• The computed hash matches, and both values are in the change ticket.
• If the vendor offers no method, the ticket says so, and the vendor is flagged for Part 1.2.5 follow-up.
• The new version is written into the baseline as an exact version string.
• Any SBOM or VEX the vendor supplied for this version is attached.

Decision table: the vendor will not provide an SBOM

How do SBOMs fit CIP-013 if the standard does not require them?

CIP-013 does not use the word SBOM, but it requires processes for vulnerability disclosure (Part 1.2.4) and procurement risk assessment (Part 1.1). An SBOM is the most direct way to know what a disclosure applies to and to answer XZ-style questions yourself. Asking for one is well supported by the DOE principles and CISA's minimum elements; requiring one in every legacy contract is not what the standard says.

What if a device cannot be scanned?

Many substation and plant devices cannot run an agent or reach the internet. Their inventory comes from vendor SBOMs, release notes and engineering records, and the integrity check happens on the engineering workstation before the file goes to the device. Put scanning effort into your own code, container images, hosts and received files.

How Safeguard does this

Everything above can be done with spreadsheets, open source tools and discipline. Safeguard brings it into one place. The steps follow the 30/60/90 plan; commands and YAML are copied from docs.safeguard.sh as of 25 October 2026 and were not run for this post.

1. Inventory the software you build. In the web app, open Integrations and connect repositories (GitHub, GitLab, Bitbucket or any Git URL), container registries, or a manifest file. SBOM generation and analysis (GA) and software composition analysis (GA) build an SBOM per project across the full transitive dependency tree.

2. Scan where cloud access is not allowed. For repositories you will not connect to a cloud service, the Safeguard CLI (GA) includes a local runner (GA). The docs say the runner polls the platform over outbound HTTPS that it opens, nothing connects to it, it runs each scan job locally, and it uploads only the resulting SBOM and findings, never your source code. Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login in the terminal and approve the session in your browser. For a one-off scan of a directory or an SBOM you already have, the docs show:

safeguard scan --dir .
safeguard scan --sbom sbom.json

safeguard scan writes results as JSON files under an output folder and does not fail on findings; gating is done separately (step 7).

3. Check vendor SBOMs and VEX before you trust them. The CLI validates CycloneDX and SPDX SBOMs and CSAF and OpenVEX documents against their specifications:

safeguard validate sbom.json --strict -o report.json

4. Request SBOMs from vendors and track them. In TPRM (GA), add vendors with a risk tier (Critical, High, Medium or Low) and SBOM status, or bulk import them from CSV. From a vendor, choose Request SBOM, select products and a template, set a deadline and send. The docs describe status tracking from Sent to Validated or Rejected, automated reminders, and validation on receipt (format, completeness and an automatic vulnerability scan), with Request Revision for submissions that fall short.

5. Load vendor advisories and VEX statements. With CSAF and VEX upload (GA), go to Integrations, filter by Upload, and choose Upload CSAF/VEX. The docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. A vendor's "not affected" statement can then sit next to the findings for that product version.

6. Turn on the NERC CIP framework. In the compliance and GRC suite (GA), NERC CIP is a framework under Americas, on in your workspace unless you switch it off in Compliance › Manage. Its scan requirements are checked against each product's SBOM: baseline inventory with exact versions (CIP-010 R1), integrity hashes for source and integrity verification (CIP-010 Part 1.6 and CIP-013 Part 1.2.5), known suppliers (CIP-013 R1), and components identifiable against patch and vulnerability sources (CIP-007 R2). Policy templates include a NERC CIP Supply Chain Risk Management Policy.

7. Gate what you ship. With policies and gates (GA), create a policy under Settings, Policies with conditions such as vulnerability severity, CVSS, EPSS or license, and set its action. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). Approval for a legitimate exception runs through the exception workflow: request, justification, expiration date, approver decision and an audit trail. In GitHub Actions, the docs show this workflow:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add that adding --fail-on-gate all fails the job on a policy gate instead of a severity threshold.

8. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV. Reachability analysis (GA) labels findings reachable, conditionally reachable, unreachable or unknown, treating unknown as potentially reachable, which gives a 35-day patch cycle an ordered list for the code you build.

9. Fix in-house code with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, one at a time or in bulk with one pull request per repository. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on and decides how far it goes.

10. Keep it inside the perimeter if you need to. Air-gapped deployment (GA) runs the platform in your environment, fed by signed snapshot bundles through a one-way diode, manual media or a DMZ receiver, with no component inside the perimeter calling outbound. Zero AI mode (GA) runs with no LLM in the loop.

Safeguard's own security posture is relevant here, because once you adopt it, Safeguard becomes a vendor in your CIP-013 process. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Assess it the way you assess any other vendor.

What Safeguard does not do

• It does not make you compliant with NERC CIP. It produces inventories, findings, gates and evidence; your Regional Entity judges compliance.
• It cannot scan firmware inside relays, RTUs or IEDs in the field. For devices you cannot scan, Safeguard works from what vendors give you: SBOMs, CSAF advisories and VEX statements. If a vendor provides none, that gap remains.
• It does not verify vendor files on your engineering workstation for you. The NERC CIP framework checks that SBOM entries carry hashes and exact versions. The CIP-010 Part 1.6 check before installation is still a step your engineer performs and records.
• It does not control or monitor vendor remote access sessions. CIP-005 R2.4 and R2.5 and CIP-003-9 Section 6 need your remote access tooling and procedures.
• It does not write or negotiate contract terms. TPRM tracks SBOM requests and vendor tiers; the Part 1.2 language is between your counsel, procurement and the vendor.
• It does not fix vendor code. Autonomous remediation opens pull requests in repositories you own. A vulnerability inside a vendor platform still needs the vendor's patch.
• The docs control catalog for NERC CIP names some earlier standard versions (for example CIP-003-8 and CIP-002-5.1a). Map those controls to the versions in effect for your registration.

Common mistakes

• Treating the CIP-013 plan as a procurement document only. The plan has to be implemented (R2), and the evidence of implementation lives in engineering and change management as much as in purchasing.
• Writing "latest version" in the baseline. CIP-010 needs versions you can compare against. A range or a placeholder hides deviations.
• Taking the hash from the same page as the download. If the page is compromised, both are. Get the hash or signature through a separate channel where the vendor allows it.
• Leaving in-house integrations out of the program. The scripts that move data between zones are software in your supply chain, and their open source dependencies are not reviewed by any vendor.
• Ignoring low impact sites. CIP-003-9 Section 6 covers vendor electronic remote access there, and the Polish incident targeted exactly that kind of grid connection point.
• Counting SBOMs instead of answers. The measure that matters is how long it takes to answer "are we affected" and to act, not how many files you have collected.

FAQ

Does NERC CIP-013 require an SBOM?

No. CIP-013-2 does not mention SBOMs. It requires processes for vendor vulnerability disclosure, software integrity verification and risk assessment during procurement. An SBOM is a strong way to meet those processes, and the DOE principles and CISA's 2026 minimum elements support asking for one.

What is the difference between CIP-013 Part 1.2.5 and CIP-010 Part 1.6?

Part 1.2.5 is about procurement: your plan must address how vendors let you verify the integrity and authenticity of their software and patches. CIP-010 Part 1.6 is about operations: before a baseline change, you verify the source identity and the integrity of the specific software you are about to install, when the source provides a method.

How often must the CIP-013 plan be reviewed?

CIP-013-2 R3 requires review and CIP Senior Manager or delegate approval at least once every 15 calendar months.

What does FERC Order No. 912 change today?

It does not change your obligations today. It directs NERC to file new or modified supply chain standards within 18 months of its 18 September 2025 issuance, addressing plan sufficiency and how the standards apply to Protected Cyber Assets. Expect auditors to ask sufficiency questions sooner.

Does CIP-013 apply to low impact BES Cyber Systems?

CIP-013-2 applies to high and medium impact BES Cyber Systems and their associated EACMS and PACS. Low impact assets have vendor electronic remote access controls under CIP-003-9 Attachment 1 Section 6, which NERC's implementation plan lists as effective 1 April 2026.

What should a utility do if a vendor provides no hash or signature?

CIP-010 Part 1.6 applies when the method is available from the software source. Record that no method was available in the change ticket, flag the vendor under your Part 1.2.5 process, and raise it at renewal or transition.

Are in-house scripts and integrations in scope?

If they run on or are part of a BES Cyber System, EACMS or PACS, they belong in the baseline and the change process. Even where they are not in scope, their open source dependencies carry the same risks, and they are the software you can fix fastest yourself.

Can a supply chain tool run in an isolated control center network?

Some can. Safeguard's air-gapped deployment runs inside your perimeter with signed snapshot bundles and no outbound calls from inside, and its local runner sends only SBOMs and findings over outbound HTTPS where a connection is allowed. Assess any tool as a vendor under your CIP-013 plan.

Everything above helps you see and verify what you run. The block below covers the next step for the code and containers you build: getting known vulnerable components out quickly, even when an upstream fix is slow.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. At a utility, this is the route for repositories that hold control center integrations and cannot be connected to a cloud service, because only the SBOM and findings leave the machine.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies to an in-house outage portal or data integration.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work goes to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny, which keeps an on-call engineer in the loop away from the desk.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NERC CIP-013-2
• NERC CIP-010-4
• NERC CIP-007-6
• NERC CIP-005-7
• NERC CIP-003-9
• NERC CIP-003-11 Implementation Plan
• FERC Order No. 912 (Federal Register)
• FERC Order No. 907
• CISA advisory AA24-038A
• CISA alert on XZ Utils, CVE-2024-3094
• CERT Polska incident report page
• CERT Polska report (PDF)
• DOE Supply Chain Cybersecurity Principles
• NIST SP 800-161 Rev. 1
• CISA 2026 SBOM Minimum Elements bulletin
• Safeguard docs, NERC CIP framework
• Safeguard docs, Generate SBOM
• Safeguard docs, Local Runner
• Safeguard docs, CLI usage
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, TPRM Vendor Management
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Policies and Gates
• Safeguard docs, GitHub Actions
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, Air-Gapped Deployment

To try it on your own code, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.