Supply chain security for energy utilities in 2026 is governed by NERC CIP-013-2, enforceable since 1 October 2022, and reinforced by CIP-010-4's software integrity and authenticity requirements. The 2024 FERC approval of CIP-015-1 (internal network security monitoring) extends the assumed-breach model to the control systems operating the bulk electric system (BES) in the United States, with phased compliance through 2028. Together with CISA's Shields Up posture, the DOE's 100-day plans for electric, pipelines, and water, and the forthcoming CIP-003 physical security updates, the message to reliability coordinators, transmission operators, and generation owners is consistent: your software supply chain is in scope, and auditors will ask for evidence.
This post covers what NERC CIP requires for software supply chain in 2026, how SBOM workflows fit into CIP-013 procurement and CIP-010 change management, and what registered entities typically get wrong.
What does NERC CIP-013-2 actually require?
CIP-013-2 applies to high- and medium-impact BES Cyber Systems and covers supply chain risk management. Requirement R1 obligates responsible entities to develop a documented supply chain cybersecurity risk management plan addressing: (a) procurement, (b) installation, and (c) transitions between vendors, for BES Cyber Systems and their associated EACMS, PACS, and PCA.
R1.2 specifies six procurement concerns:
- Notification of vendor-identified security incidents
- Coordinated response to incidents
- Notification when vendor remote access is no longer needed
- Disclosure of known vulnerabilities
- Software integrity and authenticity verification
- Vendor remote access controls (interactive and system-to-system)
R2 requires implementation of the plan. R3 requires CIP Senior Manager review every 15 calendar months. Auditors look for executed contracts and procurement records that reflect R1.2 concerns, SBOM or equivalent vulnerability disclosure evidence, and integrity verification records on software installations.
How does CIP-010-4 software integrity and authenticity tie in?
CIP-010-4 R1.6 (which became enforceable on 1 October 2020 and remains the governing requirement) specifies that prior to installing software on BES Cyber Systems, responsible entities must verify the identity of the software source and the integrity of the software. In practice that means cryptographic signature verification, hash matching against vendor-published values, or equivalent methods.
The operational implication is that you need a trusted channel for receiving software integrity metadata from your vendor and a documented process for verifying it before the software lands in a Bulk Electric System Cyber Asset (BCA). An SBOM signed by the vendor is increasingly the vehicle for transmitting that metadata along with component-level detail.
What does CIP-015-1 introduce in 2026?
CIP-015-1, approved by FERC in Order No. 898 on 27 June 2024, requires internal network security monitoring (INSM) for high-impact BES Cyber Systems at control centers and medium-impact BES Cyber Systems with external routable connectivity. The rule phases in over 36 months from the effective date for high-impact applicable systems and 60 months for medium-impact, putting compliance dates squarely in 2027-2029 but demanding design work in 2026.
INSM is an assumed-breach control. It exists because supply chain attacks like SolarWinds bypass perimeter defenses. For energy utilities this means east-west traffic in the OT environment must be monitored, anomalies detected, and data retained for forensic use. SBOM data feeds into INSM baselining -- if you know what software is running, you know what network behavior is legitimate and what is not.
Which supply chain events drove these rules?
The 2020 SolarWinds compromise reached multiple electric utilities using Orion for IT network management. The May 2021 Colonial Pipeline ransomware incident, while not a classic software supply chain attack, drove the TSA Security Directives and clarified the national-security framing of energy sector cyber. The 2024 CDK Global ransomware incident affected dealer management systems but reinforced the concentration risk lesson for energy service providers. The 2024 XZ Utils backdoor in OpenSSH -- a near-miss -- is still cited by NERC auditors when asking utilities how their SBOM program would have detected the malicious component.
How do you operationalize CIP-013 R1.2 in 2026?
The plan needs to be a living operational document, not a static policy. Practical elements:
- Vendor risk tiering based on impact rating of systems they touch (high, medium, low BES Cyber Systems) and the nature of the service.
- Pre-procurement questionnaires that cover the six R1.2 concerns plus SBOM delivery, SLSA-level build provenance, and coordinated vulnerability disclosure processes.
- Contract language that obligates vendors to notify you of incidents within contractual windows (commonly 24-72 hours), provide SBOMs for each release, disclose known vulnerabilities, and support integrity verification.
- Onboarding workflow that ingests the vendor's SBOM, cross-references vulnerabilities, and records the integrity verification for CIP-010 R1.6.
- Ongoing monitoring that re-runs vulnerability correlation on stored SBOMs as new CVEs drop and routes findings to the CIP Senior Manager for risk decisions.
- Transition and offboarding procedures that handle vendor replacements, including how you continue to support fielded software when a vendor exits.
Auditors in 2026 routinely ask for sample procurements and trace them end-to-end through this workflow.
What about low-impact BES Cyber Systems?
CIP-003-8 and the proposed CIP-003-9 address low-impact system protections. The 2024 FERC directives (Order No. 887 on INSM and subsequent orders) ask NERC to consider extending certain protections to low-impact assets. While low-impact is not currently subject to CIP-013-2 directly, responsible entities increasingly apply consistent supply chain controls across impact tiers because maintaining separate processes is operationally expensive.
How do SBOMs interact with OT-specific constraints?
OT environments have realities that commercial IT does not:
- Air-gapped networks: SBOM correlation against vulnerability feeds may need to happen on a management network with scheduled data diode transfers.
- Extended lifecycles: relay, RTU, and SCADA firmware can have 15-25 year operating life. SBOMs must be retained and queryable over that horizon.
- Limited patchability: many OT components cannot be patched in-place. Vulnerability findings feed compensating control decisions rather than automatic patching.
- Vendor constraints: some OEMs still resist SBOM delivery citing IP concerns. The E-ISAC and NATF (North American Transmission Forum) have published model contract language and vendor engagement guidance that helps close these gaps.
- Firmware binaries: SBOM generation from firmware blobs requires binary analysis, not source-code scanning. Programmable logic devices, IEDs, and communication processors all need this capability.
What is the role of E-ISAC and NATF in 2026?
The Electricity Information Sharing and Analysis Center operates Cybersecurity Risk Information Sharing Program (CRISP) feeds that utilities integrate into their vulnerability management. NATF publishes supply chain security criteria and an Industry Organizations Team questionnaire that many vendors complete once and reuse across utility customers. In 2026, registered entities are expected to reference E-ISAC and NATF materials in their CIP-013 plans and to demonstrate active participation where applicable.
What evidence do auditors expect?
For a CIP-013-2 audit:
- Your current supply chain risk management plan with CIP Senior Manager approval.
- Procurement records showing R1.2 concerns were addressed.
- Vendor SBOMs or equivalent vulnerability disclosure artifacts.
- Integrity verification records for installed software (CIP-010-4 R1.6).
- Incident notification logs showing vendor-originated incidents were handled per plan.
- Evidence of 15-calendar-month plan review.
For CIP-015-1, expect auditors to ask how your INSM design leverages SBOM-informed behavioral baselines.
How Safeguard.sh Helps
Safeguard.sh is deployed by energy utilities and generation owners to support CIP-013-2, CIP-010-4, and the CIP-015-1 rollout in 2026. The platform generates and ingests SBOMs in SPDX and CycloneDX for both IT systems and OT-adjacent software, supports firmware binary analysis for IEDs and RTUs, and maintains component inventories that survive the 20-year OT lifecycle.
For CIP-013 procurement, Safeguard.sh captures vendor SBOM delivery, automates the R1.2 vulnerability disclosure workflow, and produces audit evidence packs that map directly to R1 and R2. For CIP-010 software integrity verification, the platform records signature and hash validation events alongside the SBOM metadata. For CIP-015 INSM design, Safeguard.sh provides the software inventory baseline that anomaly detection systems consume.
Safeguard.sh operates across the IT/OT boundary with air-gap-aware deployment options and diode-friendly data export so utilities running strict jurisdictional controls can still benefit from continuous vulnerability correlation. For compliance teams managing CIP evidence across dozens of substations, control centers, and generation sites, Safeguard.sh consolidates the supply chain evidence base into a single platform that regional entity auditors recognize.