Vulnerability management in OT environments - from identification to remediation

In February 2021, an operator at the Oldsmar water treatment plant in Florida noticed the cursor on the HMI screen moving on its own - someone was remotely changing the sodium hydroxide concentration from 100 to over 11,000 ppm. The attacker used TeamViewer running on a workstation with Windows 7, a system without support since January 2020. Had the operator not been sitting at the console at that moment, contaminated water could have reached 15,000 consumers.

This incident did not require a sophisticated exploit chain or a zero-day vulnerability. Unpatched software, a shared password and a lack of segmentation were enough - three problems that vulnerability management should have addressed long before the attack.

In OT environments, vulnerability management is one of the hardest processes to implement. Systems cannot be patched on the fly, the vendor controls the update schedule, and the patch itself may disrupt the stability of the production process. This article covers the full cycle - from vulnerability identification to remediation or the application of compensating controls - taking into account the realities in which industrial automation systems operate.

Sources: Forescout ICS Cybersecurity 2026, Claroty State of CPS Security 2025

Why OT is not IT - the specifics of vulnerability management in industrial automation

In IT networks, the patching cycle is measured in days. The security team publishes a bulletin, administrators test the fix on a pilot group and deploy it to production. In OT, the same process can take months - or never happen at all.

The difference stems from five fundamental constraints:

Factor	IT environment	OT environment
Availability	Downtime tolerance (maintenance windows)	Zero tolerance - continuous process 24/7/365
Lifecycle	3-5 years	15-25 years, often longer
Update control	Administrator decides	Vendor must approve the patch
Testing	Test environment is standard	Test environment rarely available
Failure impact	Data loss, service outage	Threat to life, environment, production losses

No “live” patching

A PLC controller managing a chemical process or production line cannot be restarted between production cycles the way a web server can. Loading new firmware requires:

• stopping the process or switching to redundant control,
• testing the new version (ideally on an identical test stand),
• vendor confirmation that the fix is compatible with the existing configuration,
• coordination with the production team and maintenance staff.

In practice, planned maintenance shutdowns occur once every 6-18 months. This means that even a critical vulnerability with a CVSS score of 9.8 may remain unpatched for the entire period.

Vendor dependency

In IT, administrators decide the patching schedule themselves. In OT, the manufacturer of the PLC controller, DCS or RTU must officially approve each update. Many vendors publish security bulletins with delays or do not offer patches for older models that are still formally running in installations.

Vulnerability lifecycle in OT environments

Vulnerability management in OT is a continuous process comprising five stages. Each differs from its IT counterpart.

1. Identification - discovering vulnerabilities

Sources of vulnerability information for industrial systems:

• CISA ICS Advisories - in 2025, CISA published 508 advisories covering 2,155 CVEs. This was the first year to exceed 500 advisories. The average CVSS score rose from 6.44 in 2010 to 8.07 in 2025, meaning the typical disclosed vulnerability shifted from the “medium” to the “high” category.
• Vendor bulletins - Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation publish their own advisories, often earlier than CISA.
• Vulnerability databases - NVD (National Vulnerability Database), Exploit-DB, VulnDB.
• CISA KEV catalog (Known Exploited Vulnerabilities) - a list of vulnerabilities actively exploited in attacks. In 2025, 29 entries concerned ICS systems, of which 16 (55%) were Siemens products.
• Passive OT network scanning - tools such as Tenable OT Security, Claroty or Nozomi Networks Guardian analyze network traffic and correlate discovered devices with vulnerability databases without actively querying controllers.

2. Assessment - contextualizing vulnerabilities

A CVSS score alone is not enough to assess risk in an OT environment. A vulnerability with CVSS 9.8 in a controller isolated in a SIS (Safety Instrumented System) security zone has a different significance than the same vulnerability in an HMI with access to the corporate network.

Contextual assessment considers:

• Network exposure - is the device accessible from the IT network or the internet?
• Asset criticality - does the controller manage a process affecting human safety (SIL-rated)?
• Exploit availability - is there a publicly available exploit code (PoC)?
• Active exploitation - does the vulnerability appear in the CISA KEV catalog?

3. Prioritization - SSVC instead of CVSS alone

The traditional “patch everything with CVSS >= 7.0” approach does not work in OT, where patching is costly and risky. CISA recommends the SSVC (Stakeholder-Specific Vulnerability Categorization) methodology, developed jointly with Carnegie Mellon SEI.

SSVC evaluates five dimensions and generates one of four decisions:

