Critical-infrastructure operators are being asked to prepare for a far more demanding scenario than an ordinary cyber incident: keeping essential services running after deliberately severing vital operational technology from the internet, corporate networks, vendors, cloud dependencies, and other external systems. The newly released CI Fortify – Advice for isolating vital systems, developed by CISA, ASD’s Australian Cyber Security Centre, the FBI, and international partners, turns that premise into a practical operating model for organisations responsible for energy, water, transport, communications, industrial services, and other indispensable functions. The central message is stark: resilience is not merely the ability to restore systems after an attack; it is the ability to continue a safe minimum service while isolated. CISA’s CI Fortify resource and the companion international isolation guidance frame that capability as a necessary response to persistent cyber threats against operational technology, or OT.
CI Fortify is notable because it does not treat network isolation as a last-ditch technical response that starts after ransomware has spread or remote access has been abused. Instead, it asks operators to engineer isolation in advance, document it, rehearse it, and prove that critical functions can survive without the digital conveniences that normal operations increasingly depend on.
That includes more than internet access. A credible isolation plan must consider whether a site can operate if it loses corporate identity systems, cloud management tools, vendor remote support, shared storage, centralized DNS, external time synchronization, carrier networks, remote monitoring, and even normal communications with suppliers and partner organisations. The guidance explicitly positions isolation as a method to maintain critical-service continuity, contain active incidents, disrupt an attacker’s ability to pivot, and create a safer environment for rebuilding compromised systems.
This is a meaningful evolution in critical infrastructure cybersecurity. Conventional incident-response plans often assume that staff can call a vendor, retrieve a configuration from a cloud portal, authenticate using a centrally managed directory, open a remote support case, or receive software updates from the internet. CI Fortify instead asks whether those assumptions hold in a prolonged crisis—and what happens if they do not.
For Windows administrators, infrastructure architects, and OT security teams, the implication is immediate: systems that seem peripheral in an enterprise environment can become operationally decisive when they underpin engineering workstations, historian access, patch repositories, domain authentication, certificate services, virtualization platforms, or industrial network management.
The broader CI Fortify initiative has already established a high-level expectation that operators should be able to disconnect vital OT and enabling systems from external networks while sustaining critical services, then rebuild affected systems quickly. Australia’s earlier CI Fortify material set a target of maintaining isolated vital OT and enabling systems for three months, alongside the ability to fully rebuild them to minimize service disruption. ASD’s CI Fortify announcement describes those twin objectives as isolation and rapid reconstruction.
The newly published advice provides the technical depth behind that direction. It is less a product checklist than an operational resilience framework. It requires organisations to understand what truly has to stay on, which systems enable that outcome, where connections cross trust boundaries, and how those connections can be removed without creating a worse safety or availability problem.
That difference explains why availability, safety, process integrity, and predictable operation must shape isolation planning. Cutting a connection that supports a remote vendor may reduce attack surface, for example, but it can also disable a safety-monitoring workflow, create a manual workload that staff cannot safely sustain, or interrupt communications required by a distributed operation.
CI Fortify’s strongest contribution is its insistence that those trade-offs be studied before a crisis. The guidance instructs operators to identify their minimum set of systems and networks required to deliver a critical service, identify dependent critical customers, establish a service-delivery target, and map the supporting connections in sufficient detail to make deliberate decisions under pressure. The critical-path model begins with those foundational tasks rather than jumping immediately to firewalls or VLANs.
That distinction forces hard decisions. A corporate reporting portal, for example, may be highly useful but not essential to maintaining a minimum level of water treatment. Conversely, a modest Windows-based application server that hosts an engineering utility, local authentication role, or protocol conversion function may be indispensable even if it does not appear on a traditional asset-criticality dashboard.
The guidance also tells operators to identify their critical customers and set an explicit service-delivery target. Examples include a defined quantity and quality of electric power or a specified volume of water delivered per day. CI Fortify’s isolation advice makes this customer-centered approach central to the exercise.
That is an important correction to technology-first security planning. An organisation cannot sensibly choose isolation controls until it knows the minimum operational outcome those controls must protect.
For a Windows-centric environment, this mapping needs to go beyond obvious TCP/IP routes. Teams should document dependencies such as:
The guidance distinguishes between physical separation and isolation. Physical separation means independence of infrastructure: vital OT should not share active network equipment, compute elements, or controllable supporting infrastructure with non-vital systems. Isolation is the ability to disconnect and continue operating independently when needed. CI Fortify’s explanation emphasizes that both matter, and that physical isolation requires no shared connectivity or infrastructure between vital and non-vital systems.
Where full separation is not feasible, operators are directed to harden OT boundaries, reduce non-OT dependencies, use dedicated communications paths where possible, and apply strong cryptography across untrusted or shared links. The guidance highlights dedicated fiber pairs or CWDM wavelengths for distributed environments and recommends dedicated encryption devices rather than relying on encryption built into OT devices for carrier-provided links. The distributed-infrastructure recommendations characterize carrier services as untrusted and potentially hostile from the perspective of a critical operator.
This is a strategically sound position. A private MPLS service may be operationally useful, but it is not the same thing as a security boundary that a critical system can trust without additional safeguards.
That message matters in Windows-heavy enterprises because segmentation is often implemented through centrally managed switching fabrics and network automation systems. A single compromised management plane, misapplied template, privileged account, or configuration error can then undermine numerous logical boundaries at once.
CI Fortify recommends securing the network control plane, using dedicated management interfaces and out-of-band infrastructure where possible, and limiting device administration to trusted management hosts such as privileged access workstations. The secure management-zone guidance recognizes that isolation mechanisms themselves must be protected from an attacker who has reached administrative infrastructure.
That warning is essential. One-way transfer technology can be powerful for sending process telemetry outward, but OT protocols frequently rely on bidirectional exchanges, acknowledgements, timing expectations, or stateful sessions. A security control that breaks a process may create its own operational incident.
Its illustrative progression for an electrical transmission operator is instructive:
For Windows and enterprise infrastructure teams, a graduated plan should identify actions that can be executed reliably and audited afterward. That may include disabling specific VPN groups, blocking remote desktop or remote-management access at designated boundaries, suspending vendor accounts, withdrawing routes, denying specific firewall policies, disabling cloud synchronization, isolating shared services, and transitioning to local identity or local administration modes.
The vital qualifier is that these measures must be tested under realistic operating conditions. A PowerShell script that disables access in a lab is not a crisis capability unless it has been validated against production dependencies, emergency procedures, safety constraints, privilege boundaries, and reversal conditions.
CI Fortify directs operators to consider competition for vendors, integrators, consumable suppliers, fuel, chemicals, and incident responders during a crisis. It also recommends addressing service-level agreements, prioritised support, external recovery dependencies, and emergency communications. The human-planning provisions are a reminder that technical segmentation alone cannot solve a logistics or staffing failure.
For organisations dependent on Windows-based OT support ecosystems, this may mean retaining secure local copies of installers, firmware, drivers, configurations, license files, documentation, approved patches, recovery media, and administrative procedures. Those copies must be protected from tampering, version-controlled, accessible in an emergency, and tested for usability.
These are serious operational concerns. An isolated environment can become difficult to observe, difficult to update, and difficult to repair. It may force staff into manual procedures that are slower, more error-prone, and more exhausting. It can interrupt routine maintenance, regulatory reporting, billing, supply-chain coordination, and communications with customers or dependent infrastructure providers.
The right interpretation is not that isolation should be avoided. It is that isolation must be engineered as a sustainable operating mode, not treated as a dramatic cable-pulling event.
A sound recovery approach should include a clear authority model, validation of system integrity, staged restoration of links, monitoring for unexpected traffic, credential review, configuration comparison, and lessons learned from the isolated period. While the companion CI Fortify materials place strong emphasis on rebuilding vital OT and enabling systems, the isolation guidance itself makes clear that separation reduces the time needed to evict malicious actors and restore normal services. The broader CI Fortify resilience model ties isolation and rebuild capability together.
Then identify every system, workflow, facility, and operator role required to deliver that baseline. This inventory should distinguish vital systems from merely important ones.
Pay special attention to shared Windows infrastructure. A domain controller, DNS server, Hyper-V cluster, file server, SQL instance, or backup appliance may support both enterprise and OT environments. That shared role can become the exact point at which a supposedly segregated environment fails to operate independently.
Where complete separation is impossible, document the residual exposure honestly. Use dedicated communications paths, hardened edge systems, explicit traffic restrictions, and independently managed encryption devices where appropriate, consistent with the guidance for distributed critical networks.
Then test it. Start with tabletop exercises, move to technical validation in representative environments, and conduct controlled operational tests that prove the organisation can sustain its defined minimum service. The guidance’s recommendation to test all vital systems periodically is demanding, but it is also the standard most likely to expose hidden dependencies before an attacker does. CI Fortify’s testing guidance is clear on that point.
That is the framework’s greatest strength. It shifts OT cybersecurity from an optimistic model of continuous connectivity and available support to a resilience model designed for degraded, disconnected, and contested conditions.
Its risks are equally clear. Isolation projects can be costly, technically complex, and disruptive to normal business operations. They can reveal uncomfortable dependence on managed service providers, cloud platforms, centralized Windows services, vendor contracts, and shared enterprise infrastructure. They can also create a false sense of security if organisations mistake VLANs, diagrams, or untested procedures for a genuine ability to operate independently.
But those risks are arguments for disciplined implementation—not reasons to defer the work. CI Fortify’s core lesson is that critical infrastructure cannot wait until a crisis to discover what it takes to run alone. The organisations best positioned to preserve vital services will be those that identify their true dependencies now, build separation deliberately, and make isolation a practiced operational capability rather than an emergency improvisation.
Overview: A Resilience Strategy Built for Disconnection
CI Fortify is notable because it does not treat network isolation as a last-ditch technical response that starts after ransomware has spread or remote access has been abused. Instead, it asks operators to engineer isolation in advance, document it, rehearse it, and prove that critical functions can survive without the digital conveniences that normal operations increasingly depend on.That includes more than internet access. A credible isolation plan must consider whether a site can operate if it loses corporate identity systems, cloud management tools, vendor remote support, shared storage, centralized DNS, external time synchronization, carrier networks, remote monitoring, and even normal communications with suppliers and partner organisations. The guidance explicitly positions isolation as a method to maintain critical-service continuity, contain active incidents, disrupt an attacker’s ability to pivot, and create a safer environment for rebuilding compromised systems.
This is a meaningful evolution in critical infrastructure cybersecurity. Conventional incident-response plans often assume that staff can call a vendor, retrieve a configuration from a cloud portal, authenticate using a centrally managed directory, open a remote support case, or receive software updates from the internet. CI Fortify instead asks whether those assumptions hold in a prolonged crisis—and what happens if they do not.
For Windows administrators, infrastructure architects, and OT security teams, the implication is immediate: systems that seem peripheral in an enterprise environment can become operationally decisive when they underpin engineering workstations, historian access, patch repositories, domain authentication, certificate services, virtualization platforms, or industrial network management.
Background: Why Isolation Has Moved to the Forefront
Critical infrastructure is increasingly exposed to a threat environment in which attackers seek persistence, intelligence collection, coercive leverage, and the potential to disrupt physical processes. The joint guidance notes that state-sponsored actors target critical infrastructure for espionage and may pre-position themselves for disruptive or destructive activity in a crisis or conflict, while cybercriminals continue to target operators for extortion and ransomware. The published advice therefore focuses on reducing an adversary’s freedom of movement rather than assuming every intrusion can be prevented at the perimeter.The broader CI Fortify initiative has already established a high-level expectation that operators should be able to disconnect vital OT and enabling systems from external networks while sustaining critical services, then rebuild affected systems quickly. Australia’s earlier CI Fortify material set a target of maintaining isolated vital OT and enabling systems for three months, alongside the ability to fully rebuild them to minimize service disruption. ASD’s CI Fortify announcement describes those twin objectives as isolation and rapid reconstruction.
The newly published advice provides the technical depth behind that direction. It is less a product checklist than an operational resilience framework. It requires organisations to understand what truly has to stay on, which systems enable that outcome, where connections cross trust boundaries, and how those connections can be removed without creating a worse safety or availability problem.
OT Is Not Simply Enterprise IT With Different Devices
A Windows server supporting an industrial site may look familiar to a traditional IT team, but the consequences of a poorly timed restart, broken name resolution path, expired certificate, or unavailable engineering application can be fundamentally different. OT environments exist to monitor and control physical processes—water treatment, electricity delivery, manufacturing, pipeline flow, railway signalling, building systems, and other real-world functions.That difference explains why availability, safety, process integrity, and predictable operation must shape isolation planning. Cutting a connection that supports a remote vendor may reduce attack surface, for example, but it can also disable a safety-monitoring workflow, create a manual workload that staff cannot safely sustain, or interrupt communications required by a distributed operation.
CI Fortify’s strongest contribution is its insistence that those trade-offs be studied before a crisis. The guidance instructs operators to identify their minimum set of systems and networks required to deliver a critical service, identify dependent critical customers, establish a service-delivery target, and map the supporting connections in sufficient detail to make deliberate decisions under pressure. The critical-path model begins with those foundational tasks rather than jumping immediately to firewalls or VLANs.
The Critical Path to Isolation
The guidance lays out a structured path from understanding critical services to building and testing the ability to isolate them. That sequence deserves attention because it prevents a common failure mode: deploying more segmentation technology without proving that it actually supports business continuity.1. Identify Vital Systems and Critical Customers
The first challenge is defining what “vital” means. It does not mean every system that is important, expensive, difficult to replace, or politically visible. It means the minimum set of systems and networks required to deliver a critical service.That distinction forces hard decisions. A corporate reporting portal, for example, may be highly useful but not essential to maintaining a minimum level of water treatment. Conversely, a modest Windows-based application server that hosts an engineering utility, local authentication role, or protocol conversion function may be indispensable even if it does not appear on a traditional asset-criticality dashboard.
The guidance also tells operators to identify their critical customers and set an explicit service-delivery target. Examples include a defined quantity and quality of electric power or a specified volume of water delivered per day. CI Fortify’s isolation advice makes this customer-centered approach central to the exercise.
That is an important correction to technology-first security planning. An organisation cannot sensibly choose isolation controls until it knows the minimum operational outcome those controls must protect.
2. Establish Levels of Criticality and Trust
Next, operators are urged to classify hosts and networks according to criticality and threat exposure, grouping them into appropriate segments and zones. In practical terms, this means recognizing that the same broad OT environment may contain systems with dramatically different roles:- Safety-related controllers and supervisory systems
- Human-machine interface, or HMI, workstations
- Engineering workstations and programming tools
- Historians and process-data collectors
- Domain controllers and directory-dependent services
- Patch-management, backup, and virtualization systems
- Vendor jump hosts and remote-access platforms
- Corporate reporting, analytics, and maintenance systems
3. Map Every Relevant Connection
This is where many isolation programs become difficult—and where they become valuable. CI Fortify advises organisations to identify and record all interconnections between critical networks and other systems, including links to corporate systems, vendor remote access, untrusted networks, cloud environments, peer critical networks, and communications services such as carrier networks, mobile, satellite, radio, and Wi-Fi. The connection-mapping requirements also call for recording technical details such as owners, providers, information flows, protocols, architecture diagrams, router and firewall configurations, VPN details, RPOs, RTOs, and emergency contacts.For a Windows-centric environment, this mapping needs to go beyond obvious TCP/IP routes. Teams should document dependencies such as:
- Active Directory authentication and Group Policy
- DNS resolution, including conditional forwarders and external resolvers
- DHCP scopes and relay configurations
- Network Time Protocol or Precision Time Protocol dependencies
- Public key infrastructure, certificate enrollment, and revocation checks
- Shared hypervisors, clusters, management planes, and storage networks
- Backup repositories, configuration management platforms, and licensing servers
- Remote desktop gateways, VPN concentrators, jump servers, and privileged access workstations
- Microsoft SQL Server, file shares, Windows services, COM/DCOM paths, and vendor-specific middleware
Separation Points: Where Network Design Becomes Crisis Capability
Once dependencies are mapped, the task becomes designing effective separation and isolation points. These are not merely firewall rules. They are deliberate boundaries at which operators can stop untrusted or lower-trust connectivity from reaching vital systems while preserving the functions required for safe service delivery.The guidance distinguishes between physical separation and isolation. Physical separation means independence of infrastructure: vital OT should not share active network equipment, compute elements, or controllable supporting infrastructure with non-vital systems. Isolation is the ability to disconnect and continue operating independently when needed. CI Fortify’s explanation emphasizes that both matter, and that physical isolation requires no shared connectivity or infrastructure between vital and non-vital systems.
Physical Isolation Is the Goal, Not Always the Starting Point
The document is candid that complete physical isolation may be impractical for internet-facing services, geographically distributed infrastructure, or operations that depend on external communications. Yet it does not use that constraint as an excuse for weak boundaries.Where full separation is not feasible, operators are directed to harden OT boundaries, reduce non-OT dependencies, use dedicated communications paths where possible, and apply strong cryptography across untrusted or shared links. The guidance highlights dedicated fiber pairs or CWDM wavelengths for distributed environments and recommends dedicated encryption devices rather than relying on encryption built into OT devices for carrier-provided links. The distributed-infrastructure recommendations characterize carrier services as untrusted and potentially hostile from the perspective of a critical operator.
This is a strategically sound position. A private MPLS service may be operationally useful, but it is not the same thing as a security boundary that a critical system can trust without additional safeguards.
VLANs Are Useful—but Not an End State
One of the more valuable sections addresses the limits of administrative controls. CI Fortify states that controls such as VLANs, IP access lists, route blocking, and routing black holes can serve as interim measures, but they do not provide the assurance of physical or cryptographic isolation. The administrative-controls guidance explicitly warns that VLANs should not become a permanent substitute for a fully segregated operations network.That message matters in Windows-heavy enterprises because segmentation is often implemented through centrally managed switching fabrics and network automation systems. A single compromised management plane, misapplied template, privileged account, or configuration error can then undermine numerous logical boundaries at once.
CI Fortify recommends securing the network control plane, using dedicated management interfaces and out-of-band infrastructure where possible, and limiting device administration to trusted management hosts such as privileged access workstations. The secure management-zone guidance recognizes that isolation mechanisms themselves must be protected from an attacker who has reached administrative infrastructure.
Data Diodes and Cross-Domain Solutions
For some environments, information has to cross between critical and non-critical zones even during heightened threat conditions. The guidance identifies data diodes and cross-domain solutions, or CDS, as technologies that can enable tightly controlled data transfer with higher assurance than standard gateways—provided they are designed, configured, and maintained correctly. The CI Fortify section on data diodes and CDS cautions that improper deployment can damage operational integrity, including by disrupting required handshakes.That warning is essential. One-way transfer technology can be powerful for sending process telemetry outward, but OT protocols frequently rely on bidirectional exchanges, acknowledgements, timing expectations, or stateful sessions. A security control that breaks a process may create its own operational incident.
A Graduated Plan Is Better Than a Single Emergency Switch
The idea of shutting everything off at once is simple, but it is rarely safe or practical. CI Fortify promotes a graduated isolation plan that progressively removes pathways into vital OT systems as the threat environment worsens, while still treating complete isolation of the most vital systems as the intended end state. The isolation-plan guidance calls for predefined trigger criteria aligned with incident-response planning.Its illustrative progression for an electrical transmission operator is instructive:
- Disable remote-worker access to OT through intermediate systems.
- Disable on-premises remote access to OT.
- Isolate non-OT from OT environments.
- Isolate lower-priority peer OT connections.
- Fully isolate the OT environment and vital systems.
For Windows and enterprise infrastructure teams, a graduated plan should identify actions that can be executed reliably and audited afterward. That may include disabling specific VPN groups, blocking remote desktop or remote-management access at designated boundaries, suspending vendor accounts, withdrawing routes, denying specific firewall policies, disabling cloud synchronization, isolating shared services, and transitioning to local identity or local administration modes.
The vital qualifier is that these measures must be tested under realistic operating conditions. A PowerShell script that disables access in a lab is not a crisis capability unless it has been validated against production dependencies, emergency procedures, safety constraints, privilege boundaries, and reversal conditions.
Testing, Documentation, and the Human Element
CI Fortify strongly emphasizes that plans cannot remain documents. Operators should regularly test isolation plans, test the isolation of all vital systems rather than a convenient subset, and store secure offline hard copies of those plans. The testing recommendations recognize a basic reality: during a major incident, online documentation repositories and enterprise collaboration platforms may be unavailable or untrusted.What a Meaningful Exercise Should Prove
A robust OT isolation exercise should test more than whether packets stop crossing a firewall. It should demonstrate:- That minimum service targets can still be met.
- That safety controls retain their intended behavior.
- That operations staff can communicate through fallback channels.
- That essential identities, time services, certificates, configuration files, and engineering tools remain available.
- That manual workflows are documented and staffed.
- That the organization can identify and monitor accidental reconnection.
- That leadership understands which business functions must be suspended during the isolated state.
The Need for OT Sovereignty
Perhaps the most challenging aspect of the guidance is its implicit call for operational sovereignty. An organisation may own its facilities but still lack the people, materials, credentials, software, or support arrangements needed to run them independently.CI Fortify directs operators to consider competition for vendors, integrators, consumable suppliers, fuel, chemicals, and incident responders during a crisis. It also recommends addressing service-level agreements, prioritised support, external recovery dependencies, and emergency communications. The human-planning provisions are a reminder that technical segmentation alone cannot solve a logistics or staffing failure.
For organisations dependent on Windows-based OT support ecosystems, this may mean retaining secure local copies of installers, firmware, drivers, configurations, license files, documentation, approved patches, recovery media, and administrative procedures. Those copies must be protected from tampering, version-controlled, accessible in an emergency, and tested for usability.
Risks of Isolation: The Guidance Avoids Magical Thinking
CI Fortify is persuasive precisely because it does not portray isolation as risk-free. The guidance flags several hazards of operating isolated systems, including delayed patching, reduced external visibility, and greater reliance on removable media that can itself introduce malware. Its isolated-systems risk section also notes that systems used to scan removable media may not receive updates during an extended isolation period.These are serious operational concerns. An isolated environment can become difficult to observe, difficult to update, and difficult to repair. It may force staff into manual procedures that are slower, more error-prone, and more exhausting. It can interrupt routine maintenance, regulatory reporting, billing, supply-chain coordination, and communications with customers or dependent infrastructure providers.
The right interpretation is not that isolation should be avoided. It is that isolation must be engineered as a sustainable operating mode, not treated as a dramatic cable-pulling event.
Reconnection Is a Security Event
The period after isolation deserves as much planning as isolation itself. Any reconnection can reintroduce an attacker, propagate malware, overwrite local changes, re-enable vulnerable remote access, or restore dependencies before they have been assessed.A sound recovery approach should include a clear authority model, validation of system integrity, staged restoration of links, monitoring for unexpected traffic, credential review, configuration comparison, and lessons learned from the isolated period. While the companion CI Fortify materials place strong emphasis on rebuilding vital OT and enabling systems, the isolation guidance itself makes clear that separation reduces the time needed to evict malicious actors and restore normal services. The broader CI Fortify resilience model ties isolation and rebuild capability together.
What Organisations Should Do Now
The practical value of CI Fortify lies in turning a broad resilience objective into an implementation program. The following sequence reflects the guidance’s priorities while translating them into actionable work for OT, IT, and security leadership.Establish the Critical-Service Baseline
Define the minimum service that must continue for every critical function. Avoid vague labels such as “keep the plant operational.” Use measurable outcomes: minimum throughput, essential coverage, acceptable quality, required safety posture, and critical dependent customers.Then identify every system, workflow, facility, and operator role required to deliver that baseline. This inventory should distinguish vital systems from merely important ones.
Build a Dependency Map That Includes Windows Infrastructure
Create a living dependency model, not a static diagram created for an audit. Include network paths, physical links, application flows, identity services, storage, virtualization, cloud platforms, remote support, monitoring, patching, backups, certificates, time sources, and vendor licensing.Pay special attention to shared Windows infrastructure. A domain controller, DNS server, Hyper-V cluster, file server, SQL instance, or backup appliance may support both enterprise and OT environments. That shared role can become the exact point at which a supposedly segregated environment fails to operate independently.
Design and Prioritize Isolation Points
Identify which connections can be disabled immediately, which need a controlled transition, and which cannot be removed until an alternate capability is built. Build isolation around durable boundaries—physical separation, dedicated infrastructure, hardened management zones, and strong cryptographic protection—rather than depending exclusively on logical segmentation.Where complete separation is impossible, document the residual exposure honestly. Use dedicated communications paths, hardened edge systems, explicit traffic restrictions, and independently managed encryption devices where appropriate, consistent with the guidance for distributed critical networks.
Write a Graduated Playbook and Test It
Define threat-based triggers, decision authorities, isolation stages, communications plans, manual procedures, monitoring requirements, and conditions for reconnection. Store essential versions offline, including hard copies where suitable.Then test it. Start with tabletop exercises, move to technical validation in representative environments, and conduct controlled operational tests that prove the organisation can sustain its defined minimum service. The guidance’s recommendation to test all vital systems periodically is demanding, but it is also the standard most likely to expose hidden dependencies before an attacker does. CI Fortify’s testing guidance is clear on that point.
The Strategic Significance of CI Fortify
CI Fortify does not replace patching, multifactor authentication, secure remote access, asset inventory, endpoint security, backups, monitoring, or incident response. It changes how those controls should be evaluated. The crucial question is no longer only, “Can this control reduce the chance of compromise?” It is also, “Can this system and service continue safely when compromise is assumed and external connectivity is deliberately constrained?”That is the framework’s greatest strength. It shifts OT cybersecurity from an optimistic model of continuous connectivity and available support to a resilience model designed for degraded, disconnected, and contested conditions.
Its risks are equally clear. Isolation projects can be costly, technically complex, and disruptive to normal business operations. They can reveal uncomfortable dependence on managed service providers, cloud platforms, centralized Windows services, vendor contracts, and shared enterprise infrastructure. They can also create a false sense of security if organisations mistake VLANs, diagrams, or untested procedures for a genuine ability to operate independently.
But those risks are arguments for disciplined implementation—not reasons to defer the work. CI Fortify’s core lesson is that critical infrastructure cannot wait until a crisis to discover what it takes to run alone. The organisations best positioned to preserve vital services will be those that identify their true dependencies now, build separation deliberately, and make isolation a practiced operational capability rather than an emergency improvisation.
References
- Primary source: CISA
Published: 2026-07-28T12:00:00+00:00
- Related coverage: cyber.gov.au
- Related coverage: mondaq.com
CISA’s "CI Fortify” Initiative Signals New Expectations For Critical Infrastructure Resilience: What Operators And Vendors Need To Know - Terrorism, Homeland Security & Defence - United States
On May 5, 2026, CISA announced CI Fortify — an initiative directing critical infrastructure owners and operators to prepare for geopolitical conflict in which OT networks are actively targeted while communications...
www.mondaq.com
