ICS and OT Cybersecurity 2026: AI Vulnerability Discovery in Industrial Control Systems

Most IT security practitioners who are assigned OT responsibility encounter a domain where their standard playbook does not apply. The confidentiality-integrity-availability (CIA) triad is inverted in OT: availability is the paramount concern, integrity is second, and confidentiality is a distant third. An IT security professional's instinct to take a compromised system offline for forensic analysis can be catastrophically wrong in an OT environment where that system is controlling a live industrial process. OT environments are built around deterministic real-time communications. SCADA systems collect data from and send commands to field devices (PLCs, remote terminal units) through protocols designed for reliability and speed, not security. Protocols like Modbus (developed in 1979), DNP3, and older versions of EtherNet/IP lack authentication, encryption, or integrity verification. An attacker with network access to an OT segment can inject commands to physical devices with no authentication barrier. OT security also involves a vendor dependency that is more acute than in IT: the firmware, operating systems, and communications stacks in OT devices are proprietary, and security updates depend entirely on the vendor's release schedule. Many OT vendors do not have mature vulnerability disclosure programs and have historically been slow to release patches even after vulnerabilities are publicly known.

The Purdue Enterprise Reference Architecture (PERA), commonly called the Purdue Model, has been the dominant framework for ICS/OT network architecture since the 1990s. It organizes industrial network zones into levels: Level 0 (physical process), Level 1 (basic control via PLCs/RTUs), Level 2 (supervisory control via SCADA/HMI), Level 3 (operations management), a DMZ, and Level 4 (enterprise IT). The model assumes that strict network segmentation between levels prevents threats from propagating from the enterprise network into OT environments. In practice, the Purdue Model's assumptions have been eroded by decades of IT/OT convergence. Remote access connections for vendor maintenance, historian databases that bridge OT and IT networks, cloud-connected sensors, and business pressure to integrate operational data with enterprise analytics have created hundreds of pathways across the boundaries the Purdue Model assumes to be hard. Security researchers and incident responders have documented Purdue Model violations in nearly every ICS environment they assess. The model remains useful as a conceptual framework, but treating it as a realized security control rather than an aspiration is a category error that many organizations make.

IT/OT convergence refers to the increasing integration of enterprise IT networks with OT control system networks, driven by digital transformation initiatives, remote monitoring, predictive maintenance, and supply chain integration. From a business perspective, convergence provides real value: real-time operational data improves decision-making, remote access reduces maintenance costs, and connected sensors enable predictive analytics. From a security perspective, convergence creates attack surface. The pathways that allow operational data to flow from OT to IT also create pathways that allow threats to propagate from IT to OT. The 2015 Ukraine power grid attack demonstrated this in a highly visible way: attackers moved from IT networks through OT boundaries to issue commands to breakers. The Colonial Pipeline attack in 2021 demonstrated the inverse: a ransomware attack on IT systems caused the operator to shut down OT operations proactively, creating physical disruption without ever touching OT networks directly. Glasswing's critical infrastructure expansion is relevant to convergence risk because many of the vulnerabilities it is identifying are in software and protocols that exist in both IT and OT contexts. A vulnerability in a networking library or operating system component that is present on both enterprise servers and OT historian systems creates a lateral movement pathway.

The OT patching challenge is structural, not a matter of organizational will or budget. Consider the constraints facing a utility security team that receives a Glasswing CVD notification for a vulnerability in a SCADA system it operates. The SCADA system controls physical switching operations in a live power grid and runs continuously with a maintenance window of approximately four hours every 18 months. The vendor has a patch available, but it requires testing in a representative environment before deployment. The utility's test environment is not fully representative of the production system because it was built in 2018 and the production SCADA has received numerous configuration changes since then. The vendor's patch validation documentation recommends a two-week testing period. During those two weeks, the vulnerability is disclosed publicly. This scenario is not a hypothetical: it is the standard operating condition for most critical infrastructure OT environments. Factors that compound the patching difficulty include: vendor-prescribed maintenance windows that cannot be unilaterally extended; the absence of redundant systems in many OT environments that would allow hot-patching; the need for coordination with operational, safety, and regulatory stakeholders; and the reality that some patches require physical access to field devices distributed across large geographic areas.

