The air gap has a reputation problem in both directions. Half the industry treats it as obsolete theater; the other half treats it as a force field. Both are wrong. A physically isolated SCADA network is a legitimate - sometimes mandatory - architecture for high-consequence facilities, and it is also one of the most commonly mismanaged. This guide covers when regulation or policy genuinely requires an air gap, why the gap alone is not security (Stuxnet settled that argument), how to run offline updates and patch discipline inside the gap, how to monitor without internet, how the gap maps to compliance frameworks, and the hybrid patterns that get you visibility without punching holes.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
A true air-gapped SCADA deployment has no routed network path between the control network and anything else - not the internet, not the corporate LAN, not a vendor support tunnel that "only gets turned on when needed." Servers, historians, HMIs, and engineering workstations all live inside the isolated network, and anything that crosses the boundary - software, patches, exported reports - crosses by a deliberate, manual, logged process.
Three things commonly get called air gaps but are not: an on-premise deployment behind a firewall (there is still a path; it is just filtered), a network with a "temporary" remote-access VPN for the integrator (a path that exists sometimes is a path), and a segmented OT zone with a data DMZ (excellent architecture - but that is defense in depth with conduits, not an air gap). The distinction matters because each of these has different failure modes, different compliance stories, and different operating costs. If you are choosing between them, our honest cloud vs on-premise security comparison lays out the full decision, and the original cloud vs on-premise SCADA comparison covers the operational and cost side.
Hard legal mandates for a literal air gap are rarer than vendors of isolation hardware imply. Where they exist, they cluster around the highest-consequence facilities: certain nuclear applications, defense and other government-accredited systems, and some classified or export-controlled environments. Corporate policy is the more common driver - an internal standard that says the safety or control layer of a specific process shall have no external connectivity, full stop.
Most sector frameworks stop short of demanding isolation. The NERC CIP standards require identified electronic security perimeters with controlled and monitored access points - a discipline about the boundary, not a prohibition of one. ISA/IEC 62443 is built entirely around zones and conduits, which presumes connections exist and governs them. AWIA Section 2013 requires water utilities to assess cyber risk; TSA pipeline security directives require segmentation between IT and OT and a plan for it. In every one of those regimes, a well-governed conduit is compliant. So the honest first question is not "how do we air-gap this?" but "which specific requirement or risk decision demands zero connectivity, and have we written it down?" If you can state it, the air gap is a rational answer. If you cannot, you may be about to pay the air gap's operating costs for a policy nobody actually holds.
The air gap eliminates one attack path - the network. Every other path still exists, and history has used all of them. Stuxnet is the canonical case: around 2010 it was discovered inside Iran's isolated uranium enrichment facilities, having crossed the gap - the US government's primary Stuxnet advisory (ICSA-10-272-01) documents its spread via removable media and network shares - and it proceeded to damage centrifuges while feeding operators normal-looking data. No internet connection was involved at any point. The lesson generalizes far beyond sabotage-grade attackers: commodity malware rides in on USB drives and contractor laptops without anyone targeting you at all.
There is a second, quieter failure mode: isolation decay. Air-gapped networks tend to rot from the inside because the friction of the gap discourages hygiene. Patching lags for years because updates are inconvenient. Accounts are shared because there is no SSO. Malware that does get in stays undetected for months because no monitoring looks inward. The gap becomes a reason to skip every other control - which inverts its value entirely. Treat the air gap as one strong control at one boundary, sitting inside the same defense-in-depth expectations as any other architecture.
| Path | How It Crosses | The Control That Closes It |
|---|---|---|
| Removable media | USB drives carrying updates, project files, or malware | Dedicated, scanned, freshly-formatted transfer media; kiosk scanning station; port lockdown on all other USB |
| Transient laptops | Engineering and vendor laptops plugged into the control network | Dedicated in-gap engineering workstations; no dual-homed devices; quarantine and scan policy for anything that must connect |
| Vendors and contractors | Support visits, commissioning tools, preloaded equipment | Supervised access, signed media procedures, contractual security requirements, logged sessions |
| Insiders | Deliberate or careless staff actions inside the gap | Named accounts, least privilege, audit trails, separation of duties, offboarding discipline |
| Supply chain | Compromised software or hardware installed as trusted | Signature verification of all installed artifacts, vendor security vetting, integrity checks at install time |
Notice that every one of these controls is procedural or identity-based, not network-based. That is the practical meaning of "the air gap is not security by itself" - the security program inside the gap is what does the work.
The single biggest operational risk in air-gapped SCADA is the update you never applied. A repeatable offline procedure keeps the gap from becoming an excuse:
Vendor choice matters enormously here. Ask any vendor offering on-premise deployment to walk you through their offline update path in detail: how releases are packaged, how signatures are verified without internet access, and how often on-premise customers actually receive updates. Merobix supports fully on-premise and air-gapped installation, publishes signed release artifacts with verification as part of the install path, and is building immutable, versioned gateway installs with atomic activation and rollback to make the offline update procedure safer still. What the software vendor should certify versus what you must operate is its own topic - covered in our companion guide to on-premise SCADA certifications.
Everything a cloud SOC would watch from outside must exist inside the gap, self-contained:
An air gap simplifies some audit conversations and sharpens others. Boundary-control requirements (NERC CIP electronic security perimeters, IEC 62443 zone definitions, TSA segmentation duties) are largely satisfied by demonstrating the isolation - but auditors then focus on exactly the topics this guide covers: media control procedures, patch currency, account management, and internal monitoring, because those are where isolated systems fail. Expect to produce the transfer log, the patch schedule with actual dates, the access review records, and evidence that audit trails are protected. NIST SP 800-82 Rev. 3 is the reference most US auditors reach for on all of these, and IEC 62443-2-1 - part of the ISA/IEC 62443 series - describes the standing program they expect the operating organization to run. In other words: the gap gets you past the connectivity questions and directly into the program questions - with nowhere to point but your own operations.
Most operators who need isolation do not need it for everything. The mature pattern separates the control layer from the visibility layer:
This is also where platform choice compounds: Merobix runs the same platform cloud-hosted, on-premise, or fully air-gapped, so a mixed fleet does not mean two SCADA products, two training programs, and two sets of screens. The architecture details are on the security page.
Key takeaway: An air gap is a boundary control, not a security program. Deploy it where consequence or regulation demands zero connectivity - then staff the program that makes it real: verified offline updates on a calendar, dedicated transfer media, named accounts with least privilege, in-gap monitoring with protected audit trails, and a written answer to "which requirement demands this gap?" A neglected air-gapped system is not safer than a well-run connected one; it is merely quieter about its problems.
An air-gapped SCADA system runs entirely on a network that is physically isolated from the internet and from corporate IT - no routed path exists in or out. All servers, historians, HMIs, and engineering workstations live inside the isolated network, and any data or software that crosses the boundary does so through a controlled manual process such as verified removable media. The air gap is a network architecture decision, usually driven by policy, regulation, or risk appetite at high-consequence facilities. It is not the same thing as an on-premise deployment with a firewall: on-premise systems typically still have some connectivity, while a true air gap has none.
No. An air gap removes the internet as an attack path, but it does nothing about the paths that remain: removable media, transient laptops, vendor and contractor equipment, insiders, and compromised software or hardware entering through the supply chain. Stuxnet demonstrated this definitively - it crossed into isolated Iranian enrichment facilities around 2010, most likely on removable media, and damaged centrifuges without any internet connection. Worse, air-gapped networks often decay internally: patches lag because updating is inconvenient, accounts are shared, and monitoring is thin because nobody is watching from outside. An air gap is one strong control at one boundary, and it must be surrounded by patching, media discipline, access control, and internal monitoring to constitute security.
Through a controlled offline update procedure. The vendor publishes a release package with cryptographic hashes or signatures; you download it on a connected system, verify the signature, scan it, and write it to dedicated, freshly-formatted transfer media. Inside the gap, verify the hash again before installation, apply the update in a maintenance window with a tested rollback plan, and record the whole transaction - who carried what across, when, and what changed. The discipline matters more than the tooling: air-gapped systems that skip updates because the process is painful end up running years-old software, which quietly converts the air gap from a security control into a security liability.
Not directly - remote access would break the gap. The accepted pattern for getting operational data out without creating an inbound path is a unidirectional gateway or hardware data diode: process data flows one way, outward, to a replica historian or monitoring system on the connected side, and nothing can flow back in. That gives managers and remote engineers read-only visibility while control remains isolated. Inside the gap itself, monitoring must be self-contained: a local historian, local alarming, local log collection and review. Many operators land on this hybrid - safety-critical control stays air-gapped while a one-way mirror feeds dashboards outside.
Genuine hard requirements are rarer than commonly believed. Certain nuclear, defense, and other government-connected facilities operate under rules or accreditation regimes that mandate isolation, and some corporate security policies impose it for highest-consequence processes. Most sector frameworks - NERC CIP, AWIA, TSA pipeline directives, IEC 62443 - require strong segmentation, controlled conduits, and monitored boundaries, but do not mandate a literal air gap. If your driver is policy rather than regulation, weigh the real costs: slower patching, no vendor telemetry, harder support, and heavy update logistics. Choose the air gap deliberately where consequence justifies it, not as a default security posture.
Merobix runs cloud-hosted, on-premise, or fully air-gapped - signed releases, immutable audit trails, and local alarming that work with zero external dependencies. See it against your isolation requirements.