40% of organizations have OT assets insecurely connected to the internet. Over 180,000 ICS devices are exposed globally. The air gap exists on the diagram — the internet tells a different story.
Ask any critical infrastructure operator whether their OT network is connected to the internet, and most will say no. They will point to a network diagram showing a clear boundary — IT on one side, OT on the other, a firewall or DMZ in between. The diagram says air-gapped. The internet says otherwise.
The numbers tell a different story:
These are not lab environments or research honeypots. These are production PLCs, HMIs, RTUs, and engineering workstations running in water plants, power substations, manufacturing facilities, and building management systems. Visible to anyone who scans for them.
The air gap is a diagram. The internet is the ground truth.
No OT engineer deliberately puts a PLC on the public internet. These exposures show up through patterns that are predictable, repeatable, and well-documented in incident reports.
The shift to remote operations — accelerated during and after the pandemic — created massive OT exposure. Vendors and integrators need remote access to maintain equipment. Plant operators need to monitor processes from home. The solutions deployed often bypass the air gap entirely:
This is how it plays out in practice: In 2023, China-nexus threat group Volt Typhoon compromised Littleton Electric Light and Water Departments in Massachusetts through a public-facing FortiGate 300D firewall. They stayed inside for over 300 days, harvesting credentials and moving laterally through infrastructure that was designed to be segmented. The "air-gapped" OT environment was reachable through the compromised perimeter device (detailed in case studies below), as reported by The Record.
The Purdue model — the layered reference architecture that segments enterprise IT from supervisory control from the physical process — has been the textbook answer for OT network design since the 1990s. In practice, a large share of OT environments never implemented it. The network was built to move data between machines, not to enforce security boundaries. A single subnet carries both corporate IT traffic and industrial control traffic, and when that subnet gets an internet connection — for email, ERP, vendor updates, cloud analytics — every device on it becomes potentially reachable from the outside.
This is especially common in:
The common thread: these networks were designed for operational convenience, not adversarial resilience. Segmentation was always something to add later, and later never came.
The firewall exists on the diagram. Whether it does what the diagram says is a different question.
The most common failure mode is the "temporary" rule. A vendor needs remote access to troubleshoot a PLC. Someone opens a port, the vendor fixes the issue, and the rule stays in the firewall config for the next three years because nobody tracks who created it or why. Over time, these accumulate. A firewall with 200 rules, 40 of which are undocumented exceptions from past maintenance windows, is not providing the segmentation the architecture diagram shows.
NAT adds another layer of risk. A port-forward rule intended to expose a single management interface on a specific IP can, if misconfigured, expose an entire subnet. This is especially dangerous in OT environments where devices on the same subnet — PLCs, HMIs, historians — were never designed to be internet-reachable and have no authentication to fall back on.
Then there is the port coverage gap. Firewall policies at most organizations are written for IT traffic: HTTP, HTTPS, SSH, RDP, SQL. OT-specific ports — 502 (Modbus), 102 (S7), 47808 (BACnet), 44818 (EtherNet/IP), 20000 (DNP3) — often are not in the rule set at all because the firewall team does not know they exist. Traffic on those ports passes through unfiltered, and nobody notices because nobody is looking for it.
Cloud migration creates a newer variant of this problem. When organizations move historians, data lakes, or analytics platforms to the cloud, the data pipeline from OT devices to cloud services creates a network path that traverses the internet. If that path is not properly isolated, it becomes a bidirectional route — and the OT device that was sending telemetry to the cloud is now reachable from it.
Perhaps the most dangerous pattern: devices that exist in the OT environment but were never provisioned by the OT team and do not appear in any asset inventory.
Every organization has them. A facilities manager installs a cellular-connected vibration sensor on a pump. An equipment vendor ships a PLC with a built-in 4G modem for remote diagnostics — enabled by default. A property management company deploys a smart building platform that connects BACnet controllers to a cloud dashboard. A test bench from a commissioning project three years ago is still powered on and connected.
None of these devices went through a security review. None of them appear in the IT asset inventory, the OT asset inventory, or the CMDB. The OT security team does not know they exist. The IT security team does not know they exist. But they are on the network — sometimes on the OT network directly — and many of them have internet connectivity by design.
Claroty's analysis of nearly one million OT devices found that 40% of organizations have OT assets insecurely connected to the internet. A meaningful share of those connections are not the result of a deliberate architecture decision. They are shadow devices that nobody approved and nobody monitors.
A real example: FrostyGoop, the ICS malware that cut heating to 600+ apartment buildings in Lviv, Ukraine in January 2024, got its initial foothold through a Mikrotik router that was not part of the formal OT architecture. From there, the attackers reached ENCO controllers via Modbus TCP and changed heating setpoints. The OT devices were not directly internet-facing, but someone had never accounted for the network path from the internet to the controllers. It existed, and it was exploitable. Dragos published a detailed analysis of the incident.
Remote access, flat networks, misconfigured firewalls, shadow devices — those are the mechanisms. They explain how OT devices end up on the internet. The next question is how many, and what an attacker actually sees when they find one.
When critical infrastructure networks are scanned from the outside, the findings consistently contradict the air gap assumption:
| Protocol | Internet-Exposed Devices | Primary Sectors |
|---|---|---|
| Modbus TCP | 54,770+ | Energy, Manufacturing, Water |
| BACnet | 12,000+ | Building Automation, Healthcare |
| Fox (Niagara) | 30,000+ | Building Automation |
| EtherNet/IP | 7,000+ | Manufacturing, Oil & Gas |
| S7 (Siemens) | 4,500+ | Manufacturing, Energy |
| DNP3 | 1,500+ | Electric Utilities, Water |
Approximate device counts based on Censys and Shodan internet-wide scan data. Actual counts fluctuate as devices come online and offline. Cross-referenced with Bitsight ICS/OT exposure research.
These are not web interfaces or management consoles. These are the native industrial control protocols — most of them designed decades ago with no authentication whatsoever. Modbus accepts commands from any source. BACnet broadcasts device information to anyone who asks. DNP3 was built for serial links between trusted endpoints, not TCP connections from arbitrary IPs. Every protocol on this table was designed for a closed network. None of them are on one.
This is not theoretical. Forescout Vedere Labs deployed a network of 11 OT honeypots — industrial routers, PLCs, and similar devices — and recorded over 60 million inbound requests in 90 days. The vast majority was automated scanning and SNMP enumeration, but roughly 3.5 million were substantive attack events: brute-force attempts, exploit payloads, and malware delivery. Their findings:
The takeaway: if your OT device is reachable from the internet, someone is already poking at it.
Volt Typhoon — the China-nexus group introduced earlier — compromised multiple U.S. critical infrastructure organizations through public-facing network appliances, per CISA's advisory. The Littleton case is worth examining specifically for the air gap question. This was a small municipal utility. They had a FortiGate firewall. They had network segmentation. On paper, the OT environment was separated from IT. In practice, the attackers lived inside the network for over 300 days, harvested Active Directory credentials, and had access paths to operational systems — all through a device that was supposed to enforce the boundary between IT and OT.
The segmentation existed on the diagram. The attacker never saw the diagram.
SYLVANITE illustrates a different air gap failure mode: the security device as attack vector. Dragos identified this China-nexus group exploiting Ivanti Connect Secure VPN vulnerabilities at U.S. electric and water utilities. They extracted Active Directory credentials, established persistent access, and then handed off those footholds to VOLTZITE for deeper OT-focused intrusion.
The VPN appliance was deployed specifically to provide secure remote access — to enforce a controlled boundary between the internet and the internal network. Once compromised, it provided exactly the access it was designed to protect against. The air gap did not fail because it was missing. It failed because the device enforcing it became the entry point.
FrostyGoop is the shadow OT case study. The attackers compromised a Mikrotik router that was not part of the formal OT architecture — it did not appear on the network diagram, was not managed by the OT team, and was not covered by whatever segmentation controls existed. From that router, they reached ENCO controllers via Modbus TCP and manipulated heating system setpoints. Over 600 apartment buildings lost heat for nearly two days in winter.
The facility had an OT architecture. The Mikrotik router was not part of it. But the network path from the internet through that router to the controllers existed, and nobody knew about it until the heating stopped. This is what happens when the air gap is defined by the diagram rather than by what is actually on the network.
The three case studies above each represent a different air gap failure mode — a compromised perimeter device, a weaponized VPN appliance, and an unmanaged router that nobody knew about. What they share is that in each case, the organization believed it had segmentation. The diagram said so. The compliance audit confirmed it. The architecture review did not flag a problem.
The fundamental issue is that OT security posture is almost always assessed from the inside: network diagrams, architecture reviews, firewall rule audits, compliance checklists. These tools answer the question "how did we design the network?" They do not answer a different and more important question: "what can an attacker see from the outside?"
A network diagram shows intent. An external scan shows reality. The distance between those two things is your actual attack surface.
This gap persists because:
Before commissioning an external assessment, asset owners can perform basic checks using publicly available data:
scada., hmi., plc-) that appear in public CT logs indicate services that were or are internet-facing.scada.example.com or bms.example.com that resolve to public IPs are a clear indicator.These are non-intrusive, passive checks. They do not touch your infrastructure. They simply reveal what is already publicly visible — the same information any threat actor can access.
The air gap question is the wrong question. The useful one is: "What is currently exposed, and how does that map to what threat actors are actually targeting?"
Answering that requires a shift from inside-out to outside-in.
Start with external discovery. Most organizations assess their OT security posture from inside the network — architecture reviews, firewall audits, vulnerability scans. These are useful but they cannot see what the internet sees. An external scan using OT-native protocol probes (not just TCP port enumeration) reveals devices that internal tools miss entirely: the cellular modem that bypasses the firewall, the cloud-connected HMI that routes through a third-party API, the test bench that was never decommissioned. If you only look from the inside, you only find what you already know about.
Correlate assets to ownership and context. An exposed Modbus device on its own is a finding. Knowing that it belongs to a water treatment facility, runs a specific firmware version, and sits in a region where VOLTZITE has been active — that is actionable intelligence. External discovery without asset context produces scan results. Asset context without external discovery produces a false sense of security. You need both.
Map exposures to active threats. Not all exposures carry the same risk. An exposed BACnet controller in a commercial office building and an exposed DNP3 RTU at an electric substation have very different threat profiles — because different actors are targeting different protocols in different sectors. FrostyGoop went after Modbus. PIPEDREAM included modules for Modbus, CODESYS, and OPC UA. VOLTZITE targeted VPN appliances at utilities specifically. Prioritization should follow the threat, not just the CVSS score.
Connect remediation to compliance. For electric sector operators, NERC CIP requires electronic security perimeters around BES Cyber Systems — an exposed OT device is a direct compliance gap, not just a security risk. For all sectors, IEC 62443 zone and conduit models address isolation of legacy protocols from untrusted networks. When fixing an exposure also closes a compliance finding, the business case gets easier and the fix actually happens.
The air gap may be on your diagram. The question is whether it is on the internet.
ShiftSix Security discovers what your network diagram does not show. Request a complimentary external exposure assessment to see your OT environment from the attacker's perspective.
ShiftSix discovers what's exposed from the outside — the attacker's view of your OT environment.
Request a Complimentary Assessment
Continuous attack surface intelligence for IT, OT, and ICS environments — purpose-built for enterprise security teams and critical infrastructure operators.