Estimated reading time: 10–11 minutes
Editorial disclosure: GME approached Digital Reviews Network with an interview opportunity with Christopher Rule. DRN independently developed the questions and this editorial. GME had no editorial input into the article and did not review it before publication. GME Defence is the official Asia-Pacific distributor and support partner for Owl Cyber Defense, which provides cross-domain and hardware-enforced data diode solutions discussed in this article.
Australia’s critical infrastructure is becoming more connected, more automated and more dependent on systems that were once largely separate.
That brings enormous benefits when everything works.
The tougher but more relevant question is what happens when it doesn’t.
Recently, Digital Reviews Network looked at a Telecommunications Industry Ombudsman report examining the reliability of telecommunications across regional, rural and remote Australia. Among its findings was an uncomfortable reminder that infrastructure rarely exists in isolation.
Telecommunications networks depend on electricity. Electricity restoration can depend on functioning communications. Businesses depend on both. Increasingly, so do farms, emergency services and connected systems that reach far beyond phones and internet access.
During a natural disaster, failure in one can cascade into another.
Now consider deliberately disconnecting part of that infrastructure — and keeping essential services running for an extended period.
That is the challenge Australian critical infrastructure operators are being asked to prepare for under new cyber resilience guidance from the Australian Signals Directorate (ASD).
It sounds simple enough: if an attacker compromises your corporate network, isolate the operational technology that actually controls the essential service.
Pull the plug.
Except, in 2026, there can be an awful lot attached to that plug.
How long is an extended period?
ASD’s new CI Fortify guidance says critical infrastructure operators should have the capability to isolate vital operational technology, or OT, and the systems that enable it from other networks.
OT is distinct from the information technology, or IT, most of us interact with every day. IT handles information and business systems. OT monitors or controls physical equipment and processes — the technology involved in keeping electricity flowing, water moving or industrial equipment operating.
For anyone who has worked around industrial systems, that includes technology such as SCADA — Supervisory Control and Data Acquisition — used to monitor and control physical infrastructure.
I’ve supported SCADA environments where redundancy was designed into virtually every level: multiple nodes across sites, backup servers, backups of those backups and live replication designed to keep operations running when something failed.
That kind of redundancy is fundamental to critical infrastructure, but it also illustrates why ASD’s isolation question is different.
Having another server ready to take over protects against a server failing. Replicating data protects against losing a node. Multiple sites can protect against losing a location.
None necessarily answers what happens when the network connecting those systems — or an enterprise service they depend upon — is compromised.
That’s because OT does not necessarily exist as an island.
SCADA and other operational systems may legitimately exchange information with enterprise IT for monitoring, reporting, authentication, remote support and other purposes. A highly redundant operational environment can therefore still have dependencies outside the OT network.
The objective of isolation isn’t simply to protect computers. It’s to allow critical services to continue while an incident is contained and compromised systems are safely rebuilt.
ASD doesn’t prescribe a specific duration for that isolation. Instead, it says operators need to consider how they would continue functioning in an isolated state for an “extended period.”
But what does extended mean in practice?
Digital Reviews Network put a more concrete scenario to Christopher Rule, General Manager – Defence, Security and Resilience at Australian communications manufacturer GME: could operators remain isolated for as long as three months?
Rule said the objective was realistic, but warned that it isn’t something most operators should assume they can achieve today without deliberate design work and testing.
The problem is that an industrial control system does not necessarily stop depending on the outside world simply because somebody has drawn a boundary around the OT network.
Monitoring might reside elsewhere. Reporting could pass through enterprise IT. Remote maintenance may depend on external vendor access. Authentication could require shared identity infrastructure. Patches and software repositories might sit outside OT.
The list gets longer.
Rule points to dependencies including Active Directory, DNS, network time services, certificates, licence servers, historians and cloud-based monitoring platforms.
Any one of those could be perfectly mundane during normal operations.
Remove enterprise connectivity, however, and an organisation may discover that something it considered self-contained isn’t self-contained at all.
“A lot of the dependency risk is invisible until you try to operate with enterprise connectivity removed, because systems work normally in day-to-day conditions but fail under incident conditions,” Rule said.
ASD’s own guidance identifies much the same problem. It tells operators to map connections between vital systems and corporate networks, vendor remote access, the internet, cloud environments and other critical networks. It also identifies dependencies including shared network infrastructure, storage and backup systems, Active Directory, DNS, certificate services and time synchronisation.
The resilience question isn’t simply whether there is another system ready to take over.
It’s whether the vital system can continue operating safely when everything it normally talks to can no longer be trusted.
Australia already has a lesson in interdependency
There is a parallel here with the problems the TIO has identified in regional Australia.
Its August 2026 Systemic Insights Report found telecommunications outages can leave people unable to make emergency calls, receive disaster warnings or operate medical alarms. Businesses can lose EFTPOS, supplier communications and bookings, while unreliable connectivity can restrict technologies including farm water monitoring, remote cattle weighing and soil sensors.
Power complicates the equation further.
Telcos told the TIO that loss of mains electricity is a common cause of telecommunications outages. During disasters, damaged telecommunications infrastructure can take time to restore.
But the dependency runs both ways: communications outages can themselves interfere with restoration of electricity services.
That does not mean a regional telecommunications outage is equivalent to a cyberattack against operational technology.
It does demonstrate the underlying problem.
Modern infrastructure is a system of systems. Resilience therefore depends not only on whether an individual component keeps working, but on whether everything that component quietly relies upon remains available too.
For critical infrastructure operators, ASD’s isolation challenge turns that dependency problem on its head.
Instead of asking what happens when a dependency unexpectedly fails, operators need to know what happens when they intentionally remove it.
Isolated isn’t necessarily independent
There is another potential trap.
A network can be separated logically without being capable of operating independently.
ASD makes an important distinction between physical separation and isolation. Physical separation means infrastructure independence. Isolation means having the ability to disconnect systems and continue operating independently when required.
That makes the architecture underneath critical infrastructure particularly important.
Firewalls, VLANs, access control lists and routing policies can create boundaries between enterprise and operational networks. Rule isn’t arguing that those controls are useless.
He is arguing that they ultimately remain dependent on software and configuration.
If an attacker gains sufficient administrative access to a firewall, compromises credentials or exploits the system responsible for enforcing that boundary, the rules themselves could potentially be changed.
Routes can be altered. Policies can be modified. New paths can potentially be established.
ASD’s own guidance reinforces that concern. It describes administrative network controls such as VLANs as providing minimally effective segregation and says they should be considered an interim measure on the path towards stronger physical or cryptographic isolation, rather than a long-term solution for a fully segregated operational network.
ASD also warns organisations relying on administrative isolation controls to secure the network control plane against attackers capable of disabling or defeating them.
That becomes particularly important when the reason an organisation is isolating OT is that another part of its environment is already under active attack.
And it exposes another difference between redundancy and isolation.
If multiple SCADA nodes and servers replicate across the same trusted environment, that replication is a strength when hardware fails. During a cyber incident, however, connectivity can potentially become part of the problem. The question changes from how quickly another node can take over to whether compromised systems can be prevented from reaching the systems that must remain operational.
When isolation becomes physical
ASD describes physical isolation of vital OT and enabling systems as the most effective form of protection.
Rule advocates hardware-enforced isolation for systems requiring that higher level of assurance, including one-way gateways commonly known as data diodes.
There is a commercial connection worth noting. GME Defence is the official Asia-Pacific distributor and support partner for Owl Cyber Defense, which provides cross-domain and hardware-enforced data diode solutions. GME does not manufacture the technology itself.
The difference is physical.
A conventional firewall might be configured to prohibit traffic travelling from one network to another. A one-way hardware architecture instead removes the return path.
In the one-way architecture Rule describes, data can leave the protected OT environment for monitoring or other purposes, while traffic cannot travel back through the same connection.
For SCADA, that distinction is easy to appreciate.
An operator may have legitimate reasons to export operational information from the SCADA environment into enterprise systems for monitoring, analysis or reporting. That does not necessarily mean the enterprise environment should have an equivalent pathway back into the systems controlling physical infrastructure.
Rule offers a straightforward scenario.
Imagine an organisation separates IT and OT with a firewall. During an attack, the firewall or its management interface is compromised. An attacker with sufficient control may be able to permit or tunnel traffic that would normally be blocked.
With a genuinely one-way hardware connection, compromising the IT side doesn’t create a return path through that connection.
The attacker may be able to see information being exported from OT. They cannot use that connection to send commands or malware back into it.
ASD itself recommends considering data diodes or cross-domain solutions where information needs to pass between critical and non-critical networks, saying appropriately designed and maintained implementations can provide greater assurance than standard network gateways.
But that doesn’t make them magic.
ASD also warns that data diodes must be appropriately designed, configured and maintained. Incorrect deployment can itself harm operational integrity.
Nor is complete physical isolation possible everywhere.
Critical services that must remain internet-facing or infrastructure spread across geographically dispersed sites may make complete physical isolation impractical. In those circumstances, ASD recommends greater emphasis on hardened OT boundaries, dedicated communications paths and strong cryptographic isolation.
The goal isn’t simply to disconnect everything.
It’s to understand what must remain connected, what can be severed and what happens to the critical service when it is.
The test isn’t whether the diagram looks right
Perhaps the most important part of ASD’s resilience challenge has little to do with buying another security product.
It is testing assumptions.
An architecture diagram can show a neat dividing line between IT and OT. A security policy can state that critical systems are segmented. A disaster recovery document can describe how isolation is supposed to work.
None of those demonstrate what will actually happen when the connection really disappears.
ASD recommends operators periodically test the isolation of all vital systems, warning that testing only a single system or subset may fail to expose all dependencies.
Rule similarly argues that operators need to test the loss of cloud connectivity, internet access, enterprise identity systems and remote support rather than assuming those services aren’t essential to OT.
Testing may reveal something as mundane as a forgotten licence server.
Or it might expose a bidirectional connection nobody realised remained open.
More importantly, it can reveal whether people can continue operating the infrastructure safely once their familiar digital tools are gone.
Because surviving an extended period of isolation doesn’t mean running normally throughout it.
It means maintaining the essential service while compromised systems are contained, investigated and recovered.
That distinction could be the difference between an inconvenience and a national infrastructure disaster.
The board needs a different question
Cybersecurity discussions at board level can easily gravitate toward numbers.
How many vulnerabilities have been patched? How many attacks were blocked? How much money is being spent? Are we compliant?
The isolation problem demands something more concrete.
Rule suggests boards responsible for essential services start by asking what their critical OT dependencies actually are — and whether the organisation has tested what happens when enterprise IT, cloud services, remote access or identity infrastructure becomes unavailable.
Then comes an even simpler question:
Have we actually demonstrated that vital systems can be isolated while continuing to operate safely?
And finally, if the business network or privileged-access systems were compromised tomorrow, what prevents an attacker moving laterally into OT — and when was that protection last independently tested?
Those are uncomfortable questions because “we have a firewall” isn’t necessarily an adequate answer.
Neither is “the network is isolated” if nobody has actually tried isolating it.
Resilience starts when something disappears
The TIO’s examination of regional telecommunications and ASD’s critical infrastructure guidance address very different problems.
But there is a common thread running through them.
Australia is increasingly dependent on interconnected infrastructure, and every new dependency has consequences when something disappears.
In regional communities, the loss of electricity can mean the loss of telecommunications. The loss of telecommunications can affect emergency communications, businesses and potentially the restoration of electricity itself.
Inside critical infrastructure, the dependencies may be less visible but no less important.
A control environment might rely on enterprise authentication. Monitoring may rely on the cloud. Maintenance might require remote vendor access. A supposedly isolated network might still contain a pathway nobody noticed because it has always been there.
And redundancy doesn’t necessarily solve that problem.
You can have another server, another node, another site and another copy of the data. Those are enormously valuable when components fail.
But cyber resilience asks a different question: what happens when the infrastructure is still functioning, but part of the environment can no longer be trusted?
The worst possible time to discover the answer is after an attacker has arrived.
ASD’s guidance therefore asks Australian infrastructure operators to build the capability to continue providing critical services while their vital systems are isolated. It acknowledges that getting there will require investment, planning and, in some environments, alternatives to complete physical isolation.
Rule’s three-month scenario puts a useful number against that otherwise open-ended challenge.
The question isn’t whether an architecture diagram says critical systems can be isolated.
It’s whether anyone has actually tested what happens when they are.
Digital Reviews Network thanks Christopher Rule for his time and for contributing his perspective to this editorial.
