Executive Takeaway
Disconnecting operational technology can contain an attacker and stop further movement from compromised corporate systems. It can also disable identity services, monitoring, remote engineering, time synchronization, vendor support, and data flows that operators did not realize were necessary until they disappeared.
That is the consequential distinction in the CI Fortify guidance published on July 28, 2026. Isolation is not merely the act of opening a switch or changing a firewall rule. It is the capability to preserve an essential service after selected connections, shared infrastructure, and external support have been removed.
For refining, chemicals, pipelines, utilities, manufacturing, and other critical operations, the management decision is therefore not whether OT should be isolated in principle. Leaders must decide which services need to survive, at what minimum capacity and quality, for how long, and with which dependencies unavailable. Architecture and operating procedures must then make that decision achievable.
What the New Guidance Changes
The guidance, developed by the Australian Signals Directorate with international partners and aligned with CISA’s CI Fortify initiative, provides a staged path to isolating vital OT and enabling systems. It calls on operators to identify the minimum systems needed to deliver a critical service, identify critical customers, classify systems by criticality and trust, map connections, build isolation points, and test a graduated isolation plan.
That sequence matters. Starting with network controls would answer the wrong question. The operator first has to define the service that must remain available. The guidance suggests expressing customer needs through operational targets such as power output or water volume. A petrochemical organization might instead define minimum safe throughput, environmental-control requirements, inventory movement, utility consumption, or the ability to move the process into a stable shutdown state.
The guidance does not claim that every site can remain fully productive while physically disconnected. It acknowledges that complete physical isolation may be impractical for internet-dependent services and geographically distributed infrastructure. The UK National Cyber Security Centre similarly describes full-site “islanding” as an extreme measure, not a universally proportionate default.
The required capability is bounded continuity: knowing what can be disconnected, what must remain connected, what service degradation is acceptable, and who can authorize each step.
Isolation Exposes the Architecture You Actually Have
Many OT environments appear separated on diagrams while depending on shared enterprise services in operation. CI Fortify identifies dependencies including shared virtualization, storage, backup services, Active Directory, DNS, DHCP, certificate services, document repositories, and external time sources. It also points to cloud environments, vendor remote access, carrier networks, dispatch operators, and peer infrastructure as connections that must be understood before isolation.
A firewall inventory will not expose the full problem. Leaders need a dependency model that answers four questions:
- Which business or safety function uses the connection?
- Who owns the systems on both sides?
- What happens immediately and over time if the connection is removed?
- What alternative process, local service, or trusted path is available?
This is where asset inventory becomes an operating capability rather than a compliance artifact. An asset list can show that an engineering workstation exists. It does not necessarily show that the workstation retrieves configurations from a corporate document platform, authenticates through an enterprise directory, receives time from an external source, or requires a vendor engineer to recover a failed controller.
The same accountability problem appears with suppliers. Contracts may promise emergency support, but a severe regional event can create competition for integrators, incident responders, replacement hardware, fuel, chemicals, and specialist personnel. As discussed in Cloud Security Accountability Cannot Stop at the Contract, contractual language is useful only when the organization can verify how the service will work under stressed conditions.
Define Minimum Viable Service Before Buying Isolation Technology
The business owner and operations leader should define the minimum viable service. Engineering and cybersecurity can then determine the architecture required to preserve it.
For a safety-critical industrial process, the desired business attributes may include:
- Safe: isolation must not remove a protection, alarm, or operator capability needed to prevent harm.
- Available: the essential service continues at an agreed minimum level or reaches a controlled state.
- Recoverable: trusted configurations, software, credentials, equipment, and personnel are available to restore service.
- Governed: authority to escalate, isolate, reconnect, and accept degraded operation is explicit.
- Assured: exercises and technical tests produce evidence that the capability works.
Those requirements should drive technology choices. Some facilities may need physically separate switches, local identity services, dedicated engineering repositories, independent backup infrastructure, or hardware-enforced data flows. Distributed operators may need dedicated communications or strong encryption across carrier networks. Others may obtain sufficient risk reduction by improving existing segmentation, securing the management plane, removing unnecessary remote access, and creating local alternatives for a small number of critical dependencies.
New technology is justified when it closes a defined continuity gap. Buying data diodes, additional firewalls, or another monitoring platform before defining the permitted data flows and minimum service can add cost without creating a usable isolation capability. The broader architecture principles remain consistent with CyberEnablement’s critical-infrastructure resilience priorities: design around consequence, controlled connectivity, trusted recovery, and realistic operating conditions.
Prioritized Actions and Leadership Questions
| Priority | Accountable owner | Required decision and operating evidence |
|---|---|---|
| Define the vital service | Business and operations leader | Approved minimum capacity, quality, safety, environmental, and duration requirements for isolated operation |
| Map dependencies | OT architecture and engineering | Verified flows, shared services, suppliers, carrier links, credentials, and manual alternatives—not only an asset list |
| Design graduated isolation | OT network owner with incident command | Predefined stages, trigger conditions, authority, expected impact, and a route to complete isolation where required |
| Build local operating capability | Engineering, site operations, and technology owners | Local access, configurations, recovery media, communications, monitoring, spares, and procedures sufficient for the target duration |
| Exercise and improve | Operations resilience leader | Full-scope test results, observed service degradation, failed assumptions, recovery time, and funded remediation decisions |
Leaders should ask:
- Which critical process would fail first if corporate identity, cloud connectivity, or remote vendor access disappeared?
- Can the site operate safely if external monitoring and centralized logging are unavailable?
- Who has authority to isolate a facility when cybersecurity, production, safety, and commercial priorities conflict?
- Which third parties are necessary during isolation, and what evidence shows they can support multiple customers during a widespread event?
- What conditions must be satisfied before reconnection, and who accepts the risk of reconnecting before every uncertainty is resolved?
The exercise should not be judged by whether the team followed the plan. It should show whether the service remained within agreed operating limits and whether leaders received enough evidence to make escalation, continuity, and recovery decisions.
My Perspective
My concern is that organizations will turn this guidance into another segmentation project. Segmentation is necessary, but the harder problem is organizational: years of integration have allowed OT to inherit convenient dependencies without assigning anyone responsibility for preserving the service when those dependencies fail.
A site may have an OT firewall, an inventory, an incident-response plan, and network diagrams yet remain unable to operate independently for an hour. That is not primarily a missing-control problem. It is an architecture and ownership problem.
I would not recommend universal physical separation or routine islanding. Both can reduce visibility, interrupt legitimate coordination, complicate patching, and increase reliance on removable media. The CI Fortify guidance explicitly recognizes these secondary risks. The proportionate objective is to make isolation possible where the consequence justifies it and to understand the residual risk where it is not feasible.
The strongest operators will treat isolated operation as a degraded business mode with defined service targets, decision rights, staffing, logistics, and recovery conditions. That framing makes the capability testable and prevents cybersecurity from making an operational promise it cannot deliver.
Conclusion
The new guidance raises the standard from protecting OT boundaries to proving that critical services can survive when those boundaries close.
Executives do not need to decide which firewall command will isolate a plant. They must decide what the plant, pipeline, terminal, utility, or production network is required to accomplish after isolation—and what degradation they are prepared to accept. Operations, engineering, technology, cybersecurity, suppliers, and resilience teams can then build and test the simplest architecture capable of meeting that requirement.
Isolation is successful only when it contains the threat without creating a larger operational failure.