The term “air-gapped” gets thrown around a lot in critical infrastructure and OT security conversations. The implication is clear: no network connection, no attack surface. Physical separation as the ultimate security control.
In practice, most “air-gapped” networks aren’t. And the ones that actually are can still be compromised — it’s just harder.
The Most Common Air Gap Myths
“There’s no connection between IT and OT”
During a recent engagement at a mid-sized manufacturing facility, the operations team was adamant their ICS network had zero connectivity to the corporate network. We found 11 connections between the IT and OT networks. Most were legitimate but undocumented — historian servers pulling data for reporting, a jump host set up three years ago for a vendor, a wireless access point installed “temporarily” during a maintenance window and never removed.
“USB drives are prohibited”
USB prohibitions are enforced by policy. Policy doesn’t enforce itself. Stuxnet — still the most famous ICS attack — traveled via USB. That was 2010. It’s still the most common vector we see in OT assessments today.
“Attackers can’t target systems they can’t reach”
They don’t need to. The standard OT attack chain: compromise an IT system with internet connectivity, lateral move toward OT boundary systems, abuse legitimate access paths (historian, jump host, vendor remote access), pivot into OT network. The air gap is only relevant at step 3, and if legitimate paths exist, it’s not actually a gap.
What Actual Air Gaps Look Like
I’ve seen maybe three genuinely air-gapped OT environments in five years. All three were in government or defence contexts. What they required: data diodes for one-way data transfer, formal media control procedures with cryptographic verification of USB content, physical access controls logging unauthorized USB insertion, OT-side network monitoring, and vendor access via jump hosts with full session recording.
What You Should Actually Do
If perfect air-gapping isn’t practical, the goal is verified segmentation with monitored crossing points: enumerate every connection between IT and OT, apply firewall rules at the boundary with default-deny, log and alert on all boundary crossings, implement regular OT-specific penetration testing to verify controls, and deploy passive network monitoring within the OT zone. Treat your OT network like it’s already compromised and build detection accordingly.
