Risk-Based Vulnerability Management and Patching Industrial Systems

Patching in Industrial Control Systems (ICS) and Operational Technology (OT) environments does not normally follow traditional IT patching processes, schedules, or methodologies. Common security advisories and vulnerability scores provide useful guidance, but effective ICS/OT patching requires careful engineering-informed analysis and close coordination with engineering teams to prioritize safety. 

This blog outlines key considerations for ICS/OT defenders looking to adopt a practical, engineering-driven approach to industrial control system vulnerability management. 

Risk-Based Patching Over "Patch Everything"

Mature ICS organizations have moved beyond “patch everything month” approaches. instead, they apply updates during planned engineering maintenance windows that align with operational needs and the analysis of the risk to operations. This risk-based evaluation stands apart from tradition IT patch processes because ICS/OT environments have different surfaces for attack, different systems, and different consequences when something goes wrong. 

The recent SANS ICS/OT Cybersecurity survey shows most ICS/OT teams conduct structured vulnerability assessments—ranging from paper-based reviews to active testing—and increasingly rely on passive monitoring and sector specific ICS/OT threat intel to reduce disruptions: 

• 47% rely on passive network monitoring to discover control system vulnerabilities 
• 34% apply vendor-validated patches on a pre-tested, engineering-defined schedule 

Where patching isn’t practical due to potential downtime or safety concerns, alternatives like virtual patching and compensating controls are essential. It’s all about engineering system, network awareness, and risk potential. 

Weighing Engineering Impact vs. Adversary Potential

Effective risk-based patching involves weighing engineering impact against adversary potential. On one side are considerations such as downtime and production disruption, patch deployment failures, the need to coordinate control system maintenance schedules, and the possibility of implementing workarounds or temporary mitigations without downtime—all based on the targeted or affected assets (human machine interfaces (HMIs), remote terminal units (RTU), protection control relays, etc.) and their criticality. 

On the other side is the risk that an attacker could gain access to the ICS environment, discover a vulnerability, obtain or create an exploit, test it, and then exploit that vulnerability after pre-positioning in the control system environment for follow-on actions that impact operations and safety. 

Patching decisions should always consider both sides. The goal is to ensure that security measures enhance, and support safety, integrity, and operational availability rather than unnecessarily disrupt them. Additionally, it is important to know that patching is not the end all be all and final answer to reducing targeted threats, as seen in this blog on ICS/OT attacks that live off the land.

Beyond CVSS: Engineering Context is Everything

CVSS scores will continue to play a role in mitigation efforts, but they are insufficient on their own. Prioritizing patching based solely on CVSS ratings can lead to downtime or safety risks, with very low security return on investment. Effective ICS vulnerability mitigation depends on understanding the threat vector and the operational criticality of assets, assessing the potential impacts of downtime, and considering the evolving threat landscape and adversary capabilities.  

To achieve this, organizations can leverage vendor-supplied ICS/OT-specific solutions that support contextual and risk-based vulnerability prioritization. These tools safely build an asset inventory, continuously monitor for vulnerabilities, and prioritize them based on engineering-provided context—such as asset criticality, network location, and potential operational impact. This contextual insight is essential for making informed and defensible risk-based operational decisions. 

Foundations and Conclusion

IT security processes demand a thoughtful, risk-informed approach grounded in engineering context and operational awareness. ICS defenders must move beyond relying solely on CVSS scores to incorporate a deep understanding of asset criticality, network architecture, and the potential operational impacts of downtime from patch deployment versus adversary potential. 

With an established, engineering-informed vulnerability management process, organizations can prioritize vulnerabilities that:

• Are actively being exploited  
• Allow remote code execution 
• Enable abuse of native ICS protocols 
• Compromise remote access pathways into ICS/OT environments 

There is no one-size-fits-all approach, but mature organizations may consider a phased, level-based strategy aligned with the Purdue Model. For example, patching at Levels 3.5 and 3 may be less disruptive if operators can continue using embedded HMIs at lower levels. Additionally, applying updates and patches during planned maintenance windows remain the safest method to maintain operational safety. 

Close collaboration with engineering teams is the only effective way. Start today by reviewing your patching processes to ensure they truly enhance the resilience of your ICS environment, where security supports safety. Take a deeper look into the Five ICS Cybersecurity Critical Controls for more.

Advancing Your ICS/OT Cybersecurity Skillset

If this blog sparked questions about how to apply these practices in your own control system environment, in-depth hands on training like ICS410: ICS/SCADA Security Essentials or ICS515: ICS Visibility, Detection, and Response can help deepen your defense, network visibility, risk-based security decision-making, and operational safe controls.

I invite you to join me in class as I teach ICS515: ICS Active Defense and Incident Response this October at SANS Orlando Fall 2025 starting October 27 and at SANS San Francisco Fall 2025 starting November 17.