Your OT Isolation Plan: What You Can Actually Disconnect When It Matters

It’s Tuesday afternoon and word comes in that an integrator with remote access to your environment has been compromised. The compromise isn’t in your network; it’s in theirs. Nobody can tell you yet whether anything moved through that connection.

What do you disconnect?

For a lot of organizations, the honest answer is everything or nothing, because that’s the range their OT isolation plan actually covers. Pull the uplink and lose remote support, historian replication, and your own visibility along with the risk. Or leave it up, watch, and hope.

An OT isolation plan defines which external connections, services, vendors, data flows, and sites can be disconnected during an incident without creating a larger operational or safety problem.

The Secure Connectivity Principles for Operational Technology, published by NCSC-UK with CISA, the FBI, and partner agencies in Australia, Canada, Germany, the Netherlands, and New Zealand, closes with Principle 8: establish an isolation plan. The seven before it walk through connectivity design in order: balance the risks and opportunities, limit the exposure of your connectivity, centralize and standardize network connections, use standardized and secure protocols, harden your OT boundary, limit the impact of compromise, and log and monitor all connectivity. Principle 8 covers what happens when all of that has to be cut. It’s the least discussed of the eight, and it’s the one that decides how that afternoon goes.

Three Ways an OT Isolation Plan Can Work

Guidance describes three isolation strategies, ordered by what they require.

1. Disconnect the whole site.

If your network is flat, meaning everything sits on one network with no segmentation separating systems from each other, this is your only option. Cut every external connection at once, either by physically unplugging or by changing rules on the network device that controls those connections. Guidance adds a condition worth catching: if you isolate by rule change, that device has to be one you trust and keep patched, because you are now depending on it entirely. Isolating through equipment you don’t trust isn’t isolation.

2. Cut one service and leave the rest running.

This becomes possible once the network is segmented, meaning divided into zones, with controlled paths governing what crosses between them. Segmentation is the foundation. On top of it sit the connection controls the guidance describes: routes consolidated into a small number of known paths, remote access brokered through a controlled gateway rather than pointed directly at control equipment, and vendor access enabled when required and switched off the rest of the time. When those things are true, every connection is a separate switch. The worked example in the guidance is almost exactly the Tuesday scenario. The compromised integrator loses access, every other vendor keeps working, and you turn that one connection back on when the risk is resolved.

3. Go dark but keep the data flowing out.

This one is designed in from the start, typically with a data diode. A diode enforces direction physically rather than through configuration, so data can leave the environment and nothing can come back through it. That means telemetry and logs keep flowing while everything else is cut, so you isolate without losing sight of the environment.

Line the three up and what escalates is segmentation. The first assumes none of it. The second depends on logical segmentation, where zones and the rules between them are defined in configuration. The third depends on physical segmentation, where the separation is built into hardware and cannot be reconfigured away. Every step has to be architected in advance.

If you’re on the first strategy and the second looks like a capital project, the cheapest move toward it is usually consolidating remote access. Routing every vendor through one brokered path turns a dozen uncontrolled entry points into a single switch you own, which is the switch you want on Tuesday. It can be done without re-architecting the plant.

All three share a floor. Principle 2, limit the exposure of your connectivity, notes that network edges in OT are hard to identify, offering the example of an unsecured radio link inside an OT network that never appears on a diagram while still forming part of the edge. An isolation plan covers connections somebody wrote down. The undocumented cellular gateway an integrator left in a cabinet survives all three strategies, because nobody knows to cut it.

Segmentation At Sea

Ships solve this with watertight compartments, which is physical segmentation in its oldest form. The hull is divided by bulkheads, each with doors that seal, so flooding in one section doesn’t take the whole vessel down.

Three things make that work. The bulkheads went in during construction. The crew has drilled which door to close and how fast. And somebody already decided what the ship can afford to lose behind a sealed door.

Miss any one of those and the compartments stop mattering. Compartments nobody has drilled are one big compartment and some extra hardware.

Guidance requires the first two in plainer language. Isolation planning belongs in the system design process so that isolating doesn’t create consequences nobody anticipated, and the plan should be tested regularly to confirm it works and doesn’t take down services it was never meant to touch. There is a third requirement with no shipboard equivalent: the plan has to sit inside wider business continuity planning.

