OT/ICS Security Gaps: Why Critical Infrastructure Remains Vulnerable

Compliance frameworks exist to establish a security floor. The problem is that sophisticated threat actors don't audit for compliance-they audit for gaps. In industrial control system (ICS) and operational technology (OT) environments, those gaps are both pervasive and poorly understood. After reviewing the latest threat intelligence and incident data, I'm convinced that the security industry still hasn't grappled with what "beyond compliance" actually means for critical infrastructure.

This isn't a vendor pitch. The methodology I'm sharing comes from public research-Dragos, Check Point Research, Marlink, and independent vulnerability researchers who've been publishing findings the community can actually use.

The Air-Gap Mirage

Walk into most industrial facilities and you'll hear some version of this: "Our OT network is air-gapped, so we're protected." I've heard it from facility managers, security teams, and even some consultants. It's one of the most persistent myths in infrastructure security, and it's dangerous precisely because it creates false confidence.

The air-gap assumption worked when OT environments truly were isolated-when PLCs communicated over dedicated serial lines and nobody thought to connect them to corporate networks. That world is gone. Modern OT environments are hybrid systems where operational efficiency demands connectivity. Vendors need remote access for maintenance. Corporate IT wants real-time production data. Digitalization initiatives layer new systems atop decades-old infrastructure.

The result is that isolation has eroded through multiple pathways simultaneously: supply-chain compromises that introduce vulnerabilities during equipment provisioning, vendor access channels that bypass perimeter controls, removable media that operators use to transfer recipes and configurations, and the simple fact that IT/OT convergence has made the traditional "air gap" a geographic fiction.

Real breaches illustrate the point. In early 2026, a pro-Iranian threat actor known as Ababil of Minab claimed responsibility for a cyberattack on the Los Angeles County Metropolitan Transportation Authority (LACMTA), exposing real risks to rail control systems and critical transit infrastructure. They didn't breach some isolated network; they moved through interconnected systems where the "air gap" existed only on organizational charts.

The CyberAv3ngers group-linked to Iran-manipulated Rockwell PLCs and SCADA systems across water, energy, and government facilities in the United States. In Ukraine, the FrostyGoop malware disrupted heating for more than 600 buildings. The initial infection vector wasn't a sophisticated zero-day-it was the same removable media that operators use every day to transfer configuration files.

This doesn't mean segmentation is hopeless. The Purdue Model for control hierarchy still provides a useful framework-Level 0 through Level 5, from field devices to enterprise IT. What has changed is that modern implementations require active enforcement rather than assumed isolation. Zones and conduits must be defined, monitored, and controlled. Vendor access must be segmented from operational networks. Removable media policies must account for the fact that a USB drive is a bidirectional attack vector.

For brownfield environments where legacy PLCs and field controllers coexist with modern systems, segmentation becomes a journey rather than a destination. The practical approach is to start with visibility-you can't segment what you can't see-then identify the most critical assets and enforce controls around them first.

Living-off-the-Land in the Control Room

When I talk about OT threats with security teams, the conversation usually turns to malware. Flame. Stuxnet. Trisis. The sophisticated payloads that make headlines. But the day-to-day threat reality in ICS environments looks different, and if you're not watching for it, you'll miss it.

More than half of OT penetration tests conducted by security researchers show living-off-the-land (LotL) techniques-attacks that use legitimate engineering tools, protocols, and administrative access rather than custom malware. This isn't because attackers can't write code. It's because in OT environments, living-off-the-land works.

Consider what an attacker with credentials and network access can do in a typical control system environment. They can manipulate Modbus registers directly-the same protocol that operators use to read sensor values and write setpoints every day. They can interact with HMIs through legitimate software interfaces. They can issue commands through the same engineering workstations that plant personnel use for routine operations. The challenge for defenders is that all of this activity looks like legitimate operation until it doesn't.

The emergence of Black Shrantac-a rapidly evolving ransomware group active since September 2025-demonstrates this exact pattern. Analysis from Marlink shows this group increasingly leveraging legitimate administrative tools to infiltrate industrial environments, using double extortion tactics that combine encryption with data theft. They don't need custom malware when legitimate tools work fine.

