ASD Wants Critical Infrastructure Isolated for 3 Months. What If You Supply It?

The Australian Signals Directorate’s CI Fortify guidance asks critical infrastructure operators to be able to run their vital systems completely disconnected for three months, and to rebuild those systems from nothing if they have to. Almost all of the commentary is written for the operators. If your business supplies those operators, the guidance reads very differently.

In the graduated isolation plan ASD describes, external access is not a late casualty. It goes first. Remote worker access to operational technology is stage one. On-site remote access is stage two. If you provide testing, analysis, maintenance, calibration or monitoring services to a critical infrastructure operator, your connection is among the first things switched off, deliberately, by a customer following the advice properly.

ASD says so itself: “Supply chain dependencies should be considered when reviewing the advice in this publication.” And there is a sharper reason to care than losing access for a quarter. Even where an operator isolates perfectly, a compromised supplier system crossing that boundary to carry out testing can hand an attacker the exact access the isolation was built to remove. This article covers what CI Fortify asks for, why full isolation is the last step rather than the first, why testing activity is the bridge that defeats it, and what all of it means if you hold or are building an ISO 27001 management system.

What CI Fortify asks for

CI Fortify sets out two planned actions for operators of critical infrastructure:

1. Isolate vital operational technology and enabling systems for three months while continuing to deliver critical services.
2. Rapidly and completely rebuild those systems.

Three preparatory steps sit underneath that: maintain an up to date OT asset inventory, identify which OT and enabling systems are vital, and identify the isolation points. The guidance is blunt that isolating vital OT will break business processes, and that automated processes crossing the boundary will need to be done manually.

The rebuild half is the part people skip. It requires offline, known good, tested backups of firmware, configuration and processes. Not just data. Firmware and configuration.

The driver is pre-positioning by state actors. ASD names Volt Typhoon, Salt Typhoon, APT29, APT40 and Lazarus, and lists the OT incidents that shaped the thinking: Stuxnet in 2010, Industroyer in 2016, Triton in 2017, Colonial Pipeline in 2021 and Industroyer 2 in 2022. The document is co-sealed with the United States Cybersecurity and Infrastructure Security Agency and draws on ASD’s Critical Infrastructure Uplift program under the $10 billion REDSPICE investment.

Why full isolation is the last step, not the first

Heidi Hutchison, ASD’s assistant director-general for cyber uplift, has described complete isolation as “probably the last measure of resilience” rather than a first response. What ASD wants is a graduated plan, so an operator can step down connectivity in stages that match the severity of what they are facing.

The worked example ASD uses is a fictitious electricity transmission company isolating in five stages:

1. Cut remote workers’ access to OT
2. Cut on-site remote access
3. Cut all remaining links between corporate systems and OT
4. Cut lower priority connections to peer utilities
5. Complete isolation

Read that as a supplier and the point is unmissable. Stages one and two are you. Not because anyone doubts you, but because external access is the cheapest thing to remove and the first thing an attacker would use. A customer does not have to lose confidence in your service to switch it off. They only have to follow the plan.

This also means the instinct most people have, which is “just air gap it”, is answering a different question from the one ASD asked. Air gapping is the destination. The guidance is about the road to it.

“Vital” or “business”? Your customer decides, and probably has not told you

To build an isolation plan an operator has to delineate every connected system as either vital or business. Hutchison has openly acknowledged this is one of the hard parts, and it is easy to see why. The boundary is rarely clean, and the enabling systems that keep vital OT running are often the ones nobody has documented.

For a supplier, that classification decides your fate and you almost certainly have not been consulted on it:

• Classified as business: you are designed out. Your service stops for the duration, and your contract needs to say what happens then.
• Classified as vital: you are designed in, and you inherit obligations you have never seen. Availability commitments, offline delivery arrangements, personnel on site, evidence requirements.

There is a third question almost nobody asks a supplier. ASD requires rebuild from known good baselines of firmware, configuration and processes. Testing and analysis providers frequently hold exactly that material: reference configurations, calibration records, baseline datasets. If your customer rebuilds, whose copy is authoritative, and is yours offline, current and tested?

The practical move is simply to ask. A short conversation with your customer’s security or risk lead about where you sit in their isolation plan is worth more than any amount of policy writing, and it tends to be a conversation they are pleased to have.