SSVC decision	Meaning	Example in OT
Act	Immediate remediation	KEV in an HMI with internet access
Attend	Remediation in the next maintenance window	High CVSS, no exploitation, but device in DMZ zone
Track*	Monitor, plan remediation	Known vulnerability, device in a closed zone
Track	Observe, no immediate action	Low exposure, no PoC, device in SIS zone

Five SSVC assessment criteria:

1. Exploitation status - is the vulnerability being actively exploited?
2. Technical impact - partial or full system compromise?
3. Automatable - can the exploitation be automated?
4. Mission prevalence - how critical is the system to the process?
5. Public safety impact - can compromise endanger people?

4. Remediation - patch, compensating control or risk acceptance

After prioritization, each vulnerability requires one of three decisions:

a) Install the patch - when the vendor has released an approved update and it can be deployed during a planned maintenance window.

b) Apply a compensating control - when patching is impossible or too risky. Options:

• Virtual patching - IPS/IDS rules blocking the specific exploitation vector at the network level, without modifying the target device.
• Network segmentation - isolating the vulnerable device in a separate zone with restricted access (more on segmentation).
• Protocol filtering - an industrial firewall passing only authorized commands (e.g. Modbus register reads, blocking writes).
• Monitoring - increasing the detection level: alerts on unusual queries, configuration changes, new connections.
• Restricting remote access - disabling or adding additional security to remote channels (configuring secure access).

c) Accept the risk - a formally documented decision when the risk is low (device in an isolated zone, no exploit, low impact). Requires periodic review.

5. Verification - confirming effectiveness

After remediation, verify whether:

• the patch was actually installed (not just planned),
• the compensating control works as intended,
• the device functions correctly after the change,
• no new vulnerabilities appeared as a side effect of the update.

IEC 62443 - regulatory requirements for vulnerability management

Two documents in the IEC 62443 family directly address vulnerability management:

IEC 62443-2-3 - patch management in the IACS environment

Technical report IEC TR 62443-2-3:2015 defines a five-phase patch management cycle:

1. Identification - tracking security alerts and vendor bulletins
2. Prioritization - risk assessment considering the IACS context
3. Testing - verifying the patch in a test environment before production deployment
4. Deployment - installing the patch in accordance with change management procedures
5. Verification - confirming proper system operation after the update

The standard emphasizes that patch management must be integrated with the change management process - every modification to an OT system requires formal approval and documentation.

IEC 62443-4-2 - component security requirements

The IEC 62443-4-2 standard defines technical requirements that the component manufacturer should meet. From a vulnerability management perspective, the relevant requirements concern:

• secure firmware update mechanisms (digital signature, integrity verification),
• support for authentication and authorization (elimination of default passwords),
• security event logging enabling detection of exploitation attempts.

The CISA KEV catalog and its significance for OT

The Known Exploited Vulnerabilities (KEV) catalog is a list maintained by CISA under directive BOD 22-01. It contains vulnerabilities for which evidence of active exploitation exists.

For OT environments, the KEV catalog serves three functions:

1. Prioritization - if a vulnerability is in the KEV, it means attackers are actively exploiting it. In an OT environment, such a vulnerability requires an immediate compensating control, even if patching is not possible.
2. Vendor risk assessment - if a PLC controller manufacturer has many KEV entries without delivered patches, that is a signal to escalate or consider an alternative vendor.
3. Compliance - organizations subject to US federal regulations (FISMA, BOD 22-01) are obligated to remediate KEV entries within specified timeframes. In Europe, the NIS2 directive imposes analogous requirements.

According to Claroty Team82 analysis, 12% of OT devices in surveyed organizations have vulnerabilities listed in the KEV catalog, and 40% of organizations have at least some of those devices with unsecured internet access.

Compensating controls - when patching is impossible

In OT, compensating controls are not a fallback plan - they are a standard part of the strategy. For many devices with a 15-25 year lifecycle, security patches will never be released.

Compensating controls matrix

Control	Mechanism	When to apply	Limitations
Virtual patching (IPS)	Rules blocking the exploit at the network level	Known attack vector, signature available	Does not protect against new exploits
Network segmentation	Isolating the vulnerable device in a zone with restrictive rules	Device does not require broad network access	Requires architecture redesign
Protocol filtering	Industrial firewall (DPI) passing only authorized commands	OT protocols (Modbus, S7comm, EtherNet/IP)	Requires detailed knowledge of normal traffic
Anomaly monitoring	Alerts on deviations from baseline	Supplement to every other control	Does not block the attack, only detects it
Disabling unnecessary services	Deactivating unused ports, protocols, interfaces	Every OT device	Requires dependency analysis
Configuration hardening	Changing default passwords, disabling web services	Every OT device	Does not address firmware vulnerabilities