The implications for detection are significant. Traditional endpoint detection and response (EDR) wasn't designed for control system environments. An EDR agent can't run on a PLC or most SCADA servers without risking operational disruption. Even where agents can run, the behavioral patterns that EDR looks for-process injection, memory scraping, unusual network connections-overlap substantially with what legitimate engineering software does every day.

The answer isn't more IT-style endpoint protection in OT environments. It's engineering-led, process-aware detection that understands the difference between normal operations and anomalous commands. When a technician accesses a specific HMI screen, that's expected behavior. When the same technician accesses seventeen HMIs in three minutes from an unusual external location, that's a detection trigger. The detection logic has to understand the operational context, not just the technical indicators.

This also means that IT security teams can't own OT incident response. The professionals who respond to incidents in control system environments need to understand the difference between a suspicious network connection and a process upset caused by aggressive remediation. Applying IT playbooks in OT environments has historically caused self-inflicted outages and, in some cases, safety incidents. The incident response approach has to be built with operations in mind.

Visibility as the New Perimeter

The concept of a network perimeter has been eroding for years in IT security. In OT environments, the perimeter was always somewhat fictional-"air-gapped" networks that turned out to have more entry points than anyone acknowledged. But there's a subtler problem that doesn't get enough attention: most OT networks have no idea what traffic flows through them.

Less than 10% of OT networks have adequate monitoring capabilities, according to Dragos and World Economic Forum research. That's not a vendor claim-it's a statistic derived from incident response engagements and assessment data across hundreds of organizations. The implication is that the majority of OT networks are effectively blind to what's happening on the wire.

Dragos tracks 26 OT threat groups actively operating, and in most cases, compromise becomes visible only after something in the process behaves abnormally. Threat actors are gaining access to industrial environments and positioning for operational impact-but only the organizations with visibility see it before something breaks.

This creates strategic problems beyond the immediate security concern. When adversaries conduct reconnaissance in an unmonitored OT network, they can operate with plausible deniability. Were those configuration reads normal vendor activity or hostile intelligence gathering? Was that brief anomaly a failed exploitation attempt or just a flaky sensor? Without recording-without the data to reconstruct what happened-attribution becomes guesswork and response becomes reactive.

The visibility gap also affects how organizations understand their own exposure. I've seen environments where the security team believed they had robust segmentation until passive monitoring revealed that a single engineering workstation had unrestricted access to multiple Purdue levels. The segmentation existed on paper; the actual traffic patterns told a different story.

The path to visibility without disrupting operations exists, but it requires understanding the constraints. Passive monitoring-SPAN ports, TAPs, and network flow analysis-can provide substantial visibility without introducing active probing that might interfere with control system communications. Asset inventory through passive collection builds automatically rather than requiring the kind of active scanning that some legacy systems can't handle.

Visibility isn't a luxury. For OT environments, it's the foundation that makes every other security control meaningful. You can't respond to what you can't see, and you can't segment what you can't map.

Beyond CVSS - Context-Based Prioritization

Every year, security teams face a growing volume of vulnerabilities in ICS environments. Across 2025, researchers disclosed more than 2,100 ICS vulnerabilities across more than 500 advisories-a record volume, according to Forescout's ICS/OT Vulnerability Intelligence research. Many of these vulnerabilities appear in devices that control physical processes: PLCs, remote terminal units, SCADA servers, and engineering workstations.

Here's the statistic that stopped me when I first encountered it: approximately 98% of high and critical severity ICS vulnerabilities have never been exploited in the wild. Not a small percentage-the overwhelming majority of vulnerabilities that security tools flag as urgent have no known active exploitation.

This isn't because threat actors lack imagination. It's because exploitation in OT environments requires more than a software vulnerability-it requires reachability. Can the vulnerable device actually be accessed from an attacker's position in the network? Does exploiting the vulnerability provide meaningful operational impact, or does it just crash a monitoring screen? Is the device even connected to anything an attacker could leverage?

CVSS scores answer none of these questions. A CVSS 9.8 vulnerability in a PLC that has no network connectivity and controls a non-critical process might represent less actual risk than a CVSS 6.5 in a controller that sits at the intersection of multiple Purdue levels. But generic severity scores don't capture that nuance, and organizations that prioritize remediation purely by CVSS are spending resources on the wrong targets.

