Air gapping breaks down when it no longer reflects how industrial environments actually operate. Modern OT often needs controlled connectivity for business functions, monitoring, and maintenance, so the boundary becomes unclear. When teams cannot tell which systems are truly isolated, security gaps emerge, especially around trust assumptions, access paths, and hidden dependencies.
What fails when air gapping is treated as the primary control
Air gapping only works when the isolation boundary is real, stable, and fully understood. In OT, that assumption often fails because plants need monitoring, patching, remote support, historian feeds, vendor access, and business data flows. Once those connections exist, the control becomes a policy statement rather than a security boundary, and risk shifts to hidden dependencies, unmanaged trust paths, and exceptions.
The practical failure is not that isolation is useless, it is that teams mistake “separate network” for “separate trust domain.” When connectivity exists but is undocumented or informally approved, defenders lose visibility into where access originates, who can reach what, and which assets still depend on outside systems.
Why the boundary becomes ambiguous in real OT operations
OT environments rarely stay perfectly sealed. Engineering workstations, jump hosts, remote maintenance channels, vendor support, file transfers, and data replication all create controlled openings. If those openings are treated as exceptions instead of first-class parts of the architecture, the organisation cannot reliably say which systems are isolated and which are only partially exposed.
That ambiguity creates a control gap: teams may continue to trust the “air gap” label even after connectivity has been introduced through removable media, remote administration tools, or one-off business integrations. In that state, the issue is not just connectivity, it is the loss of a defensible trust model.
For OT-specific guidance on segmentation, threat assumptions, and real-world architecture constraints, see NIST SP 800-82 Rev 3, OT Security Guide and CISA Industrial Control Systems. Where the hidden dependency is credential-driven remote access rather than pure network design, the failure mode is often better understood through Schneider Electric credentials breach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Air-gap failure is fundamentally a trust and access-path problem in OT. |
| PR.PT — Protective Technology | OT isolation depends on protective network and segmentation technology, not labels. | |
| DE.CM — Continuous Monitoring | Hidden OT dependencies require ongoing visibility into actual connectivity. | |
| Recommendation — Define and enforce access boundaries for every OT exception path. Use protective technologies to constrain and monitor OT connectivity. Continuously monitor OT pathways and exception channels for drift. | ||
| CIS Controls v8 | CIS 6 — Access Control Management | OT exception paths rely on accounts and remote access that need governance. |
| CIS 12 — Network Infrastructure Management | Air gapping breaks down when network segmentation and flows are not governed. | |
| CIS 8 — Audit Log Management | Ambiguous trust boundaries demand logs that reveal who reached what and when. | |
| Recommendation — Inventory and restrict all OT remote access and privileged pathways. Segment OT networks and document every permitted cross-boundary flow. Log OT administrative and boundary-crossing activity for review and detection. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Explicit Access to Resources | Zero trust replaces implicit air-gap trust with explicit, verified access decisions. |
| 2.0 — Zero Trust Architecture Principles | OT environments with mixed connectivity need continuous trust evaluation. | |
| Recommendation — Require explicit verification for every OT access request and connection. Design OT access around continuously evaluated trust boundaries, not isolation assumptions. | ||
Practitioner Guidance
What to verify: Treat every exception path as part of the security boundary. Verify whether remote maintenance, vendor tooling, historian exports, backup processes, and patch workflows can reach production control assets, and document the exact systems, accounts, and protocols involved.
What to measure: Track how many OT connections are permanent, how many are approved only informally, and how many are dependent on credentials or shared admin paths. If the count of exceptions is rising, the environment is moving away from true isolation even if the network diagram still shows an air gap.
Common mistake: Teams often secure the perimeter while leaving exception handling unmanaged. That leaves the most dangerous paths, such as maintenance access and data transfer workflows, outside routine review even though they are the channels most likely to bypass the intended isolation model.
Practitioner takeaway: In OT, the question is not whether air gapping once reduced exposure, but whether the current operating model still preserves a clear, auditable trust boundary. If not, the control should be replaced or supplemented with segmentation, access governance, and continuous visibility.
