This blog is part of our ongoing series exploring how NERC CIP requirements intersect with the real-world challenges of securing Operational Technology (OT) environments. So far, the series has examined why accurate asset identification is the foundation of compliance, how OT patching introduces unique operational risks, and why patch source trust and prioritization matter just as much as patch deployment itself.
Together, those discussions illustrate how patch management is not a single activity, but a connected process that spans accurate asset identification, vulnerability intelligence, trusted patch sources, sandbox testing, documentation, and compliance alignment. These topics build on the earlier posts in this series—Asset Identification and OT Patching Solution Challenges—showing how foundational processes and risk awareness set the stage for effective supply chain management.
In this post, we shift focus to one of the most frequently misunderstood areas of that process—the patch supply chain. Using a question-and-answer format, we address how Responsible Entities can verify patch authenticity, align patching practices with CIP-013 supply chain risk management requirements, and demonstrate compliance with CIP-010 when verification methods are limited or inconsistent.
Best Practices for NERC CIP Patch Verification
What if a software vendor or device manufacturer does not provide a signature or hash for a patch or other update?
How can a Responsible Entity verify integrity and authenticity?
This situation occurs frequently, particularly in OT environments. One way to gain reasonable assurance that a patch is authentic and has not been tampered with in transit is to always download patches from a verified provider source. This includes bookmarking or otherwise preserving known, trusted URLs—whether they are the vendor’s official site or a managed patch aggregation service—rather than typing the URLs by hand or clicking search-engine results.
If the patch source is a managed service (often referred to as a patch aggregator), the Responsible Entity should understand how the service verifies its sources. Where possible, source validation practices should be documented and included in contractual language or service-level agreements (SLAs).
Examples of OT-focused patch aggregation tools include services such as Foxguard Patchintel, which centralizes vendor patch information, tracks OT-relevant updates, and provides visibility into patch availability across diverse environments.
Patches should also be tested thoroughly in a sandbox or test environment, where anomalous behavior that might indicate compromise can be observed. In practice, this testing should occur regardless of whether the vendor provides a signature or a hash value. For organizations that want to maintain direct control over deployment while improving consistency and auditability, controlled patch deployment tools like Foxguard Deploy can help ensure patches are installed in a repeatable manner and aligned with approved change workflows.
It is important to keep in mind the lessons learned from supply chain attacks such as SolarWinds: malware can be delivered through trusted, verified patches when upstream controls fail. This risk is explored in more detail in our previous blog post in the series, titled Choose your patch source(s) carefully!. Verification helps establish authenticity and integrity, but it does not guarantee that a patch is safe.
How can patch supply chain security align with a CIP-013 supply chain risk management plan?
Patch management is an important component of supply chain cyber security risk management. As a result, a NERC entity’s CIP-007 R2 patch management plan can reasonably be viewed as a subset of its CIP-013 supply chain cyber security risk management plan.
The two plans should be aligned in several ways.
- Risk identification (CIP-013-2 R1)
CIP-013-2 Requirement R1 requires the Responsible Entity to identify risks to the BES associated with “procuring and installing vendor equipment and software”. These risks should include patch-related risks, such as:
- Applying a patch without verifying identity, integrity, or both.
- A vendor’s software build environment being compromised, resulting in malware embedded in a signed patch (this is what happened in the SolarWinds attacks, described in our previous post, Choose your patch source(s) carefully!).
- A supplier failing to release a patch for a severe vulnerability before exploitation occurs.
- A vendor never developing a patch for a significant vulnerability.
- Failure to implement compensating controls for vulnerabilities that cannot be patched.
- Risk assessment (CIP-013-2 R1.1)
Requirement R1.1 requires the Responsible Entity to assess risks to the BES from “procuring and installing vendor equipment and software”. The CIP-013 plan should describe how questionnaires or other evaluation methods are used to determine whether vendors have mitigated identified risks (listed above).
Vendor questionnaires should be focused and intentional. Questions should only address risks the organization considers worth mitigating, and responses should be used to drive decisions or follow-up actions.
- Verification of software integrity and authenticity (CIP-013-2 R1.2.5)
Requirement R1.2.5 requires “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System and their associated EACMS and PACS.”
Responsible Entities should document how they verify signatures and hash values when provided, as well as the steps taken to mitigate risk when vendors do not provide signatures or hashes.
- Risk mitigation and follow-through (CIP-013-2 R2)
CIP-013-2 Requirement R2 requires the Responsible Entity to “…implement its supply chain cyber security risk management plan(s) specified in Requirement R1.” Identifying and assessing vendor risk is not sufficient; Responsible Entities must document the steps taken to mitigate identified risks.
How do we prove verification of patch identity and integrity for CIP-010 R1.6?
Although it is strongly recommended to include identity and integrity verification in a NERC entity’s CIP-007 R2 patch management plan, it is not explicitly required. However, verification is required under CIP-010 Requirement R1 Part 1.6.
This requirement applies to all software added to systems in scope for R1 and states that, prior to a baseline change—and when the method to do so is available from the software source—the Responsible 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.
The phrase “when the method to do so is available” makes it clear that Responsible Entities are not strictly required to take alternative verification steps when vendors do not provide signatures or hashes. However, as discussed earlier in the series, it is highly recommended to implement additional controls.
From an audit perspective, there are two primary ways to provide evidence of compliance. The first is shown in the example in the Measures section, which reads:
“An example of evidence may include, but is not limited to, a change request record that demonstrates the verification of identity of the software source and integrity of the software was performed prior to the baseline change or a process which documents the mechanisms in place that would automatically ensure the identity of the software source and integrity of the software.”
This approach does not require documentation of every individual instance of verification. Instead, it allows the Responsible Entity to demonstrate compliance using either of the following approaches:
a) a change request record that shows verification of identity and integrity before the software (or patch) was installed, or
b) documented mechanisms that automatically ensure verification of the software source and software integrity.
The second approach is to provide evidence similar to what would be required if this requirement were part of CIP-007 R2. This typically includes screenshots or other records showing that identity and integrity were verified for each patch prior to installation, consistent with CIP-007 Requirement R2 Part 2.2.
The specific evidence retained will depend on how the supplier publishes hash values. Some suppliers include hashes in release notes, while others publish them on the same webpage where the patch is downloaded. In either case, Responsible Entities should retain the release notes or screenshots, along with documentation showing that the hash value was verified.
If no hash is provided, a screenshot of the download site should be retained. The URL should match the documented update source, and the Responsible Entity should be prepared to demonstrate how the legitimacy of the site was verified. If a patch aggregation service is used, documentation describing how the service provider verifies the legitimacy of its download sources and files should also be retained.
Moving forward together
Understanding and documenting patch supply chains is a critical step toward NERC CIP compliance, but it does not, by itself, ensure complete security. Responsible Entities need to pair patch verification with broader supply chain risk management, clear asset visibility, and ongoing vulnerability monitoring to maintain a patch management program that is repeatable, auditable, and resilient.
Even when vendors provide digital signatures or hash values, organizations still face practical questions. How do you verify identity when standard methods aren’t available? How do you evaluate the reliability of patch aggregation services? And how do you ensure that patch management aligns with CIP‑013 and CIP‑010 requirements? Addressing these demands successfully requires teams to work together, follow clear procedures, and validate every step.
Tools and services that support patch intelligence, controlled deployment, and ongoing monitoring can help organizations operationalize these practices, whether implemented directly by internal teams or supported through managed services.
In the next installment of the Decoding NERC CIP series, we will focus on vendor-approved patching. We will explore why OT systems require validated patches, how patch approval processes vary among OEMs, and practical strategies to ensure that every patch applied is traceable, consistent, and compliant.
Taken together, these discussions move the series from verifying patch authenticity to ensuring that every patch applied is approved, safe, and aligned with operational and regulatory expectations.