Could you run for three months with your OT cut off?

Look at the links into your operational technology (OT) network: vendor remote access, cloud monitoring portals, licence servers, corporate sign-in, and satellite or mobile links to remote sites. Each is useful on a normal day. Each is also a way in for an attacker, and something that may stop working if you have to disconnect.

The Australian Signals Directorate (ASD) has turned this into a clear test for critical infrastructure operators. This article explains what the test asks, why it matters now, and what meeting it requires.

What CI Fortify asks

ASD’s CI Fortify guidance asks operators to be able to isolate vital OT and enabling systems for three months, and to fully rebuild them. The first step is a current OT asset inventory.

In plain terms, you should be able to disconnect OT from IT networks, suppliers and the internet, keep essential services running while an intrusion is found and removed, and restore systems to a known-good state. A short outage can be covered by automatic control and extra effort from staff. Three months exposes every hidden dependency: licences that expire, sign-in that fails, spares that are missing and procedures nobody has used.

The threat picture

In February 2024, a joint advisory co-sealed by ASD (AA24-038A) reported that PRC state-sponsored actors, known as Volt Typhoon, had compromised US critical infrastructure, including energy. They kept access to some IT networks for at least five years, in preparation for moving into OT.

ASD responded to over 1,200 cyber incidents in the 2024–25 financial year, up 11%. Critical infrastructure accounted for 13% of them, and denial-of-service attacks appeared in 31% of critical infrastructure incidents. Globally, the International Energy Agency (IEA) reports that cyberattacks on energy utilities tripled in four years and are becoming more sophisticated because of AI.

Wind and solar sites are direct targets. On 29 December 2025, coordinated attacks hit more than 30 wind and solar farms in Poland, plus a combined heat and power plant. Attackers targeted RTUs, HMIs, protection relays and communications devices at grid connection points. Some were reached through default credentials, and RTU firmware was corrupted. CERT Polska later called it the first purely destructive cyberattack on Poland’s energy sector.

Losing the link is not the same as losing the plant

Two incidents show what unplanned isolation looks like. In February 2022, an attack on the Viasat KA-SAT satellite network cut remote monitoring and control of about 5,800 Enercon wind turbines in Germany, with a combined capacity of 11 GW. The turbines kept running on automatic control. In Poland, communication with the distribution system operator was disrupted, but electricity production continued.

Both cases show that local automatic control can keep plant generating when outside links fail. They also show the limit: remote monitoring and control were lost, so any change needed someone on site. Planned isolation for three months needs more than automatic control. It needs local monitoring, local control, trained people and a way to rebuild what was damaged.

What running isolated requires

Every system needed for safe operation must work with no outside connection, and you must be able to restore it from what you hold yourself. In practice, that means the following.

• A current asset inventory. This is ASD’s starting point. Record every OT asset, its firmware and configuration, and every connection out of the OT network, including vendor access and mobile links. CERT Polska’s follow-up on the Polish attacks found a new path in through a misconfigured private mobile network.
• On-premise systems with no cloud dependency. SCADA, HMIs, historians, alarm handling and engineering tools must run on site. Look for less obvious dependencies, such as cloud dashboards, external time sources and update services.
• Offline licensing. Software that checks a licence server may stop or lose functions when it cannot reach it. Ask each vendor how the product behaves after three months without a connection, and when each licence expires.
• Local identity. If operators sign in through a corporate directory or a cloud identity service, isolation can lock them out. Keep local accounts with multi-factor sign-in that works offline, and emergency accounts whose credentials are stored securely and tested.
• Tested backups. Keep offline copies of configurations, project files, firmware and system images, and prove that you can restore them. When firmware has been corrupted, as in Poland, a known-good copy is what you rebuild from.
• Spares. Hold spare RTUs, network switches, servers and HMI hardware for the items that take longest to replace, with firmware and licences ready to load.
• Manual procedures. Write down how to run each site locally, which functions stay on automatic control and which need people on site. Keep printed copies and contact lists that do not depend on the network.
• Practice drills. Isolate systems in planned exercises, starting with hours and building to longer periods. Record what failed, fix it and test again.

Existing duties still apply

Isolation planning fits within duties that already exist. Under the Security of Critical Infrastructure (SOCI) Act, energy assets need a Critical Infrastructure Risk Management Program (CIRMP) that meets a named cyber framework, such as AESCSF Security Profile 1 or Essential Eight Maturity Level 1. The isolation plan belongs in that program.

Reporting does not pause during isolation. A cyber incident with a significant impact on a critical infrastructure asset must be reported to ASD within 12 hours, and one with a relevant impact within 72 hours. Since 30 May 2025, businesses with turnover above $3 million and SOCI-regulated entities must also report ransomware payments to ASD within 72 hours, under the Cyber Security Act 2024.

Your isolation plan should name who reports, and how they will do it if corporate email and phones are unavailable. Test that path in the same drills.

How we approach this

Ozari Grid is designed to run without outside connections. It ships as one self-contained binary that runs on-premise or fully air-gapped, and uses an offline signed licence that never needs to contact us. Its outbound features, weather data and remote AI, are off by default. The way to start is a read-only shadow pilot, so you can check its behaviour on an isolated network before it controls anything.