Welcome back to our Decoding NERC CIP blog series, part of Foxguard’s ongoing Decoding NERC CIP Podcast.
This post serves as the first installment accompanying Episode 3: “Bridging Patch Management and Vulnerability Strategies for NERC CIP.”
Across the earlier posts in this series, we’ve looked at how organizations approach patching in OT environments—from deciding whether to prioritize by asset or by risk, to patch source selection and supply chain verification. What those discussions point to is a practical constraint: in most OT environments, there are simply too many patches to apply them all. Teams have to decide which ones are worth acting on, which are relevant to their systems, and which can be deferred without introducing meaningful risk.
That reality raises an important question for organizations operating under NERC CIP requirements. When CIP-007 Requirement R2 was developed, the expectation was that entities would track, evaluate, and apply every applicable patch. Today, however, most organizations are working through far more vulnerabilities and patches than can be addressed within limited maintenance windows and operational constraints.
So how can Responsible Entities adopt a more risk-based approach to vulnerability management while still meeting the expectations of CIP-007? To answer that, it’s worth starting with how patch prioritization is already approached in OT environments.
Patch prioritization in OT environments
When CIP-007 Requirement R2 was developed in 2011, the expectation was that organizations would apply every security patch released by the vendor of a product used within the entity’s Electronic Security Perimeter (ESP). At the time, this requirement was not considered burdensome.
Today, however, most organizations recognize that patching everything is rarely achievable in practice. OT environments receive a constant stream of security updates, and patching often requires testing windows, planned outages, and coordination across operational teams. As a result, organizations increasingly prioritize remediation efforts based on the risk mitigated by each patch.
In OT environments, patch prioritization is typically approached in two ways: by the risk mitigated by the vulnerabilities addressed in the patch, or by the criticality of the affected asset. When prioritizing by vulnerability risk, many organizations rely on the CVSS score as a proxy for severity, applying patches that address higher-severity vulnerabilities first.
Prioritizing by affected asset takes a different approach. Organizations develop a methodology for determining the criticality of different systems and apply patches first to assets whose compromise would have the greatest operational impact.
Regardless of which prioritization approach is used, OT teams must also account for operational realities. Some assets cannot be patched until a planned outage occurs, and vulnerabilities that are easily exploitable in IT environments may not always be exploitable in OT devices due to architectural differences and network protections.
Why prioritization matters in practice
Even with prioritization strategies in place, it’s important to understand why prioritization is necessary in the first place.
Whether patch application is prioritized by asset or by risk mitigated, the most important reason for prioritization is that most vulnerabilities are unlikely to be exploited in real-world attacks.
The Exploit Prediction Scoring System (EPSS), maintained by THE Forum of Incident Response and Security Teams (FIRST), indicates that only around 5% of published vulnerabilities are ever exploited in the wild. This estimate is based on aggregated industry data from studies published between 2018 and 2022, with reported exploitation rates ranging from under 2% to roughly 5.7% of all CVEs.
Many organizations therefore establish a threshold for remediation. Vulnerabilities with a CVSS score below a defined level—for example 5.0 or 7.0—may not require immediate patching, provided the policy is applied consistently, and exceptions are documented.
An organization operating an OT environment must also account for two additional realities:
- Some assets cannot be patched until a planned outage occurs.
- Not every vulnerability is realistically exploitable in OT environments, due to architecture, segmentation, and network protections.
These factors reinforce that prioritization in OT is not simply a matter of ranking vulnerabilities by score, but of understanding how those vulnerabilities translate into real operational risk. A vulnerability that appears critical on paper may pose little immediate risk in a segmented OT environment, while a lower-scoring issue on a critical asset may require urgent attention.
This is why effective vulnerability management requires both a structured methodology and informed judgment. Organizations must balance severity, exploitability, and asset context to ensure that limited patching windows are used to reduce the greatest amount of risk. This becomes even more important when those prioritization decisions must align with CIP-007 requirements.
NERC CIP-007-6 R2
NERC CIP-007-6 Requirement R2 is the CIP patch management requirement. It has four Requirement Parts:
- Part 2.1 requires “A patch management process for tracking, evaluating, and installing cyber security patches for applicable Cyber Assets. The tracking portion shall include the identification of a source or sources that the Responsible Entity tracks for the release of cyber security patches for applicable Cyber Assets that are updateable and for which a patching source exists.” Note the following:
- The first sentence requires a “process” for “tracking, evaluating, and installing cyber security patches…” These three steps correspond roughly with Requirement Parts 2.1, 2.2, and 2.3.
- The second sentence emphasizes the importance of the “patch source”. During enforcement of versions 1-3 of the CIP standards (roughly from 2009 until 2016), there was often confusion about whether a NERC entity should for example patch their EMS system whenever the O/S vendor (e.g., Microsoft) released a patch or wait for the EMS vendor to approve an O/S patch. That problem was resolved when CIP-007-5 Requirement 2 R2.1 (which came into effect on July 1, 2016, along with the other ‘CIP version 5’ standards) required the entity to designate a patch source for every software product in scope (as discussed in our earlier post, Choose Your Patch Source(s) Carefully!.) Note that the patch source does not need to be a software vendor; it can also be a third-party service provider like Foxguard.
- Part 2.2 requires the NERC entity to “At least once every 35 calendar days, evaluate security patches for applicability that have been released since the last evaluation from the source or sources identified in Part 2.1.” This is a very important step, since there are many reasons why a patch that appears to apply to a software product used by a NERC entity might not need to be applied, and in fact might harm the asset if it were applied.
However, you may notice there is no mention of what we discussed earlier: the need to prioritize application of patches according to the degree of risk they mitigate, and to ignore patches that do not mitigate a minimum level of risk. Again, this is probably because, when this requirement was drafted more than a decade ago, there were far fewer CVEs than there are today. Patch prioritization was not an important concern then, as it is today.
- Part 2.3 reads:
For applicable patches identified in Part 2.2, within 35 calendar days of the evaluation completion, take one of the following actions:
- Apply the applicable patches; or
- Create a dated mitigation plan; or
- Revise an existing mitigation plan. Mitigation plans shall include the Responsible Entity’s planned actions to mitigate the vulnerabilities addressed by each security patch and a timeframe to complete these mitigations.
It is well understood in OT that very often it is impossible to apply a patch when it’s released. In some cases, that is because an outage is required. In other cases, it is because of the need to test security controls in compliance with CIP-010-4 Requirement R1 Part 1.4 or Part 1.5.
Note that the mitigation plan does not need to focus just on applying a patch when it’s safe to do so. Rather, it needs to focus on mitigating the vulnerabilities that led to the patch being released in the first place. In other words, Requirement Part 2.3 recognizes that the goal to be achieved isn’t simply applying a patch, but mitigating the vulnerabilities that the patch would otherwise address.
However, Part 2.3 never suggests that in some cases, not applying the patch at all – because it only mitigates a small amount of risk – might be the best approach. It also doesn’t suggest that it would be a good idea for the NERC entity to a) determine whether they could ever apply every security patch released by every patch source and b) if not, prioritize patches that mitigate a lot of risk and must be applied, over other patches that mitigate little risk and can be safely ignored. Instead, Part 2.3 clearly assumes the NERC entity will apply every patch provided by any of their designated patch sources.
Applying risk-based prioritization under CIP-007
So, does CIP-007-4 Requirement R2 prohibit prioritizing application of patches based on the degree of risk they mitigate (also known as ‘risk-based patch prioritization’)? No, but it does appear to prevent the NERC entity from choosing not to apply patches provided by one of their patch sources.
Does this mean a NERC entity that wants to perform risk-based vulnerability management is unable to do so if they want to comply with CIP-007-4 R2? Not necessarily. Even though the Responsible Entity cannot choose to ignore some patches, that doesn’t mean the patch source can’t do that.
The patch source could “overlay” a program for risk-based patch prioritization on top of their program to provide patches to NERC entities. If the normal operation of the program discards patches that do not meet a set threshold of severity, those patches will not be provided to customers of the patching program. In other words, even though CIP-007 Requirement R2 doesn’t allow a NERC entity to ignore patches provided by their designated patch provider, there’s nothing that prevents the provider from ignoring patches that mitigate little risk.
Audit expectations and evidence
From an audit perspective, the key question is not just whether patches were applied, but whether the organization can demonstrate a consistent and defensible process for managing them. Under CIP-007 R2, auditors will expect to see evidence that patches are being tracked from defined sources, evaluated for applicability within the required 35-day cycle, and either applied or addressed through documented mitigation plans.
This means that even when organizations adopt a risk-based approach to prioritization, they must be able to clearly demonstrate how decisions were made, when evaluations occurred, and how identified risks were mitigated. In practice, strong documentation and traceability are critical in demonstrating that prioritization decisions are aligned with compliance obligations (a key theme in The Critical Role of Vendor-Approved Patching) not made on an ad hoc basis.
The risk-based patch prioritization process
The process below outlines a practical approach to risk-based patch prioritization, which is explored in more detail later in this series, where we examine how vulnerability severity (CVSS) and exploitability indicators such as KEV and EPSS can help organizations focus on the vulnerabilities that matter most. This process is designed with an end user organization in mind, not a patching provider. We then examine how this process differs when performed by a patch provider.
- Step 1: As discussed in our earlier post, “A Guide to Patching by Asset or Risk,” the organization needs to determine whether it will prioritize patches based on the criticality of the vulnerable asset, the risk mitigated by the patch, or a combination of both (Note: This step will not need to be performed very often, since the policies decided on could well be left in place for one or more years. However, the organization needs to be prepared to change these policies when the need to do so becomes clear.)
- Step 2: Later in the series, we will explore how organizations group patches into two “buckets” based on the CVSS Base Scores of the vulnerability or vulnerabilities fixed by the patch: high and low severity. Patches that fix only low severity vulnerabilities do not need to be applied; they can be removed from consideration. All other patches fall into the high severity bucket. It is up to the organization to determine the dividing line between low and high severity CVSS Base Scores.
- Step 3a: Working just with the high severity bucket, apply any patch that fixes one or more CVEs on the KEV list as soon as possible.
- Step 3b: For the remaining patches in the high-severity bucket (excluding those addressing KEV-listed vulnerabilities) retrieve the EPSS score of each vulnerability that is fixed in each patch, then select the highest score for each patch; that is the “patch EPSS score” (in other words, if a patch fixes two CVEs, one with an EPSS score of 3.1 and the other with a score of 9.5, the patch EPSS score is 9.5). Working only with the high severity bucket, apply patches with the highest patch EPSS scores, followed by those with lower scores.
While the goal will normally be to apply every patch in the high severity bucket, if time does not permit doing that, it is acceptable to stop, then document which patches were not applied. That way, if the opportunity to apply the remaining patches arises later, someone will be able to do that. What is most important is that the patches in the high severity bucket are applied in the order of the exploitability of the CVE or CVEs fixed by each patch, meaning that the maximum amount of risk – given the time available – was mitigated by the patches applied.
The “input” to this set of steps is information about a set of patches available to be applied, as well as information on the CVEs that are fixed by each patch. This information includes the CVSS and EPSS scores for each CVE, as well as whether the CVE is on the KEV list. The “output” is a set of patches that have been selected for application, as well as information (in Step 3b) about the order in which they should be applied.
Note that, even though the above steps seem to describe a process that is taking place in real time, there is no reason why the entire process could not be “run” in software before any patch was applied. In that case, the output would be a set of instructions to apply patch 123 to device ABC, along with the order in which the patches should be applied.
How patch providers can support risk-based prioritization
How will this process change if it is performed by a provider of NERC CIP-007 R2 patching services as an “overlay” to their normal process of choosing patches for distribution?
- Since different customers are likely to have different preferences for the threshold CVSS Base Score that divides patches that fall in the high severity bucket from those in the low severity bucket, it would be good to allow the customer to set whatever threshold value they want.
- If a customer has decided in Step 1 that they have some critical assets that should be treated as higher risk than others, the patching provider may need to have a separate prioritization algorithm for them. This algorithm would use a lower severity threshold than the one used for “non-critical” assets; as a result, some patches that would not be applied to “non-critical” assets would be applied to critical assets. For example, if the threshold for non-critical assets is a CVSS Base Score of 7.0, but the threshold for critical assets is 5.0, then a patch with a 5.5 score would be applied to a critical asset, but not to a non-critical asset.
Taken together, this places more of the decision-making responsibility with the patch provider. By aligning severity thresholds, asset context, and exploitability indicators, providers can help ensure that the patches delivered to customers reflect both the operational realities of OT environments and the compliance requirements of CIP-007.
This approach reduces the burden on internal teams, who would otherwise need to manually evaluate large volumes of patches, while also improving consistency and audit defensibility. Instead of reacting to every available update, organizations can focus their efforts on the patches that meaningfully reduce risk, supported by a clear and consistent prioritization process.
Moving forward together
Risk-based vulnerability management doesn’t change what CIP-007 requires, but it does change how organizations operate within those requirements. In practice, OT teams are not choosing between compliance and prioritization—they are trying to make informed decisions within limited maintenance windows, constrained resources, and systems that cannot always be taken offline.
That reality makes it essential to focus on the vulnerabilities that are most likely to introduce real risk to operations, while still maintaining a clear and auditable process for tracking, evaluation, and mitigation. Prioritization, when applied carefully, allows teams to use the time they have to reduce exposure in a meaningful way, rather than simply working through patch lists in order of release.
Foxguard supports this approach by helping organizations identify which patches are relevant, understand how they apply to specific assets, and maintain the documentation needed to demonstrate compliance. By aligning patch intelligence with asset context and evaluation workflows, teams can reduce manual effort while maintaining consistency in how decisions are made and recorded.
In the next post in this series, we’ll shift focus to CIP-010 R4 and examine how vulnerability management applies to transient cyber assets (TCAs), where devices move between environments and introduce a different set of risks. We’ll look at why these assets require a different approach, how vulnerability management can be applied in practice, and what that means for maintaining compliance across both internal and third-party systems.