The failure mode is assuming that physical or logical separation still exists after remote support, cloud integration and vendor connectivity are added. Once those paths are present, the real control problem is access governance. Organisations lose visibility into who can reach which assets, and they often discover that old network boundaries no longer match operational reality.
Why This Matters for Security Teams
Treating OT as air-gapped creates a false assurance problem: the site may still have segmented networks, but remote support, vendor maintenance tunnels, engineering workstations, historians and cloud dashboards can reintroduce reachable paths that were never documented in the original boundary model. That shifts the real risk from “can an attacker route into OT” to “who can authenticate, approve, and monitor the paths that already exist.” The operational impact is broad because OT environments often prioritise availability and safety, which makes hardening slower and changes harder to reverse. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls emphasises access control, account management and system monitoring, but those controls only work if the asset inventory and trust boundaries are accurate. NHIMG research on Schneider Electric credentials breach shows how access and credential exposure can become a systemic issue once operational connectivity extends beyond the plant floor. In practice, many security teams discover the OT boundary only after remote access has already been standardised by operations and vendors, rather than through intentional architecture review.
How It Works in Practice
The practical failure starts when “air gap” is used as a policy label instead of an enforced control set. OT environments often include a mix of flat networks, jump servers, remote support portals, cellular maintenance links, and business-to-plant data flows. If those pathways are not continuously governed, the organisation no longer has a meaningful separation story. A better model is to treat each connection as a trust decision and map it to identity, device, session, and purpose controls.
That means tracking who can initiate access, what conditions must be met, and how the session is recorded. The most useful questions are usually operational, not theoretical:
- Is remote vendor access brokered through approved jump hosts or direct into controllers?
- Are shared accounts, service credentials, or long-lived VPN profiles still in use?
- Can engineers prove which assets are reachable from IT networks, cloud services, and third-party support tooling?
- Is every access path logged in a way that security operations can review after the fact?
For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a strong baseline for account, access and audit requirements, while DeepSeek breach illustrates the broader lesson that exposed credentials and undocumented trust paths turn “internal” systems into externally reachable targets. In OT, that same pattern often appears when engineering laptops, remote management software or supplier integrations are trusted more than the plant architecture itself. These controls tend to break down in brownfield plants with legacy PLCs, shared operator workstations and vendor-maintained remote links because the environment cannot easily support modern identity binding or per-session enforcement.
Common Variations and Edge Cases
Tighter OT access control often increases operational friction, so organisations must balance resilience against maintenance speed and safety response time. There is no universal standard for every plant topology, especially where legacy assets cannot support modern authentication or segmentation telemetry.
Some environments really are highly isolated, but that is rarer than teams assume. Once wireless, third-party telemetry, cloud reporting or emergency support paths exist, the “air-gapped” label becomes misleading. In those cases, best practice is evolving toward compensating controls: stricter remote access approval, limited-time vendor sessions, dual authorisation for critical changes, and continuous review of all trust relationships. For high-consequence sites, this is where identity governance becomes an OT control problem, not just an IT one, because credentials and operator privileges are the functional equivalent of network reachability.
Another edge case is segmented OT that still depends on shared administrative pathways. The network may be well designed, but if a single engineer account can reach many zones, the segmentation can be bypassed through legitimate access. The most effective response is to align the trust model with real operational dependencies and then validate it with incident drills, not just architecture diagrams.
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, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | OT air-gap assumptions fail when access governance is weak or undocumented. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management is central when remote support and vendor accounts reach OT assets. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero trust is the right model when OT boundaries are no longer physically isolated. |
| NIS2 | Critical infrastructure operators need governance over third-party and remote access paths. |
Treat each OT connection as untrusted by default and verify identity, device and context every time.
