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 and the unique patching challenges faced in OT environments. Now, we turn to a critical question: How can tools and services simplify the daunting task of OT vulnerability and patch management?
From creating accurate software inventories to evaluating patch applicability, we’ll break down the key tasks involved and highlight how the right tools can make a complex process more manageable. Whether you’re managing a NERC CIP-compliant environment or a general OT network, this guide will help you navigate the tools that reduce risk without overwhelming your team.
For more insights, listen to our Decoding NERC CIP & OT Security podcast: Episode One: Key Goals of Patch & Vulnerability Management.
The Complexity of OT Patch Management
OT cybersecurity patching is a complex process. The first question that comes up about any complex task is, “How can I get help with this?” In this post, we have broken the overall OT patching process into its component tasks and asked, “What types of tools and/or professional services are available to help readers accomplish this task?”
Tasks of Patch Management
The discussion below is organized around the tasks in the OT patching process, listed in boldface below. Tasks numbered with a single integer (e.g., “Task 1”) apply to any OT environment, including an environment subject to compliance with the mandatory NERC CIP1 Reliability Standards for the North American Bulk Electric System (BES). Tasks numbered with an integer and “_CIP” (e.g., “Task 1_CIP”) apply only to a NERC CIP high or medium impact environment that must comply with CIP-007 Requirement R2, Patch Management.
Note: Two tools that are commonly used in patching IT systems are not normally used for patching OT systems. These are:
- Vulnerability scanning tools. While these are quite safe to use in IT environments, in OT environments they often pose a danger, since many OT devices may be disrupted if subject to a vulnerability scan. For that reason, discovery of vulnerabilities in software products installed in the OT environment is usually accomplished by looking up OT products in a vulnerability database like the National Vulnerability Database (NVD).
- Patch deployment tools. In IT environments, patches are often deployed to hundreds of systems at a time. This is possible because the systems are almost identically configured; it is not likely that any system will be damaged through this method of deployment. However, in OT environments the systems are often quite different from each other. Moreover, they can be connected to each other in many ways. This leads to the possibility that deploying a patch to a large group of systems simultaneously will lead to damage to data or even physical devices, because of the inherent diversity of OT environments.
Tasks of OT Patch Management in Non-CIP and CIP environments
Task 1. Create or update software and firmware inventory.
Patch management is very difficult without a complete and up-to-date inventory of software and firmware that is installed in your environment. The information for each device needs to include at a minimum the name, version string, and publisher2 (or “developer”) of each product. Since all three of these can vary widely in different contexts, it is important that your inventory record the exact information for the product as it is installed in your environment.
For example, the author’s list of installed software on his laptop includes “Microsoft 365 Copilot”. This product has been known previously as “Microsoft Office”, “Microsoft Office 365”, and other names. Were the author creating a software inventory for his laptop, it would be a mistake for him to list any name for the product other than “Microsoft 365 Copilot”. The same consideration applies to the publisher name, “Microsoft Corporation”. Of course, that company is called many other names, e.g. “Microsoft”, “Microsoft, Inc.”, etc. But it is important to record the exact publisher name listed in the software.
There are other items that should be included in the inventory, if they are available. These include:
- Licensing details.
- Support information (e.g., website, email address or phone number).
- Device on which the software is installed, including physical location and IP address.
- Maintenance contract (whether the individual or organization has a maintenance contract for the software, and if so how to find information about the contract).
- Machine-readable identifier for the software product. Since this is required to look up the software in a vulnerability database, it is important to have this. There are only two widely used machine-readable software identifiers. One is “CPE name”. This identifier was formerly always included in “CVE records” (i.e., vulnerability records) found in the National Vulnerability Database (NVD). However, only about half of new CVE records issued since February 2024 contain a CPE name. Because of this, currently the only way to be sure to learn about recent vulnerabilities for products in the NVD is to manually search on the product name and version string.3
- The other widely used machine readable software identifier is purl, which stands for “Product URL”. It is currently used mostly to identify open source products that are distributed through a “package manger” like Maven Central or PyPI. As long as the user knows the package manager and the name and version string of the product in that package manager, they can create the single globally unique purl identifier for that package; it should always match a purl for the same product in a vulnerability database. Purl is heavily used to locate vulnerabilities listed in major open source vulnerability databases including OSS Index and OSV.4
There are various software tools that can create and update a software inventory, often by automatic discovery of the software products. For an OT environment, it is important to obtain a tool that is intended for use with OT. Several tools combine OT asset inventory with other OT-specific functions like vulnerability management, patch management and compliance management. Some of these tools also identify intelligent devices that are installed in the OT environment, including in most cases firmware versions installed in those devices. One of those tools is Foxguard’s Cyberwatch.
One necessary feature of OT asset inventory software is the ability to discover information on installed software and firmware products using either “agent-based” or “agentless” methods. Other things being equal, agent-based methods are better, since they can discover more information than agentless methods. However, many OT systems will not tolerate installation of a software agent. For those systems, agentless methods (which obtain information on the product by “snooping” on network traffic) are the only automated discovery option.
Task 1. Create or update software and firmware inventory
Task 1_CIP. It is safe to say that every intelligent device identified by an OT asset discovery tool will meet the NERC definition of Cyber Asset; that is, it is a “programmable electronic device”. It is also possible that the tool will miss one or more devices, including “air gapped” devices, devices on separate network segments, etc. Since failure to identify one or more Cyber Assets installed in the OT environment could result in a finding of Potential Non-compliance (PNC) during an audit, it is important to make sure all intelligent devices are included in the inventory, even if some need to be added manually.
Next, every Cyber Asset in the OT environment needs to be evaluated to determine whether it meets the definition of BES Cyber Asset (BCA); while that definition includes multiple criteria, the most important criterion for a BCA is that the Cyber Asset’s loss or compromise could “adversely impact” the Bulk Electric System (BES) within 15 minutes. Since the term “adversely impact” is not defined in the NERC Glossary, the decision whether a Cyber Asset is a BES Cyber Asset needs to be made by someone very familiar with the NERC entity’s operations and their potential impact on the power grid.
Once BCAs are identified, each BCA must be incorporated into one or more BES Cyber Systems (BCS). These are defined as “One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.” There are no restrictions on how a NERC entity groups BCAs into BCS: Each single BCA can be declared a single BCS, but hundreds of BCAs, located in widely dispersed facilities, can also be designated a single BCS.
Along with identifying Cyber Assets, BES Cyber Assets and BES Cyber Systems, the NERC entity needs to identify Protected Cyber Assets (PCA), Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). For more information on these asset types, see Foxguard’s blog post “NERC CIP Asset Identification”5
Note that, beyond the initial identification of Cyber Assets, none of the above CIP “sub-tasks” can be automated. They all require the judgment of a person who is knowledgeable about compliance with the NERC CIP standards, whether an employee of the NERC entity or a contractor.
Task 2. Identify and securely download new patches for OT software and firmware products.
Once a complete software and hardware inventory has been generated for the OT environment, the organization needs to contact all software and hardware suppliers to make sure it will quickly be informed of any new security patch. Since some suppliers can’t be counted on to send a notification of every new patch, it is up to the organization – or a patch management tool they utilize – to check regularly for new patches.
Whenever a new software or firmware patch is identified for a software or hardware product in the OT environment, the organization needs to download it and verify its authenticity and integrity; this is usually done by verifying the digital signature. This process can be fully automated by a patch management tool.
The next step is to determine whether the patch is applicable to the software or firmware product installed. Determining applicability of a patch requires reading the text of the patch report and verifying information. This includes verifying information like the following:
- The product name in the patch report matches the name of the installed product (and if they don’t match, there is a good explanation for why that is the case).
- The version string in the report (i.e., the string of characters that constitutes the “version number”, which may sometimes include letters) matches the version string of the installed product.
- The supplier name in the patch report matches the name on the installed product. There are a host of reasons why the two might not match, and in most cases the lack of an exact match won’t matter. What does matter is that the product name and version string in the patch report match those in the installed product, and that the digital signature (and hash value, if it was also provided) of the downloaded patch was verified.
- Other requirements for the patch to be applicable are met. These could include the operating system version, presence or absence of “add-ons” to the software, etc. If just one of these requirements is not met, it is important to discuss with the supplier whether the patch should still be applied.
There is a wide range of information available to help an organization determine whether a patch is applicable to an OT product that they utilize, as well as risks that might come with its application. This information includes vendor patch release notes and security bulletins. Some service providers gather this information together and make it available to their customers in both text and binary form, so that it can be utilized by third party asset management tools that their customers may use to determine patch applicability.
If the patch is applicable to the installed product, the next question to ask is whether the patch is in fact needed. For example, is there a mitigation already in place – or one that might easily be put in place, like a firewall rule – that obviates the need to apply this patch? Because of the risks that need to be considered before installing a patch on an OT device, it is often better to rely on a non-patch mitigation measure, if that is available and almost as effective as the patch.
A final consideration before approving a patch for an IT device is what the device’s dependencies are. In other words, if the device is brought down to apply the patch, what other devices will be affected when this happens? Of course, even if other devices are affected, it is still possible to apply the patch, as long as appropriate measures are taken to ensure the other devices remain available. See the Foxguard blog post “OT Patching Solution Challenges.”
In this task, the first two paragraphs can be automated using multiple patch management tools. However, the remainder of this task cannot be fully automated, although professional services are available to accomplish its purpose.
Task 2. Identify and securely download new patches
Task 2_CIP. CIP-007 Requirement R2 Part 2.1 requires the NERC entity to identify 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.” In other words, the NERC entity needs to identify a patching source for every software and firmware product installed in their Electronic Security Perimeter (ESP).
Foxguard is a one-stop patching source for a wide variety of OT products, including:
- Application software
- Hardware drivers
- Network equipment
- OEM vendor-approved patches
- OT equipment firmware and application software
- Operating systems
- Security appliances
- System BIOS / UEFI support
- System controller and component firmware
CIP-007 Requirement R2 Part 2.2 requires the 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.” The considerations for evaluating patches for applicability are almost the same as those discussed in the previous section, with the exception of the requirement to do this every 35 days.
As with Task 2, identifying and downloading new security patches and confirming their integrity and authenticity by verifying the digital signature can be automated with a patch management tool. However, the remainder of this task requires human intervention.
Task 3. Apply the patch or develop a mitigation plan.
Once the organization has decided that a patch is applicable to their system, they need either to apply it or – if the patch can’t be applied immediately or even at all – develop a plan to mitigate the vulnerabilities that are addressed by the patch.
This task cannot be fully automated, but professional services are available to help with this if needed, especially with developing mitigation plans.
Task 3_CIP. CIP-007 Requirement R2 Part 2.3 reads in part:
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.
This essentially matches the OT best practice described in Task 3, except for the requirement to do this within 35 days of completing the applicability evaluation for the patch. As with Task 3, this task cannot be fully automated, but professional services are available.
Task 4. Mitigation Plan Verification and Updates
If a mitigation plan has been put in place to mitigate the risk posed by the vulnerability or vulnerabilities addressed by a patch, it should either a) end when the patch is applied, or b) be periodically verified to still be in effect if the patch has not yet been applied. Of course, if a subsequent patch fixes the vulnerabilities addressed by the unapplied patch, the mitigation plan for the unapplied patch is no longer needed.
This task cannot be fully automated, but professional services can answer questions like whether a new patch fully mitigates the risk addressed by the unapplied patch.
Task 4_CIP. CIP-007 Requirement R2 Part 2.4 reads:
For each mitigation plan created or revised in Part 2.3, implement the plan within the timeframe specified in the plan, unless a revision to the plan or an extension to the timeframe specified in Part 2.3 is approved by the CIP Senior Manager or delegate.
This is very close to the best practice described in Task 4. As with Task 4, this task cannot be fully automated, but professional services can fill in any gaps.
The Need for Prioritization in OT Patch Management
Clearly, OT patch management, whether or not it is conducted for purposes of NERC CIP compliance, is not for the faint-hearted. This is especially true, given the rapid rate at which new vulnerabilities (CVEs) are being identified. In 2023, about 28,000 new CVEs were identified. That number jumped to 40,000 in 2024, for a total of about 280,000 CVEs. It is likely there will be a larger jump in 2025.
As a result, there are few if any medium or large organizations that are not overwhelmed with new patches to apply. Very few organizations believe they will ever finish applying all the patches they have to apply today, given that new patches are arriving at a faster rate all the time. To understand this, you just need to review all the tasks described above and imagine having to do all of them for – say – 1,000 patches. Now imagine doing them all for 40,000 patches.
This is why the most important term in software patch management today is patch prioritization: How can an organization rank their unapplied patches by the degree of risk mitigated by each patch and prioritize applying patches that mitigate the most risk, while at the same time “de-prioritizing” (i.e., not applying) patches that mitigate little or no risk? Only by doing this will most organizations be able to get their software vulnerability risks under control.
Moving Forward Together
At Foxguard, we understand the unique challenges of patching in OT environments. It’s a complex process that requires careful planning, precise execution, and tools designed specifically for operational systems. Our goal is to help you navigate these challenges with confidence and efficiency.
Foxguard’s Cyberwatch platform is purpose-built to support OT teams, offering advanced capabilities like vulnerability management, patch prioritization, and deployment tracking. With features such as agentless asset discovery and curated ICS Patch Updates, we provide the insights and resources you need to stay ahead of emerging threats while minimizing operational disruptions.
Additionally, Foxguard’s Patchintel solution enhances your OT patch management efforts by delivering detailed patch intelligence and centralized binary delivery tailored to OT environments. With Patchintel, you gain access to comprehensive patch analysis, authenticity verification, and structured data formats that streamline remediation and compliance processes. It’s designed to save you time, improve decision-making, and ensure you have clear visibility into all security-related patches for your assets.
Whether you’re building a patch management program from the ground up or refining an existing strategy, Foxguard is here to provide the expertise and solutions you need to succeed. Let us help you simplify the patching process and strengthen your OT security posture.
Ready to take the next step? Contact us today to learn how Foxguard can support your patching needs.
- NERC stands for North American Electric Reliability Corporation. CIP stands for Critical Infrastructure Protection. ↩︎
- For an open source product, the “publisher” is usually an open source community. For example, the popular Apache web server, known as “Apache HTTP Server”, is published by the Apache Software Foundation. ↩︎
- Some commercial vulnerability databases have added CPE names to some of the CVE records that do not contain them. ↩︎
- Some commercial vulnerability databases have added CPE names to some of the CVE records that do not contain them. ↩︎
- Since there are a host of considerations – many of them not written down – that apply to identification of Cyber Assets, BES Cyber Assets and BES Cyber Systems, it is important for NERC entity staff members who are not part of the NERC CIP compliance team not to try their hand at these identifications. If you believe there has been an error or omission in NERC CIP asset classification but you are not part of that team, you should notify the team, not attempt to correct the error yourself. ↩︎