This article is part of our ongoing podcast blog series, where we explore the practical challenges and solutions for securing Operational Technology (OT) environments. In our previous posts, we discussed asset identification under NERC CIP standards, the unique patching challenges faced in OT environments, vulnerability tools for simplifying patch management, and the processes at the heart of NERC CIP Compliance (what we call the Virtuous Loop). Today’s issue explores the principles of OT vulnerability management and how NERC CIP patch management can work effectively.
We’ll walk through the challenges of managing vulnerabilities in OT systems, why applying every patch isn’t realistic, and how organizations can prioritize the patches that matter most. We’ll explore the different types of risks vulnerabilities introduce—from data exfiltration to operational disruption and lateral attacks—and outline a practical, step-by-step methodology for applying patches effectively while maintaining reliability and compliance under NERC CIP standards.
The challenge of managing OT Vulnerabilities
This article is the second in our series exploring OT software vulnerability management. In the first post OT Patching Solution Challenges, we noted that within the software security community, the conversation has shifted from “eliminating” all vulnerabilities by applying patches immediately, to “managing” vulnerabilities more strategically. Most organizations now recognize that it’s nearly impossible to dedicate enough resources to completely eliminate their backlog of unpatched software vulnerabilities. This makes structured NERC CIP patch management essential for reducing risks without overloading limited OT resources.
In other words, most medium-to-large organizations realize they don’t have the human resources needed to eliminate all vulnerabilities in the software they rely on. Moreover, even if they did have those resources, they understand that much of the effort required would ultimately be wasted—because only a small percentage of software vulnerabilities will ever pose a real risk to their organization.
The question now becomes, “How can our organization prioritize patching efforts, so we focus on the small number of patches that truly need to be applied, rather than the much larger number that don’t?” Of course, no patch arrives with a label reading “Apply” or “Don’t Apply”.
Foxguard divides OT patch prioritization into three steps. The first is deciding whether to prioritize patches based on a) the criticality of the affected asset, b) the risk mitigated by each patch, or c) a combination of the two approaches.
Prioritizing patches by criticality of the affected asset
When prioritizing by affected asset, an organization needs to assign a “criticality score” to different asset types or even different individual assets. The criteria for assigning these scores should be defined by the organization. For example, in an electric transmission substation, a relay operating a circuit breaker for a low voltage distribution feeder line would likely be considered less critical than a relay operating a 500kV transmission line. The latter would receive a much higher criticality score, even though the physical asset is the same in both cases.
There are many criteria that can be used to determine an asset’s criticality. These criteria can be combined and weighed in different ways. However, it is important not to let individual staff members decide for themselves how criticality is determined; there should be a single measure (or set of measures) for the OT side of the organization.
Criticality can be assessed using a variety of criteria. Some focus on the function an asset performs, while others consider characteristics that make an asset inherently higher or lower risk, regardless of its function.
These criteria can include:
- Whether the device or software is located on a network segment directly connected to the internet.
- How many router hops or firewalls lie between the asset and the internet.
- The effect on the process if the asset were disabled or compromised—for instance, would the plant, pipeline, or assembly line shut down; would personnel need to be evacuated for safety reasons; is there a risk of explosion, fire, or other hazardous events; would an environmental excursion occur, triggering fines or regulatory reporting; would OSHA or other authorities need to be notified; or could patient or public safety be affected (e.g., in a hospital)?
- Whether physical access to the asset is tightly controlled or whether hundreds of people walk by it every day.
- Whether the software is in end-of-life status, meaning vulnerabilities may no longer be patched.
- Whether or not the manufacturer of the device or the developer of the software is known for secure development practices.
- How good the supplier’s customer support team is at responding to reports of problems, and how long on average it takes them to diagnose a problem and propose remediation.
- Whether easy-to-use online documentation is available.
- Whether staff members who work with the device or software are well trained in its operations, as well as what it takes to secure it.
- Whether spare parts are still available if the device is out of support.
If the patching team has agreed to prioritize patch application based on the affected asset, they will schedule their work each day or week by addressing vulnerabilities in the most critical assets first, before moving on to those in less critical ones.i
One important consideration in OT environments is that a vulnerability may not actually be exploitable on a given device, even if it is easily exploitable in an IT environment. For this reason, it’s wise to confirm with the manufacturer whether a vulnerability can be exploited on a specific device or software, before spending significant time patching a supposedly critical vulnerability that poses no real risk.
Prioritizing patches by risk mitigated
While most people find it easy to understand the concept of asset criticality—and therefore to see how patches are prioritized on that basis—many find it is harder to grasp prioritization based on the degree of risk mitigated by a patch. This is probably because it requires understanding several underlying “component” concepts:
- A security patch fixes one or more vulnerabilities found in a software product.
- Every vulnerability introduces some degree of risk to the product. While it is not usually possible to measure risk in an absolute sense, it is possible to compare degrees of risk posed by different vulnerabilities.
- Risk is a combination of likelihood and impact. Comparing risk across software products therefore requires assessing both the likelihood that a risk will be realized and the impact if it is realized.
- It is up to the organization to decide how to assess the likelihood and impact of each vulnerability, as well as to define the “formula” for total risk. This formula combines the scores for likelihood and impact into a single risk score, based on an agreed-upon weighting.
- The total risk mitigated by a patch is equal to the sum of the risk scores of all vulnerabilities it addresses. If a patch only fixes one vulnerability, its total risk score is the same as the risk score mitigated by that patch.
- Prioritizing a group of patches requires comparing the total risk mitigated by each one. All else being equal, the goal of patch prioritization is to reduce as much vulnerability risk as possible within the limits of available staff time and budget—by focusing first on the patches that mitigate the greatest risk.
For most organizations, item C will prove to be the most challenging, since it requires scoring likelihood and impact for individual software vulnerabilities. For a broader look at OT-specific patching challenges and prioritization trade-offs, see our earlier post in this series: OT Patching Solution Challenges.
Utilizing both approaches
It is certainly possible that an OT organization will decide to prioritize patches based on asset criticality in some cases, and by risk mitigated in others. For example, there may be certain assets that are hugely critical; patching these could take precedence over others. For all other assets, however, the organization might choose to prioritize patches based on the risk each patch mitigates, without factoring in the criticality of individual assets.
Moving forward together
Deciding which patches to address first is just the start of managing vulnerabilities in OT. By focusing on asset criticality and the risk each patch mitigates, OT teams strengthen their NERC CIP patch management strategy, using resources wisely while reducing disruptions. This approach doesn’t remove the need for careful judgment. Each patch still needs to be evaluated in context, and sometimes what looks urgent on paper may not be a real risk on a particular device.
Foxguard’s Cyberwatch and Patchintel solutions bring clarity to this process, helping organizations identify which patches reduce the most risk and apply them efficiently while maintaining NERC CIP compliance. By combining actionable insights, real-time visibility, and professional guidance, your team can focus on what matters most, reduce exposure, and maintain operational reliability.
In the next post of this series, we’ll dive into patch source management: why verifying the origin of updates matters, the different types of sources you might encounter, the risks of unverified patches, and how to document everything for CIP-007 R2 compliance. Getting this right ensures your patching program stays both safe and auditable.
Need help patching your OT environment? Contact us today to learn how Foxguard can simplify your patching needs.