Key Takeaways
- Critical infrastructure operators must prepare to isolate operational technology (OT) systems when normal cybersecurity controls fail.
- Identification of the minimum set of systems needed to sustain essential services is the first step; this goes beyond a generic asset inventory.
- Hidden IT dependencies (authentication, time, storage, etc.) can break isolation if not addressed inside the OT boundary.
- A complete map of all connections—corporate, cloud, vendor, peer‑utility, and wireless—is required before any disconnection can be planned safely.
- Isolation should be graduated, with pre‑defined trigger conditions tied to incident‑response playbooks, rather than an all‑or‑nothing switch.
- Physical separation of network hardware is the strongest protection; where infeasible, strong cryptographic separation (MACsec, IPsec) is mandated.
- VLANs and similar administrative controls are only interim measures; they cannot be relied upon as long‑term security boundaries.
- Regular, full‑scale testing of isolation procedures—including verification of continued service operation—is essential; paper plans alone are insufficient.
- After isolation, continuous monitoring, validation of reconnected devices, and management of patch/update gaps are required to avoid re‑introduction of threats.
- Data diodes or cross‑domain solutions may allow limited, one‑way flows of telemetry while maintaining isolation integrity.
- Building isolation capability is a board‑level resilience issue that involves funding, staffing, vendor contracts, and leadership decision‑making authority.
Preparing for compromise, not assuming prevention
The CI Fortify guidance shifts the focus from merely stopping intruders to ensuring that essential services can keep running after attackers have already breached parts of the network. It acknowledges that state‑sponsored actors, criminal ransomware groups, and even hacktivists can establish persistent footholds in OT environments, making prevention alone unrealistic. Operators are urged to assume that perimeter defenses may be overcome and to design the ability to “island” critical OT systems so that they can operate independently when wider networks are compromised.
Identifying the systems that truly matter
Before any disconnection can be planned, operators must pinpoint the minimum collection of control systems, communications links, safety equipment, and enabling services required to keep an acceptable level of service alive. This exercise is narrower than a generic “critical asset” list; it asks, for example, what an electricity provider needs to balance supply and demand, or what a water utility must keep running to maintain treatment and pumping. The analysis also extends to downstream customers—hospitals, emergency responders, military sites—so that service‑level targets (e.g., megawatts of power, litres of water per hour) can be defined and used as measurable goals for isolation planning.
Hidden IT dependencies can undermine isolation plans
Modern OT environments frequently rely on corporate IT for Active Directory authentication, DNS, DHCP, time synchronization, certificate management, storage, and backup services. If these dependencies lie outside the protected OT boundary, pulling the plug on corporate networks can inadvertently strip OT systems of essential services, causing the very outage the isolation was meant to prevent. CI Fortify therefore calls for building local, independent capabilities inside OT—such as dedicated identity services, DNS servers, time sources, and backup infrastructure—so that the protected environment can survive disconnection without losing vital support functions.
Every connection must be mapped before it can be disconnected
A comprehensive inventory of all pathways into and out of the vital OT zone is a prerequisite for safe isolation. Operators must document links to corporate networks, cloud platforms, vendor maintenance systems, managed service providers, consultants, peer utilities, and any wireless or satellite connections. For each connection, the record should capture the owner, third‑party provider, protocols in use, business purpose, operational importance, recovery‑time/objective metrics, and emergency contacts. Accurate diagrams, firewall rules, router VPN settings, and gateway details should be kept up‑to‑date through ordinary change‑management processes, ensuring that the isolation plan remains valid as the network evolves over decades of service life.
A graduated path toward full disconnection
Rather than treating isolation as a binary on/off switch, the guidance recommends a staged response that scales with threat severity. In a sample electricity‑transmission scenario, an operator first cuts remote‑worker access via jump hosts, then removes on‑premises remote access, separates corporate IT from OT, disconnects lower‑priority peer links, and finally isolates the core OT systems if needed. Each stage should have pre‑defined trigger conditions—such as evidence of credential theft, compromise of a remote‑access gateway, unusual routing changes, or intelligence of an imminent campaign—embedded in the incident‑response plan. Pre‑authorising decisions avoids delays that could give attackers more time, while also preventing unnecessary service disruption if isolation is triggered prematurely.
Physical separation remains the preferred end state
The strongest form of protection is complete physical separation: critical OT hardware does not share switches, routers, compute platforms, or power supplies with lower‑trust networks. Management interfaces are isolated wherever possible, and administrative access is provided through dedicated out‑of‑band channels or privileged‑access workstations. Where geography permits, dedicated fibre pairs or wavelengths can carry critical traffic without mingling with non‑critical services. When full physical separation is impractical—because operators must use public telecom, carrier services, or cloud platforms—the guidance mandates strong cryptographic separation (MACsec for Layer 2, IPsec or encrypted tunnels for Layer 3) with encryption devices hardened, patched, and administered solely from trusted systems inside the critical security domain.
VLANs are an interim measure, not an air gap
CI Fortify is explicit that virtual LANs, access‑control lists, route maps, and black‑hole routes are merely configuration‑based controls. An attacker who gains access to the network‑management plane can alter or disable them, rendering VLAN‑based separation ineffective as a long‑term boundary. VLANs may be used as a temporary stopgap when stronger physical or cryptographic isolation is not yet available, but organisations should prevent automatic VLAN propagation, restrict permissible VLANs on trunk links, disable trunk negotiation, and keep internet‑facing zones off shared switching infrastructure with OT. Similar cautions apply to software‑defined networking and orchestration platforms, which introduce abstraction layers that could be subverted if the orchestrator itself is compromised.
Isolation must be tested as a complete operational event
A paper plan is insufficient; operators must conduct regular, full‑scale exercises that involve all vital systems, not just a single site or segment. Tests should verify that staff can execute the isolation procedure, that essential processes continue to function, that alternative communication channels work, and that required third parties can be reached without relying on the network being disconnected. The UK NCSC’s severe‑threat guidance similarly urges rehearsals of network islanding, credential invalidation, restoration from trusted backups, and, in extreme cases, rebuilding networks from scratch. Keeping a secure offline or printed copy of the isolation plan ensures that documentation remains available even if the corporate network is compromised.
Disconnection does not end the security problem
After isolation, defenders must confirm that the boundary is holding. Routing tables on both critical and non‑critical systems should be inspected for static routes or unexpected adjacencies that could permit traffic to leak across the divide. Network‑flow monitoring and intrusion‑detection sensors must remain active at key points, with reachability tests used to verify that prohibited connections have not been restored—whether accidentally or maliciously. Special attention is needed for the network‑management plane: if an attacker retains administrative control of a router, firewall, or orchestration platform, they could reverse the isolation action even if normal user traffic appears blocked. Additionally, prolonged isolation creates new risks—systems may fall behind on patches, threat‑intelligence feeds may lapse, and reliance on removable media for file transfers increases the chance of introducing malware via infected USB drives. Consequently, reconnection must be treated as a controlled security operation: any device, data, or software introduced during isolation must be validated, routes reviewed, and monitoring maintained to detect any surviving adversary.
Data diodes may preserve limited flows
For situations where some telemetry or narrowly defined information must continue to exit the isolated zone, CI Fortify points to data diodes and cross‑domain solutions. A data diode enforces hardware‑based one‑way communication, preventing any return traffic on the same path. Cross‑domain solutions can add sophisticated filtering and policy enforcement between networks of differing security levels. When properly designed, these mechanisms allow essential data flows to persist during extended isolation while offering stronger assurance than a conventional firewall. However, the guidance warns that such devices demand specialist design, installation, and ongoing maintenance; misconfiguration can break protocols that rely on two‑way handshakes and undermine operational integrity.
Resilience becomes a board‑level responsibility
Ultimately, the guidance situates isolation planning within the broader discipline of operational resilience. Building an OT environment that can run independently may require duplicate hardware, alternative communication paths, local support teams, tested backups, revised vendor contracts, and additional staffing. Leaders must also anticipate competition for scarce resources—fuel, chemicals, spare parts, incident‑response expertise—during a regional or national crisis. Because these decisions involve cost, risk appetite, and service priorities, they cannot be delegated solely to the security team. The Canadian Cyber Centre advises boards and senior executives to discuss how the organisation would operate under prolonged isolation, clarify who holds authority to make emergency decisions, and ensure that essential functions can survive a cyberattack or systemic failure. NCSC’s resilience guidance echoes this, placing the onus on leadership to guarantee continuity of critical services. CI Fortify stresses that achieving full physical isolation may be a gradual journey; each eliminated dependency and each hardened boundary reduces risk incrementally, but the end goal is clear: the most vital OT systems must be capable of surviving without the wider networks that normally surround them.