Tools supporting vulnerability management in OT

An effective vulnerability management program requires tools designed for the specifics of industrial environments. Three categories of solutions:

Visibility and vulnerability identification platforms

• Tenable OT Security (formerly Indegy) - combines passive listening with active controller querying (in a safe manner, at the level of their native protocols). Correlates discovered devices with the vulnerability database and supports context-based prioritization.
• Claroty Platform - monitors OT communication, identifies devices and maps vulnerabilities. Offers integration with the risk management process (risk-based approach).
• Nozomi Networks Guardian - passive OT network monitoring with anomaly detection and vulnerability assessment. Uses an OT Threat Intelligence feed to correlate with the latest threats.

SBOM (Software Bill of Materials) analysis

A growing trend is requiring vendors to provide an SBOM - a list of software components in the device. SBOM enables:

• automatic identification of vulnerable libraries (e.g. Log4j in embedded systems),
• tracking end-of-life components,
• faster determination of whether a new CVE affects devices in the installation.

Patch management

Tools such as Tripwire, SolarWinds Patch Manager or dedicated modules in OT platforms support planning, testing and verifying patches while accounting for maintenance windows.

Incidents caused by unpatched systems

The history of OT cybersecurity provides many cases where unmanaged vulnerabilities led to real consequences.

WannaCry - May 2017

The WannaCry ransomware used the EternalBlue exploit (MS17-010) - a vulnerability in the Windows SMBv1 protocol. The Microsoft patch had been available since March 2017, but organizations with OT systems based on Windows XP and Windows 7 could not install it due to lack of support or dependency on the DCS/SCADA system vendor. Victims included Honda, Renault-Nissan manufacturing plants and the British NHS.

Oldsmar Water Treatment - February 2021

The attacker gained remote access to the HMI through TeamViewer on a workstation running Windows 7 (EOL since January 2020). The system had no multi-factor authentication, used shared passwords and was not separated from the public network. The incident demonstrated how the accumulation of unmanaged vulnerabilities creates an attack vector accessible even to a low-skilled adversary.

VPN vulnerabilities in OT infrastructure - 2019-2025

A series of critical vulnerabilities in VPN solutions (Pulse Secure CVE-2019-11510, Fortinet CVE-2018-13379, Citrix CVE-2019-19781) were massively exploited by APT groups and ransomware to gain access to OT networks. Many industrial organizations did not patch these systems for months, treating VPN as an “IT network device” rather than an element of critical OT infrastructure.

Checklist - building a vulnerability management program in OT

• Conduct an inventory of all OT assets - you cannot manage vulnerabilities on devices you do not know about
• Deploy passive OT network monitoring with automatic vulnerability correlation
• Configure alerts for new CISA ICS-CERT bulletins and your device vendors’ advisories
• Define a vulnerability assessment procedure that considers OT context (not just CVSS)
• Implement SSVC or a similar prioritization methodology
• Determine maintenance windows and coordinate them with patching plans
• For each vulnerability without an available patch - define and document a compensating control
• Provide a test environment for verifying patches before production deployment
• Monitor the CISA KEV catalog for vulnerabilities affecting your devices
• Require SBOM from vendors of new devices and systems
• Integrate vulnerability management with the change management process (IEC 62443-2-3)
• Conduct periodic reviews of accepted risks and active compensating controls

From identification to continuous improvement

Vulnerability management in OT is not a one-time project but a continuous process. Its effectiveness depends on three elements: up-to-date knowledge of assets (inventory), current threat intelligence and the ability to respond (patching procedures and compensating controls).

Organizations that take this process seriously do not eliminate all vulnerabilities - that is impossible given the lifecycle of OT devices. Instead, they build a layered protection system in which every unpatched vulnerability is consciously managed: identified, assessed, prioritized and covered by an appropriate control.

---

Sources:

• CISA ICS Advisories Recap for 2025 - SOCRadar
• ICS Cybersecurity in 2026: Vulnerabilities and Path Forward - Forescout
• State of CPS Security: OT Exposures 2025 - Claroty
• CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
• IEC TR 62443-2-3:2015 - Patch management in the IACS environment
• Importance and Challenges of OT Patching - ISA
• CISA Known Exploited Vulnerabilities Catalog
• DHS Recommended Practice for Patch Management of Control Systems