Teams often mistake isolation for security and underestimate how attackers gain entry through connected vendors, remote access paths, modernisation projects, or convergence with IT systems. Air gaps reduce exposure, but they do not eliminate it. A realistic OT security program assumes compromise paths exist, then uses segmentation, monitoring, and recovery planning to contain them.
Why Air Gaps Fail as a Security Assumption in OT
OT teams usually get into trouble when they treat “air-gapped” as a property that remains true after maintenance access, vendor support, data replication, remote engineering, and business integration are added. In practice, the question is not whether an OT environment started isolated, but whether its current trust boundaries still match the operating reality. The CISA guidance on industrial control systems shows why this matters: connected support paths and weak boundary control are common ways isolation erodes over time, even when the plant still looks separate on paper. See NIST SP 800-207 Zero Trust Architecture for the broader principle that trust should be continuously evaluated rather than assumed.
Many teams also confuse reduced attack surface with no attack surface, which leads them to underinvest in segmentation, asset visibility, and recovery planning. That is especially dangerous in OT because operational continuity can force exceptions that quietly reopen paths into the environment. In practice, many security teams discover those exceptions only after a vendor session, remote access change, or integration project has already expanded the boundary.
How OT Connectivity Reintroduces Exposure
OT networks become reachable when organisations connect them to IT systems for reporting, monitoring, patching, analytics, or remote maintenance. Those links are often justified individually, but the cumulative effect is to replace a presumed barrier with a set of controlled and uncontrolled pathways. Once that happens, the important question shifts from “Is the network air-gapped?” to “Which paths exist, who can use them, and how quickly can they be cut off if something goes wrong?”
A practical OT model starts with boundary mapping. Teams need to identify every ingress and egress path, including vendor jump hosts, temporary maintenance connections, wireless bridges, portable media workflows, historian feeds, and identity integrations used for administration. They then need to decide which paths are permanent, which are time-bound, and which are compensating controls that must be monitored closely. This is where many programmes fail: they document the architecture once, then never reconcile it with actual operational changes.
- Validate the current trust boundary, not the original design diagram.
- Inventory all remote access and third-party support paths.
- Segment OT zones so one exception does not expose the whole environment.
- Monitor for changes in routing, remote tooling, and privileged access behaviour.
- Plan for containment and restoration if an allowed pathway is abused.
The control logic is straightforward: if a pathway is necessary, it should be explicit, limited, and observable. If it is not necessary, it should not exist. Where OT and IT convergence is already in place, the guidance breaks down when teams rely on policy language instead of technical enforcement, because the environment then depends on everyone remembering the exception list correctly.
When “Air-Gapped” Becomes a Useful but Misleading Shortcut
Tighter isolation often improves resilience, but it also creates a false sense of closure, so organisations must balance operational convenience against the assumption that “offline” means “unreachable.” In OT, that tradeoff is especially sharp during modernisation projects, because the environment may be partially segmented, partially remote-managed, and partially dependent on shared services. That is a genuine operational compromise, not a clean security state.
There is also a consensus gap in the industry around terminology. Some teams use “air-gapped” to mean physically disconnected. Others use it to mean “hard to reach from the internet.” Those are materially different claims, and only the first one is close to a strict air gap. If the question is about governance or risk acceptance, the language needs to match the actual dependency chain rather than the intended design.
Teams also underestimate how quickly exceptions become normal. A contractor laptop, a cloud-based engineering portal, or an emergency support workflow can turn a presumed boundary into a routine access path. The useful habit is to treat every exception as a control obligation with an owner, a review date, and a rollback plan. When that discipline is missing, “air-gapped” becomes a label that hides exposure instead of reducing it.
Risk and Threat Considerations
The material risk is not that OT is always directly internet-facing, but that organisations assume isolation still exists after connectivity, maintenance, and convergence have changed the environment. That assumption creates exposure through remote access, third-party support, and weakly monitored boundary crossings.
Failure mechanism: attackers or abusive insiders exploit trusted paths that bypass the original isolation model, such as vendor access, shared administrative tooling, removable media, or connected IT services. Once inside one reachable segment, they can often pivot toward OT assets if segmentation and privilege controls are weak.
Impact: the result can be loss of visibility, unsafe process manipulation, ransomware spread into operational environments, or prolonged recovery because the organisation misjudged how much separation actually remained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-5 — Network Integrity | Air-gap assumptions fail when network boundaries and trust paths erode. |
| PR.AC-3 — Remote Access is Managed | Vendor and remote support paths are a common way isolation is bypassed. | |
| DE.CM-8 — Vulnerability Scans | OT exposure grows when organisations lack visibility into changed connectivity. | |
| Recommendation — Enforce network integrity controls to limit OT reachability and constrain lateral movement. Manage remote access tightly and remove standing pathways that are not essential. Monitor boundary changes and validate exposure with continuous visibility checks. | ||
| CIS Controls v8 | 6 — Access Control Management | OT air-gap assumptions break when access paths are not governed and reviewed. |
| 12 — Network Infrastructure Management | Segmentation and boundary enforcement are central to OT isolation. | |
| Recommendation — Restrict and review access paths so implicit trust does not reopen OT boundaries. Segment OT networks and harden boundary devices to contain compromise. | ||
| MITRE ATT&CK | T1021 — Remote Services | Remote support is a common adversary path into supposedly isolated environments. |
| T1210 — Exploitation of Remote Services | Exposed OT support channels can be exploited for initial access or pivoting. | |
| T1090 — Proxy | Attackers often use intermediary hosts to traverse segmented environments. | |
| Recommendation — Hunt for remote-service abuse and alert on unexpected OT support sessions. Prioritise detection and hardening around remotely reachable OT services. Inspect intermediary hosts and proxies for staging, tunnelling, and pivot activity. | ||
Practitioner Guidance
What to prioritise: treat the current connectivity map as the control boundary. The first task is not to debate whether the network is “air-gapped,” but to prove which paths still exist and which of them are truly necessary.
What to verify: confirm that every remote access route, vendor workflow, and IT-OT integration has an owner, an approval basis, and a monitoring method. If a path cannot be named, reviewed, and revoked, it is already outside good control.
What good looks like: OT isolation is documented in terms of enforceable technical barriers, not marketing language or architecture slides. Teams can show segmentation points, access constraints, logging coverage, and a recovery path if one boundary is crossed.
Practitioner takeaway: the safest OT posture assumes that isolation decays over time, so resilience depends on proving and continually reducing reachable paths rather than assuming they do not exist.
Related resources from NHI Mgmt Group
- What do teams get wrong when they assume MCP logs are enough for accountability?
- What do teams get wrong when they treat evals as one-off checks?
- What do security teams get wrong when they rely on one-off findings instead of classes of bugs?
- What do teams get wrong when they assume new analytics dashboards will preserve existing reporting without rework?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
