Back to Knowledge Vault

CISA CI Fortify: why Isolation and Recovery point straight at Layer 1 storage

CISA's CI Fortify initiative tells critical infrastructure operators to plan for forced isolation and rapid recovery. Mark Fermor on what that means for OT, ICS and the storage layer underneath them.

In February 2026 CISA published CI Fortify, an allied initiative that asks critical infrastructure operators to prepare for a very specific scenario: a geopolitical crisis in which third-party connections, telecoms, vendors and upstream dependencies all become unreliable, while a determined adversary already has some access to the operational technology network. The guidance is unusually direct. Operators are told to invest now in two capabilities, Isolation and Recovery, so that vital services can keep running during the crisis rather than collapse with it.

For anyone building, defending or insuring industrial control systems, this is a significant shift in tone from CISA, the NCSC, the Australian Cyber Security Centre and the Canadian Centre for Cyber Security, all of whom now point in the same direction. It also lands squarely on a question Firevault has been asking customers for years: where does the gold copy of your operational data actually live, and is it reachable by the same adversary you are trying to defend against.

What CISA is asking operators to do

CI Fortify defines two emergency planning objectives. Isolation means proactively disconnecting from third-party and business networks to keep essential services running in a degraded communications environment. Recovery means documenting systems, backing up critical files, and rehearsing the replacement of components or the transition to manual operation when isolation fails and equipment is rendered inoperable.

Nick Andersen, CISA''s Acting Director, framed it plainly. In a geopolitical crisis, the organisations Americans rely on must be able to keep delivering at least the crucial services, isolate vital systems from harm, continue operating in that isolated state, and quickly recover any systems an adversary has compromised. The same logic applies to UK and European operators bound by NIS2, the Cyber Assessment Framework and DORA.

Isolation is a storage problem, not just a network problem

Most operators read the word "isolation" as a network exercise: shutting down VPNs, severing vendor remote access, killing internet egress at the boundary firewall. That is necessary, but it is not sufficient. The moment you isolate, the question becomes what data, configurations and runbooks the site has on the inside of that boundary.

If your golden images, PLC programs, SCADA project files, safety-system configurations and recovery runbooks live in a cloud bucket, an MSP tenant or a corporate file share, then "isolation" leaves the plant without the very assets it needs to keep running. Worse, if any of those assets has been quietly modified by an adversary already on the network, the operator has no clean copy to fall back to. Layer 1 path control for OT environments exists to close that gap, by putting an operator-controlled, physically disconnected copy of the operational state inside the isolation boundary.

Recovery only works if the gold copy survived the attack

CI Fortify is unusually candid about recovery. It tells security vendors to communicate tactics that prevent recovery, including malicious firmware updates, and to flag vulnerabilities in software-based data diodes that can break isolation. That language matters. It accepts that backups, snapshots and replication are themselves part of the attack surface. Anything reachable over a network or an API can be encrypted, deleted or silently corrupted before the operator notices.

Firevault''s position is straightforward. The recovery copy of an OT environment should be held offline by default, brought online only by a deliberate, audited human action, and held in infrastructure that the operator controls. That is what Layer 1 Offline Secure Storage delivers. It is not another network tier with a friendlier label. It is a physical break in the path, so that a compromise of the IT estate, the OT estate, the MSP, the cloud account or the vendor cannot, by design, reach the gold copy.

Where Firevault fits

CI Fortify is clear that the responsibility sits with the operator, supported by vendors, integrators and security providers. Firevault sits in the security-vendor and storage-vendor lane, with three deliberate choices that line up with the CISA guidance:

• Protection through physical disconnection. The Vault is offline by default. There is no always-on path for an attacker to traverse, so encryption, deletion and silent tampering of the gold copy are stopped at Layer 1, not at a policy or an alert.
• Operator-owned recovery state. Golden images, PLC and DCS programs, safety-system configurations, P&ID drawings, firmware and runbooks live where the people accountable for the plant can reach them, even when telecoms, vendors and the corporate network are unavailable.
• Auditable, human-gated access. Every connection event is logged, so NIS2, the Cyber Assessment Framework, DORA and the safety case all have evidence that the recovery copy was untouched between incidents.

This is the same architecture the Offline Secure Storage core applies to critical infrastructure, and it is why the bunker network is built around operator control of the physical path rather than a single jurisdiction or provider.

Practical next steps for CNI and OT operators

• Inventory the recovery dependency chain. For every safety-critical and service-critical system, write down where the gold copy lives, what network it sits on, and which third party can reach it. If any link in that chain breaks under CI Fortify''s isolation assumption, treat it as a finding.
• Separate the recovery copy from the production network. A backup that shares a control plane, an identity provider or an API surface with production is not a recovery copy in CI Fortify terms. Move it behind a physical break.
• Rehearse a cold restart from offline media. Tabletop and live exercises should assume the MSP, the cloud and the corporate WAN are unavailable. Time the restart and record what was missing.
• Align the evidence. Tie the offline recovery copy to the obligations in NIS2, DORA, the Cyber Assessment Framework and the relevant safety case, so the same artefact serves regulators, insurers and the board.
• Read the partner guidance. The NCSC severe cyber threat guide, the ACSC CI Fortify page and the CCCS resilience initiative say the same thing in slightly different words.

Key Takeaways

• CI Fortify changes the planning baseline. Operators are now expected to assume forced isolation and partial OT compromise as a planning case, not a worst case.
• Isolation without local data is theatre. Cutting the network is only useful if the golden images, configurations and runbooks the plant needs are already inside the boundary.
• Network-reachable backups are part of the attack surface. CISA itself flags malicious firmware and data-diode software flaws as recovery blockers.
• Layer 1 storage closes the gap. A physically disconnected, operator-controlled copy of the recovery state is the simplest way to satisfy both the Isolation and Recovery objectives.
• The evidence is reusable. The same offline copy supports NIS2, DORA, the Cyber Assessment Framework, the safety case and the insurer questionnaire.

If you want to walk through CI Fortify against your own OT estate, book a briefing with the Firevault team. We will map your current recovery chain, mark the points where CI Fortify''s assumptions break it, and show how Layer 1 Offline Secure Storage removes them.

Mark Fermor, Founder, Firevault.

Share this article