Why OT Isolation Is Harder Than the Advisory Says
CISA and ASD's joint OT isolation guidance is correct in what it recommends. What it leaves to inference is the physical-layer reality that makes the recommendation hard to execute.
Loop The joint CISA/ASD guidance on OT isolation published July 28 is correct. Pre-plan the isolation. Map which OT systems run standalone and which need the network. Define the trigger conditions before an incident makes that decision under pressure. Test the procedure. All of that is right.
What the advisory leaves to the reader is the field reality that makes those steps technically non-trivial — not as a criticism of the guidance, but because a joint advisory covering energy, water, transportation, and manufacturing can only describe the architecture in the abstract. The specific implementation problems don’t fit in a PDF.
The baseline assumption the advisory starts from
The guidance treats OT isolation as a network decision: segment, disconnect, re-route. In a well-architected environment with modern equipment and clean network boundaries, that framing is accurate enough. The issue is that most operational environments were not built with isolation in mind. They were built to run continuously, for decades, with reliability as the primary constraint. Security was not in the original design requirements for a PLC installed in 1998.
What the physical layer actually looks like
Proprietary protocols with no isolation handling. Modbus, DNP3, PROFINET, and EtherNet/IP are deterministic control protocols. They were designed to move process data reliably on isolated networks, not to tolerate the latency of a firewall traversal or a VLAN re-assignment. Devices using these protocols often poll sensors or actuators on fixed cycles measured in milliseconds. Interrupting that cycle — even briefly, even for a network change — can generate alarm states, cause a controller to fall back to a safe or unsafe default, or simply stop accepting commands from the HMI.
Isolation means knowing which of your OT devices have that dependency and in what order they can be safely disconnected. That map has to be built before the incident.
The bridged engineering workstation. Engineering workstations are where the hard problem lives. They need to reach the OT network to program and commission controllers. They also need to reach the enterprise network for email, documentation, and vendor support portals. In a properly segmented environment, those paths are controlled and logged. In most environments that exist right now, the engineering workstation is on both networks through a second NIC, a software bridge, or an explicit firewall exception that was created in 2014 and never reviewed.
That bridged workstation is, consistently, the path that enterprise ransomware uses to reach OT networks. Closing it at isolation time requires knowing it exists.
Vendor remote access paths. OT equipment vendors frequently require persistent remote access for support, calibration, and firmware updates — connections established during commissioning and never formally decommissioned. These paths often run through VPNs, cellular modems attached directly to field devices, or third-party remote support platforms. They exist outside the primary network diagram. An isolation procedure that shuts down the primary OT VLAN while leaving an active vendor tunnel on a field device has not isolated the environment.
Mapping those paths is the most labor-intensive part of building a real isolation procedure, and it’s the part most likely to be incomplete.
Physical-consequence sequencing. For some processes, isolation and safe operation are not compatible at the same moment. A batch reactor mid-process cannot simply be disconnected from its SCADA historian without knowing where it is in the cycle. A water treatment plant running a chlorination sequence needs its dose control to complete before the control network is severed. Isolation procedures in these environments require process engineers to define the safe-disconnect windows — the conditions under which a clean separation is possible without causing a safety or quality incident on the process side.
The CISA guidance implies this by calling for rehearsed procedures. The rehearsal only surfaces these constraints if the right people are in the room.
The specific thing to do first
The vendor remote access map is where most environments are most incomplete and most exposed. Start there. Pull every vendor support contract for field devices on your OT network. For each one, ask whether there is an active remote access path, what equipment it terminates on, what authentication it uses, and who holds the credentials. If you can’t answer all four questions for a device on your OT network, you don’t know your isolation surface for that device.
That map is the prerequisite for a tested isolation procedure. Build it first.
Sources: CISA/ASD joint guidance via BleepingComputer; see also our coverage of the joint advisory.
Found this useful? Share it.