The alternative is context-based prioritization that considers reachability, operational impact, and patch feasibility. Reachability asks: can an attacker reach this device from their current position, and what would they need to traverse to get there? Operational impact asks: if this device were compromised, what would the consequences be for safety, production, and reliability? Patch feasibility asks: can this device be patched without disrupting operations, or does it require a maintenance window, a controller replacement, or vendor involvement?

This framework isn't about ignoring vulnerabilities. It's about matching remediation effort to actual risk. A PLC with a known vulnerability might be appropriately managed through compensating controls-network segmentation, enhanced monitoring, physical access restrictions-if patching would require a production shutdown. That same vulnerability in a development environment might demand immediate patching because the development system can be taken offline without operational consequence.

The EmberOT vulnerability research and ICS Advisory Project have been publishing operationally relevant prioritization guidance that goes beyond CVSS. Their approach is worth studying if you're building an ICS vulnerability management program.

IT/OT Convergence Without the Chaos

Digitalization is forcing connectivity into environments that were never designed for it. Plant managers want real-time production data flowing to analytics platforms. Operations teams want remote monitoring capabilities that reduce the need for on-site presence. Efficiency initiatives demand integration between OT data and enterprise systems that run on IT infrastructure.

The pressure is real, and in many cases, legitimate. The problem is that most IT/OT integration projects create security liabilities rather than value. The integration is done quickly to meet business timelines. The security implications aren't fully considered. The result is that production data flows into corporate networks through channels that weren't designed for security, and corporate threats can potentially reach OT environments through the same pathways.

I've reviewed enough of these implementations to identify common failure modes. The first is assuming that IT security controls translate directly to OT environments. Firewalls that block all traffic from IT to OT networks create operational problems when legitimate data flows are needed-and in response, organizations punch holes through firewalls that undermine the segmentation they were supposed to provide. The second failure mode is treating OT security as a project with an end date rather than a continuous operational requirement. The integration is deployed, the project closes, and nobody maintains the security architecture as the environment evolves.

Secure hybrid architectures require deliberate design. The Purdue Model provides the conceptual framework-Level 0 through Level 5, with zones at each level that have specific security requirements. DMZs between IT and OT networks that enforce controlled data exchange without allowing direct connectivity. Segmentation that accounts for the operational necessity of certain traffic flows while blocking everything that isn't explicitly required.

The balance between efficiency and safety isn't a technical problem-it's an organizational one. Operations wants connectivity for efficiency. Engineering wants security for reliability. The security team is caught in the middle, trying to satisfy requirements that sometimes conflict. The organizations that navigate this successfully establish governance structures where OT security decisions involve both operations and security leadership, not just security teams working unilaterally.

The Path Forward

The expert consensus in OT security is clear: the industry needs to shift from reactive, compliance-driven risk models to continuous, intelligence-driven, cyber-physical resilience. Basic security hygiene-visibility, segmentation, credential management-still fails in most environments. Organizations that get these fundamentals right have substantially better outcomes than those that don't.

This isn't theoretical. Ransomware groups surged in 2025, with Check Point Research documenting 7,419 ransomware incidents globally-a significant increase. Manufacturing alone absorbed 1,466 incidents, a 56% year-over-year surge, accounting for roughly half of all global attacks. The groups that caused operational disruptions-Black Shrantac using LotL techniques and double extortion, Ababil of Minab targeting transit infrastructure-primarily exploited basic security failures. Credential reuse through VPNs. Exposed internet-facing devices. IT breaches that pivoted to OT environments through trusted pathways.

OT monitoring has become a core operational necessity, not an optional security enhancement. The organizations that treat it as such-that invest in visibility, that build incident response capabilities that understand control system operations, that prioritize remediation based on actual risk rather than CVSS scores-are the ones that survive incidents without catastrophic operational disruption.

The compliance floor exists for a reason. But the floor isn't the destination. Beyond compliance means building security programs that actually reduce risk in the environments where failure has physical consequences. Critical infrastructure deserves more than checkbox security. The community that shares methodology openly-the researchers publishing prioritization frameworks, the practitioners sharing incident response lessons, the organizations publishing their own experiences-is how the industry gets there.