Zscaler published analysis of the new CI Fortify – Advice for Isolating Vital Systems guidance released on July 28, 2026 by CISA, ASD’s Australian Cyber Security Centre, the FBI, the UK NCSC, Canada’s Cyber Centre, and New Zealand’s NCSC. The core message is direct: critical infrastructure operators should be able to isolate vital operational technology systems during a serious cyber incident while continuing essential service delivery.

For SMBs and government contractors that support utilities, manufacturing, logistics, healthcare, maritime, water systems, facilities, or industrial customers, this is more than a critical-infrastructure policy update. It is a practical test of whether segmentation, remote access, identity dependencies, vendor access, and recovery plans actually work under pressure.

What changed with CI Fortify

The joint guidance moves isolation from a vague incident-response concept into an operational capability. Organizations are being pushed to identify the minimum set of systems required to deliver the critical function, map how those systems depend on IT, cloud services, identity platforms, vendors, and upstream providers, then pre-build the points where connectivity can be restricted or cut.

Zscaler’s analysis frames the hard part well: most environments do not fail because they lack an isolation plan. They fail because the network was never engineered with executable isolation points. In many brownfield OT environments, the HMI, historian, engineering workstation, vendor jump host, remote-access pathway, and unmanaged devices still share flat or loosely separated networks. In that environment, “prepare to disconnect” can turn into emergency firewall surgery during an active intrusion.

Why this matters now

CI Fortify lands in the middle of a threat environment where state actors and ransomware groups both understand operational pressure. State-sponsored operators have shown interest in pre-positioning inside critical infrastructure for long periods, while ransomware crews know production downtime forces faster business decisions.

The defensive question is simple: if a customer, plant, facility, or industrial site had to isolate a vital OT network in the next ten minutes, would the team know what to disconnect, who can authorize it, what business function breaks, and how long the isolated state can be sustained?

If the answer is unclear, the organization does not yet have an isolation capability. It has an isolation hope.

The hidden dependency problem

The most dangerous dependencies are often the ones nobody sees until the boundary is tested. OT teams may know which PLCs, HMIs, and engineering workstations are essential. But isolation plans can break when supporting services sit outside the OT boundary:

  • Identity services: domain controllers, MFA services, privileged access management, or cloud identity dependencies.
  • Name resolution and time: DNS, NTP, certificate validation, and logging pipelines.
  • Remote support: vendor VPNs, remote monitoring tools, jump boxes, and support tunnels.
  • Operational data flows: historians, MES/ERP integrations, reporting feeds, quality systems, and safety reporting.
  • Licensing and cloud dependencies: software license checks, SaaS dashboards, vendor telemetry, and update services.

Those dependencies are not automatically bad. The risk is discovering them for the first time during containment.

Defensive takeaways for SMBs and government contractors

1. Map the vital function, not just the network

Start with the service that must continue: water treatment, production, facility control, patient support, logistics coordination, or customer operations. Then identify the minimum OT and enabling systems required to deliver that function in a degraded state.

2. Inventory every path into vital systems

Remote users, vendors, MSPs, cloud platforms, corporate IT, wireless networks, engineering laptops, backup systems, and monitoring tools all count. If a pathway can reach the vital system, it belongs in the isolation plan.

3. Pre-stage isolation levels

Do not make “disconnect everything” the only option. Build graduated levels: restrict vendor access, block remote administration, limit IT-to-OT flows, isolate specific production lines, then fully isolate vital systems when conditions justify it.

4. Test the cut points before an incident

Tabletop exercises are not enough. Run controlled technical tests that prove which systems continue operating, which dependencies break, and how operators work around degraded conditions. Small, repeated tests are safer than a once-a-year all-or-nothing drill.

5. Treat vendor remote access as a first-class risk

Many OT incidents move through trusted remote pathways. Require named accounts, MFA, time-bound access, session recording where possible, allowlisted destinations, and a documented emergency shutoff for every vendor path.

6. Separate incident response from internet dependence

If the only copies of diagrams, procedures, contacts, credentials, and recovery steps live in cloud tools that may be unavailable during isolation, the plan has a single point of failure. Keep offline-accessible copies of the materials needed to operate in degraded mode.

Bulwark Black assessment

CI Fortify is important because it changes the standard from “we have segmentation” to “we can prove isolation under stress.” That distinction matters for smaller organizations and contractors because they often inherit messy environments: legacy equipment, vendor-managed systems, partial diagrams, flat networks, and remote-access exceptions that were created to keep operations running.

The right response is not panic or a rip-and-replace project. The right response is disciplined engineering: identify vital systems, map dependencies, define isolation triggers, pre-stage controls, test them, and document what breaks. If a contractor supports a critical infrastructure customer, this is also a business opportunity: help the customer turn CI Fortify from guidance into evidence.

The organizations that handle the next OT incident well will not be the ones with the prettiest network diagram. They will be the ones that already know which switch, firewall rule, identity dependency, vendor tunnel, and manual workaround matter when the network has to be deliberately constrained.

Sources: Zscaler — What CI Fortify Means for OT Security; Cyber.gov.au — CI Fortify: Advice for isolating vital systems.