The Numbers
Forescout’s analysis of ICS security advisories published in 2025 documents a record volume: 508 advisories covering 2,155 distinct vulnerabilities — the highest figures since systematic tracking began. The high-severity concentration is equally concerning: 75% of advisories across the full tracking period were rated high or critical, but when isolating 2025 data, that proportion increases to 82%.
The record volume reflects several converging factors. Increased security research attention on operational technology systems — which historically received far less scrutiny than IT software — has expanded the researcher community and the volume of responsibly disclosed findings. Vendors, under growing regulatory pressure from CISA, the EU CRA (Cyber Resilience Act), and sector-specific frameworks, are publishing advisories at a higher rate than previously. And the increasing convergence of OT and IT infrastructure, as industrial systems gain network connectivity and cloud integration, has expanded the attack surface available to researchers and threat actors alike.
What Is Being Affected
The advisory distribution is not evenly spread across the OT asset taxonomy. Forescout’s data shows a disproportionate concentration in specific asset categories:
Field controllers (PLCs and RTUs) are the most affected category. These devices — Rockwell Automation, Siemens, Mitsubishi, Schneider Electric, and others — execute the ladder logic and control programs that directly command physical processes. Vulnerabilities in PLCs carry operational risk that goes beyond data loss: a compromised PLC can cause incorrect valve positions, unexpected motor commands, or safety system bypass. The March 2026 CISA advisory (AA26-097A) documenting Iranian-affiliated attacks on Rockwell Allen-Bradley PLCs illustrates the consequence: attacker modification of PLC project files (.ACD format) that altered the displayed HMI values while changing the actual process control logic.
SCADA and HMI software represents the second major affected category. These are the software systems that operators use to monitor and command field devices. Vulnerabilities here typically enable remote code execution or privilege escalation on the engineering workstation or server running the SCADA platform — providing a pivot point into the OT network from the IT/DMZ boundary.
OT network infrastructure — industrial switches, serial device servers, protocol gateways — is the third significant category. Vulnerabilities in network infrastructure are particularly dangerous because they are often unpatched (network equipment firmware updates are operationally complex and require maintenance windows), have direct access to OT traffic, and are frequently not included in OT asset inventories that focus on end-device controllers.
The No-Patch Problem
The figure that should concern OT security practitioners most is not the volume of advisories — it is the proportion for which no patch is available. Across Forescout’s tracked period, approximately 26% of advisories describe vulnerabilities for which no vendor-supplied fix exists at the time of publication.
In IT security, a no-patch advisory triggers a compensating controls analysis while waiting for a fix. In OT, the calculus is harder:
- End-of-life hardware: A significant fraction of no-patch situations involve devices that are past vendor support. Replacing a PLC that controls a critical production line is not a decision taken lightly — it requires planning, procurement, shutdown scheduling, and re-certification of the control program. This process takes months to years.
- Vendor development timelines: OT vendors operate on different patch release cycles than enterprise software vendors. A critical vulnerability may have a 12–18 month fix timeline while the vendor validates that the patch does not introduce unintended behaviour in safety-critical contexts.
- Vendor discontinuation: Some no-patch situations arise from vendors that no longer exist or no longer support a product line, leaving operators with permanently unpatched assets in active service.
For assets in the no-patch category, compensating controls are the only defence. The relevant options depend on the asset type.
Compensating Controls for Unpatched OT Assets
Network isolation remains the most effective compensating control for assets that cannot be patched. The principle is simple: a vulnerable PLC that cannot be reached from the network cannot be exploited remotely. In practice, achieving isolation requires:
- Removing direct network access from the field device where possible. Legacy PLCs that communicate over Modbus serial can be isolated by removing Ethernet connectivity entirely.
- Placing networked field devices in isolated VLANs or security zones with strict ACLs permitting only the specific source IPs and protocols required for legitimate SCADA polling. Denying all other inbound traffic eliminates the attack surface for most advisory-documented vulnerabilities.
- Auditing firewall rules at the Purdue Model Zone 3/Zone 2 boundary (IT/DMZ to OT control network). Rules that permit broad access across this boundary — common in environments where the network segmentation design predates modern threat understanding — should be reviewed and tightened.
Unidirectional security gateways (data diodes) for assets that need to send data to IT systems but do not require bidirectional network communication. A data diode makes remote exploitation of the OT-side device physically impossible across that link.
Application whitelisting on engineering workstations prevents malicious code from executing on the workstations used to program and configure field devices, reducing the risk that a vulnerability in the SCADA platform is exploited to push malicious logic to downstream PLCs.
OT-native intrusion detection that can monitor industrial protocols (Modbus, DNP3, EtherNet/IP, Profinet) for anomalous commands — read/write to unexpected registers, command sequences inconsistent with normal operational patterns, or traffic from unexpected source addresses. Passive monitoring platforms (Dragos, Claroty, Nozomi, Armis) detect this without requiring active scanning that could disrupt process control.
Detection Focus Areas
Given the concentration of advisories in PLCs and SCADA software, detection priority should focus on:
Unauthorized PLC project file access: Monitor engineering workstations and PLC management systems for access to project files (.ACD for Rockwell, .zap15 for Siemens, .xg5 for Mitsubishi) from unexpected hosts or at unexpected times. The CISA AA26-097A advisory documented Iranian actors extracting .ACD files as a precursor to logic modification.
Unusual protocol function codes: OT intrusion detection systems should alert on read/write function codes directed at registers outside the normal operational range for each device. Attackers modifying control logic tend to write to registers that are not part of the standard polling cycle.
Outbound connections from OT assets: Field devices and SCADA servers should not initiate outbound internet connections. Any outbound TCP or UDP from OT network segments to public IP ranges should be treated as high-priority alerts. The Harvester APT’s Graph API C2 technique has not been documented in OT contexts yet, but the underlying pattern — using trusted cloud services as C2 channels — is being adapted by multiple threat actor groups.
Engineering workstation software installations: Log and alert on any software installation on engineering workstations. Legitimate OT operations do not require frequent software changes on workstations with direct PLC access; unexpected installs warrant investigation.
Practical Implications for Patch Management
The record advisory volume does not translate directly to a proportional patching requirement for most OT environments, because:
- Many advisories cover assets that specific operators do not run
- Network isolation already prevents exploitation of a subset of network-accessible vulnerabilities
- Available patches for OT devices require validation before deployment in production
The practical response is a risk-tiered approach:
- Critical + actively exploited: Apply available patches or isolate within 30 days. CISA KEV additions are the threshold signal.
- Critical + no active exploitation evidence: Apply within 90 days where operationally feasible; network isolation as compensating control while scheduling.
- High severity: Apply during next scheduled maintenance window; compensating controls in place during interval.
- No patch available: Document, implement compensating controls, and track vendor fix timeline. Re-assess compensating controls every 90 days.
The 508-advisory year reflects an OT security research and disclosure ecosystem that is, belatedly, applying to industrial systems the same scrutiny that IT infrastructure has received for decades. The result is a growing vulnerability backlog in operational environments that were designed without software security as a primary constraint. Working through that backlog requires systematic prioritisation, not the assumption that patch velocity achievable in enterprise IT can be replicated in operational technology.