Knowing how to pull the plug: four agencies on isolating vital systems

A capability, not a switch

There is a line that recurs at every industrial security conference: if there is a serious attack, we disconnect. Put that way it is reassuring and empty, because it hides the real question — can you, actually? And if so, what keeps working while you are disconnected?

On 28 July 2026 four national agencies — the United States' CISA, Australia's ASD, the UK's NCSC and the Canadian Centre for Cyber Security — published a sixteen-page joint document titled "CI Fortify — Advice for isolating vital systems", which takes that question seriously.

The thesis is blunt and sits in one line the document states prescriptively: organisations must build physical isolation points into their vital systems to enable the capability to operate in a state of isolation from all other networks and systems. Not "should consider": must build.

Six steps to get there

1. 01
   1-2

   identify vital systems and networks, and critical customers
2. 02
   3

   establish common levels of criticality and trust for networks and hosts
3. 03
   4

   map connections to vital systems and identify potential isolation points
4. 04
   5-6

   build separation and isolation points; create and test the isolation plan

The order is not decorative. The first three steps are about knowledge, not technology, and they are the ones almost always missing: most organisations have no shared list of what is genuinely vital, nor a criticality scale that means the same thing to process engineering and to IT.

The fourth step — mapping connections — is the one that produces surprises. In industrial practice, dependencies between office and plant environments accumulate over years, one at a time, each for a good local reason, and nobody keeps the running total.

The eight dependencies to sever

The document is concrete exactly where it needs to be, listing the technology areas where the two networks tend to be tied together:

• unified routing and switching;
• document management for configurations, firmware and binaries;
• shared virtualisation;
• shared SAN and NAS;
• backup and recovery services;
• common identity, DNS and DHCP — typically a single Active Directory;
• PKI and certificate services;
• time synchronisation (NTP/PTP) from corporate or internet sources.

The last two are worth pausing on, because they most often go unnoticed. An industrial environment that draws its certificates from the corporate PKI, or its time from a corporate NTP server, cannot be isolated: the moment it disconnects, certificates stop renewing and clocks drift apart. These are invisible dependencies while everything works, and decisive precisely when autonomy is needed.

On physical separation the text is categorical: to be physically separate, OT networks must not share any active infrastructure with non-OT networks — no shared switches, routers, repeaters, multiplexers or compute elements.

The graduated plan: five rungs, not a switch

The most useful idea in the document, and the one that transfers outside the industrial world, is that isolation is not binary. The worked example — built on a fictional electricity transmission company — is a five-rung ladder:

1. Rung 1
   External remote access

   Disable OT access for remote workers.

2. Rung 2
   Internal remote access

   Disable on-premise remote access as well.

3. Rung 3
   IT/OT boundary

   Isolate all connections between non-OT and OT networks.

4. Rung 4
   Low-priority peers

   Isolate OT-to-OT connections towards less critical peers.

5. Rung 5
   Full isolation

   OT environment and vital systems completely separated.

The value lies in each rung carrying a rising operational cost and a rising level of protection, so the decision about which rung to activate can be taken on the basis of what is being observed rather than in a panic. The document asks that the trigger criteria for each rung be defined in advance and linked to the incident response plan — and that a secure offline hard copy of the isolation plans be kept. A detail that seems quaint until you consider where a digital plan lives when the network is isolated or encrypted.

The stated risks of isolation

A point of honesty in the text worth repeating: isolating is not free, and the agencies list three consequences.

Systems fall out of the patch cycle. Isolated, they receive no updates. Debt accumulates and has to be managed.

External visibility drops. Centralised telemetry and monitoring stop seeing that environment precisely while something is happening.

Risk from removable media rises. If the network is no longer a way in, the USB stick becomes one again — and the media-checking workstations may themselves not be receiving updates.

Two further technical warnings are worth citing. On carrier-provided links, the document asks operators to treat any carrier service as untrusted and potentially hostile, and not to use encryption built into OT devices: a dedicated device is required. On MPLS it is explicit: it does not provide assurance of segregation and is not secure by default. VLANs, MPLS and IP access lists are treated as administrative controls useful as interim measures, but ones organisations must not rely on as a long-term solution for a genuinely segregated operations network.

The limits, stated

The document is written for critical infrastructure operators with OT environments. Applying it unchanged to a mid-sized services company would be a stretch, and that should be said.

The text itself concedes that complete physical isolation may not be operationally feasible for organisations whose core operations depend on internet-facing services or geographically dispersed sites.

It also carries a note clarifying the status of its prescriptions: "must" statements represent cyber security best practices, and operators should consult their jurisdiction's relevant regulatory and legally binding obligations. It is not a regulation.

Finally: it contains no statistics at all. No effectiveness percentages, no cost figures. It is a document that prescribes rather than persuades, which makes it hard to quote for effect and easy to use in practice.

What transfers to an ordinary organisation

Even without an industrial plant, three ideas carry over.

The right question is not "can we disconnect" but "what keeps working if we do". That question can be put to any internal service, and the answer exposes dependencies nobody had written down.

Identity, time and certificates are hidden dependencies. This holds everywhere: an environment that relies on the central directory to authenticate does not survive the compromise of that directory.

An isolation plan is needed beforehand, and needed on paper. With trigger criteria written while thinking clearly, not at three in the morning.

The point

Isolation is rehearsed in advance. During, it is just panic.