The traditional threat model for OT security assumed that attackers required nation-state-level capability, deep knowledge of specific OT protocols and equipment, and months of reconnaissance to carry out a meaningful ICS attack. This assumption justified patching timelines measured in months and maintenance windows that extended past any reasonable CVSS SLA. AI changes the capability baseline. Claude Mythos's performance on the Exploit Evals benchmark, where it solved 21 of 41 V8 adversarial code execution challenges in the same session as discovery and outperformed all other models (which scored zero), demonstrates autonomous capability that was previously restricted to elite human researchers. The same autonomous reasoning that enables Mythos to develop V8 exploits can be applied to OT protocol analysis, firmware reverse engineering, and control logic vulnerability identification. The practical consequence is that the assumption of a months-long gap between a vulnerability being discovered and a weaponizable exploit being available no longer holds for sophisticated threat actors. When Glasswing publishes a CVE in software present in OT environments, threat actors with comparable AI tools can develop exploits rapidly. The urgency of compensating controls for environments that cannot patch immediately is substantially higher than it was when the same vulnerability would have taken a skilled human team weeks to weaponize.

NERC CIP standards apply to entities that own or operate bulk electric system (BES) assets in North America. The most relevant standards for vulnerability management and AI-discovered threats are CIP-007 (Systems Security Management, which requires patch management programs with 35-day assessment and 35-day remediation timelines for applicable high and medium BES cyber assets), CIP-010 (Configuration Change Management and Vulnerability Assessments), and CIP-011 (Information Protection). The 35-day patching SLA in CIP-007 was established before AI-accelerated vulnerability discovery existed as a threat vector. Organizations should document their risk rationale for any patch delayed beyond that SLA and ensure compensating controls are in place. IEC 62443 is the international standard series for industrial cybersecurity. It is not mandatory in the way NERC CIP is for electric utilities, but it is increasingly referenced in procurement requirements and is used by manufacturers to certify OT components. IEC 62443-3-3 (System Security Requirements and Security Levels) and 62443-4-2 (Technical Security Requirements for IACS Components) are most relevant for organizations assessing their OT security posture against an AI-discovery threat model. Both NERC CIP and IEC 62443 require security risk assessments that must be updated when new threats emerge. An organization's risk assessment should explicitly address the implications of AI-accelerated vulnerability discovery for its OT environment.

For OT environments where patching is not feasible on any near-term timeline, compensating controls are the primary defense. The most effective compensating controls for AI-discovered OT vulnerabilities are as follows. Network segmentation remains the highest-leverage control: OT networks should be isolated from IT networks using firewalls that permit only documented and required communications, with all other traffic denied by default. Protocol-aware OT firewalls can enforce allowed command sets for protocols like Modbus, DNP3, and EtherNet/IP, blocking anomalous or unauthorized commands even when traffic appears to originate from inside the OT network. Behavioral monitoring using OT-specific intrusion detection systems that build baselines of normal process behavior can detect anomalies that indicate compromise. Tools designed for OT environments understand industrial protocols and can generate alerts for process anomalies without disrupting operations. Data diodes (unidirectional security gateways) provide air-gap equivalent isolation for the most sensitive OT zones where any bidirectional network connection represents unacceptable risk. Enhanced access controls for remote access pathways, which are a primary attack vector for OT environments, include multi-factor authentication, session recording, and just-in-time access provisioning that minimizes the window during which remote access is available. Physical security controls that restrict physical access to OT components remain relevant: an attacker with physical access to a PLC or HMI can make changes that no network-based control can prevent.

The Mythos Brief includes OT-specific vulnerability indicators of compromise and a compensating control implementation checklist developed from Glasswing's critical infrastructure assessment program. The following items are available in full detail to Mythos Brief subscribers.