The risk, in one sentence

Even if the operator isolates perfectly, a compromised supplier system crossing that boundary to carry out testing can hand an attacker the exact access the isolation was built to remove.

An isolation is only ever as good as the least controlled thing that crosses it. Testing and analysis is not an accidental crossing. It is authorised, scheduled and recurring. Of all the ways back into an isolated environment, it is the one with a calendar entry and a car park pass.

Three consequences follow, and they compound.

1. The compromise is harder to see on the isolated side

This is the uncomfortable one. An isolated environment has no cloud reputation lookups, ageing detection content and no outbound telemetry reaching a platform that could correlate it with anything else. So the very isolation that protects the operator also reduces their ability to detect what your device brought in. You are introducing risk into the environment least equipped to notice it.

2. It makes testing providers a target class, not collateral

If you serve several critical infrastructure operators, you are the common node with recurring, authorised, physical access to several isolated environments. Your corporate network is almost certainly a softer target than any one of your customers’ OT environments, and compromising you reaches all of them.

The actors ASD names do not smash through front doors. Volt Typhoon’s model is quiet, patient pre-positioning against a future event. A supplier with legitimate recurring access to multiple isolated environments is not a bystander in that model. It is close to an ideal foothold. Being small is not protection here. Being the connection point is the whole attraction.

3. The exposure window is measurable, which means it is manageable

The window runs from the last time your device touched the internet to the moment it touches their operational technology. Everything that happened to the device in between travels with it.

Only two things meaningfully shrink that window. Dedicated devices that never connect to the internet at all remove it. A documented rebuild or quarantine cycle before each engagement shortens it to something you can state and evidence. Policies asking staff to be careful do neither.

Which leads to the control that follows from all of this.

The control that matters most for suppliers: do not be the bridge

If your systems directly access a customer’s critical infrastructure, the primary control is to disconnect those systems from the internet. Not their operational technology. Yours.

This is the part that gets missed. A laptop, test rig or analysis workstation that plugs into an operator’s OT environment and also reads email and browses the web is, functionally, an internet to OT bridge. From the operator’s point of view, a transient supplier asset is one of the higher risk things that will ever touch their environment, and unlike an attacker it arrives with permission, inside the perimeter, with your name on it. Every serious OT compromise on ASD’s list started with something crossing a boundary that was assumed to be safe.

In practice that means dedicated devices for OT work, never dual purpose:

• Isolated from the internet, with no email, no browsing and no personal use, enforced technically rather than by policy
• A documented, repeatable build you can rebuild from, which is also what lets you answer questions about what was on the device when it connected
• Separate credentials from your corporate environment, so a compromise of one does not deliver the other
• Controlled physical handling and storage, because an isolated device that lives in a car boot is not really controlled

All of that sits on top of the controls you would expect on any managed fleet: patch distribution through WSUS or an equivalent, endpoint protection, EDR, application control and disk encryption. Isolation does not replace those. It makes them harder to maintain, which is the next problem.

Worth noting commercially: this is also the control that makes you easy to say yes to. An operator who has read CI Fortify will start asking suppliers how their equipment is built and managed. Being able to answer with a documented, isolated, patched build is a competitive advantage well before it is a security one.

Keeping an isolated device current

Here is the honest tension nobody writing about CI Fortify seems to want to name. Isolation and currency pull against each other. Endpoint protection and EDR are largely cloud products now. They rely on regular agent and detection updates, reputation and hash lookups, and telemetry flowing out to a platform that correlates it. Cut the connection and the detection stack starts ageing immediately. Sustain that through a three month operator isolation and you are defending an environment with a three month old view of the threat landscape.

WSUS is the right instinct, and it also illustrates the shape of the answer, because WSUS itself has to synchronise from Microsoft. So you end up with a staged architecture: an upstream server that touches the internet, a downstream server inside the boundary, and a controlled export and import between them. The same shape applies to EDR definitions and to application control rules.

The air gap does not remove the update problem. It relocates it to a single controlled, auditable chokepoint, which is a far better place to have it. But it has to be designed, staffed and tested. An update path that exists on paper and has never been exercised is not a control, and an isolation you have never rehearsed is a plan rather than a capability.

Two things to decide in advance rather than in week three of an incident:

• How the media itself is controlled. A staged update path means removable media, and removable media is how air gaps have historically been broken. Stuxnet is on ASD’s own incident list. Write once media, scanning on a separate host, and a documented chain of custody are the usual answers.
• What detection coverage you accept losing, and for how long. That is a risk acceptance, not an oversight. It needs a named owner, a review date and a trigger for reassessment. Detection that degrades gracefully, leaning on behavioural and local analytics rather than cloud lookups, is what limits the damage.

One sequencing point. Isolation is the control, but ASD deliberately puts asset inventory first, because you cannot isolate what you have not mapped. Most organisations discover their real dependencies while trying to draw the boundary, not before.

The dependencies that quietly defeat an air gap

You can cut the network link and still be dependent on the other side. ASD flags shared routing and switching, common virtualisation and storage, Active Directory, DNS, DHCP, digital certificate services and, easy to overlook, NTP.

Time and certificates are the two that bite over a long isolation. Ninety days is long enough for certificates to expire with no path to renewal, and long enough for clock drift to break authentication, logging correlation and anything that checks a validity window. Telstra’s outage on 8 July 2026, caused by an undocumented time fix, is a reminder that time is infrastructure and it fails like infrastructure.

If you supply into an OT environment, the honest question is whether your own tooling has any of these dependencies on the customer’s side of the boundary. Authentication against their directory, a licence server reachable only through their network, a certificate issued by their internal CA. Any one of those means your equipment stops when they isolate, whether or not anyone intended to switch you off.

If you are building an ISO 27001 system right now

One of our ISO clients carries out testing and analysis on critical infrastructure. Work like that sits directly on the boundary CI Fortify is drawing, and it is a good illustration of why timing matters. If your ISO 27001 management system is still being designed, CI Fortify is a design input, and it costs you a conversation and a few entries in the risk assessment. If you are already certified, it is a prompt to revisit scope, supplier controls and risk, which is more work but still cheap next to discovering the gap during a customer’s incident.

Where it lands in the standard:

The commercial argument is simple. Designing this in during development costs a conversation and a few extra risk entries. Retrofitting it after certification costs a scope change, new controls and, depending on timing, a special audit. If your customers are critical infrastructure operators, this belongs in the design now. A gap analysis is usually the cheapest way to find out where you stand.

What this does not mean

CI Fortify is guidance. ASD has no enforcement powers. Whether any of it becomes mandatory is a decision for the Department of Home Affairs, not ASD. For operators already captured by the Security of Critical Infrastructure Act, much of this should already be reflected in their risk management program, so for them it is less a new obligation than a sharper articulation of an existing one.

It also does not mean every supplier needs to rebuild their service model. For most it means one conversation with the customer, one or two additions to the risk assessment, and a clear statement in the contract about what happens to the service if isolation occurs. That is a modest amount of work for a risk that would otherwise arrive as a surprise.

Frequently asked questions

Does CI Fortify apply to me if I am only a supplier?

Not directly. It is written for critical infrastructure operators. It reaches you through your customer, both because ASD tells operators to consider supply chain dependencies and because their isolation plan cuts your access in its earliest stages.

Could our testing activity undermine a customer’s isolation?

Yes, and that is the central risk for suppliers. A device that connects to a customer’s operational technology and has also been connected to the internet is a path into an environment that was isolated precisely to remove such paths. Dedicated, isolated, documented devices are the control.

Is it mandatory?

No. It is ASD guidance and ASD does not have enforcement powers. The Department of Home Affairs determines what becomes a regulatory obligation.

What is a “vital enabling system”?

A system that is not itself operational technology delivering the critical service, but that the OT depends on to keep running. Directory services, name resolution, certificate services and time synchronisation are the common examples. They are the systems that turn a clean air gap into a partial one.

Does ISO 27001 already cover this?

The framework does. Whether your particular system does depends on your scope and on whether your supplier relationship controls look upstream as well as downstream. Most look only downstream.

How does this relate to the Essential Eight?

Different problems. The Essential Eight is a baseline mitigation set aimed largely at corporate IT, and ASD is replacing it with the ASD Essentials. CI Fortify is about the resilience of operational technology delivering essential services, and specifically about surviving disconnection. If you are weighing the two frameworks, see Essential Eight vs ISO 27001.