The third condition, deciding in advance what gets left behind a sealed door, is the one almost nobody writes down.

What OT Isolation Plans Usually Leave Out

Your vendors have to drive. Guidance is explicit that isolation plans should account for contractual arrangements with third parties and suppliers, including the requirement to switch from remote support to physically attending site. If your control system vendor is a long drive or a flight away, isolation has changed your time to repair, your travel budget, and who needs to be on site to escort them.

Some connections have to stay up. For organizations running multiple sites, guidance calls for site-specific plans plus a larger strategy covering the case where shared infrastructure is compromised and could carry an attacker across every location. Planning at that scale means naming the data flows that must keep running. Some need exemptions, particularly where losing them would cause national-level impact or create unsafe operating conditions, and guidance points to hardware controls like diodes to carry those flows safely during a compromise.

That exemption list is the hardest artifact to produce and the most valuable one. It forces a decision nobody wants to make under pressure: which connections can we operate without, and which do we keep even knowing the environment may be compromised?

Isolating Without Going Blind

Back to the cost named at the top. Cutting every external connection also cuts any monitoring that depends on a link out, so the moment you most need to know what’s happening inside the environment can be the moment you stop being able to see it.

The third strategy has its own version of the problem: when telemetry keeps flowing during isolation you may need additional monitoring to confirm the incoming data still matches expected value ranges. Keeping a link up and trusting what comes across it are separate decisions. A useful OT isolation plan should preserve enough local visibility to confirm whether isolation changed traffic, relationships, or behavior inside the environment.

That’s the argument for keeping visibility on the isolated side, independent of any link back out. Internal traffic doesn’t stop when the uplink does, and the record of which devices are talking, what they’re doing, and whether any of it changed after isolation is what tells you whether the isolation worked. It’s the layer EmberOT is built around, and the principle holds regardless of what you use.

The Question to Ask Before You Connect Anything

Principle 1, balance the risks and opportunities, covers the decision made before a connection exists. It asks organizations to record, in the business case for every new connection, whether that connection will make the system reliant on external services and therefore harder to isolate during an incident.

Almost nobody writes that down. Every connection added without asking moves an environment further from selective isolation and closer to all or nothing, one convenience at a time.

The same principle asks whether operations can continue manually when connectivity is degraded or lost, and whether there’s a clear, tested procedure for doing it. Isolation and manual operation are the same conversation. What you can afford to disconnect is bounded by what you can still run afterward.

Grade Your OT Isolation Plan in Six Steps

Pull up your network diagram and your support contracts. Most of what follows comes from those two documents. One item needs a walk.

1. Name the connections you’d cut first. 

Vendor remote access, historian replication to the business network, cloud telemetry, ERP and business system links. Then go looking for the ones nobody listed, because the diagram only knows what somebody drew on it.

2. Check whether they can be cut individually. 

If revoking one vendor’s access means dropping every vendor, you have the first strategy regardless of what the diagram suggests.

3. Find out what breaks. 

For each connection, what stops working, what degrades, and what stops safely. Some processes fail safe and some fail in place, and the difference matters more than the connection itself. Note which of them carry your own monitoring and logging.

4. Read the support contracts. 

What happens when remote access is unavailable, what the on-site response commitment actually is, and what it costs.

5. Decide the exemptions now. 

Which flows stay up during isolation, on what technical basis, and who has authority to approve it at two in the morning.

6. Cut one during a planned window. 

Pick the lowest-consequence connection and actually disconnect it. A plan nobody has executed is a hypothesis.

The Plan Is the Architecture

Principle 8 ends on this. Investing in controls that manage connectivity risk reduces the operational risk of isolation, and if you can trust that services are properly isolated, you can take a more targeted approach and reduce business impact.

Run that logic in reverse and it becomes the case for the seven principles ahead of it. Limiting exposure, centralizing connections, hardening the boundary, containing the blast radius of a compromise. Every one of them buys options on the day you start cutting.

An OT isolation plan isn’t a document you write. It’s an inventory of choices you already made.