CISA's CI Fortify (May 2026): Planning Critical Infrastructure for Cyber Isolation and Recovery

CISA's guidance over the last several years has mostly addressed prevention: secure-by-design software, patching cadence, multifactor authentication, the cross-sector performance goals. The initiative the agency launched on May 5, 2026 starts from a different premise. CI Fortify assumes that during a geopolitical crisis, an adversary may succeed in severing a critical infrastructure operator's connections to the internet, telecommunications, and other technology services, and it asks operators to plan for how they will keep delivering essential services anyway.

This is a notable reframing. Rather than treating disconnection as the failure state, CI Fortify treats deliberate disconnection as a defensive tool and continued operation under degraded conditions as the goal. Acting CISA Director Nick Andersen said the agency would conduct targeted assessments prioritizing defense-critical infrastructure, naming dams, radars, and satellite communications systems. The framing is squarely about resilience under conflict conditions, not routine incident response.

For the security teams who run the software inside water utilities, transportation systems, and the other sectors in scope, the practical question is what CI Fortify asks them to be able to do. The answer touches operational technology, manual fallback procedures, and, less obviously, the software supply chain that the recovery objective depends on.

TL;DR

• On May 5, 2026, CISA launched CI Fortify, a crisis-planning initiative for critical infrastructure facing cyberattacks during a geopolitical crisis.
• The initiative has two primary objectives: isolation (proactively disconnecting from third-party and business networks to protect operational technology while maintaining essential services) and recovery (documenting systems, backing up critical files, and practicing replacement or transition to manual operation).
• CISA recommends operators prepare to run in isolation from internet and telecom, work with local emergency planners, understand dependencies on lifeline sectors, and define acceptable downtime limits.
• Acting Director Nick Andersen said CISA will conduct targeted assessments prioritizing defense-critical infrastructure including dams, radars, and satellite communications.
• The recovery objective has a software supply chain dimension: you cannot practice replacing a system if you cannot rebuild it without internet access, which depends on knowing and locally caching what it is built from.
• This is guidance and assessment, not a binding rule, but defense-critical operators should expect targeted CISA attention.

What CI Fortify asks for

CI Fortify is built around two emergency planning objectives, and both are operational rather than documentary.

The isolation objective asks operators to be able to "proactively disconnect from third-party and business networks" to protect operational technology, while maintaining essential services rather than shutting down completely. The distinction is important. A full shutdown is easy; the hard problem is severing the network paths an adversary could use while keeping the physical process, the water treatment, the rail signaling, the generation, running. That requires knowing which connections are load-bearing for safety and which are conveniences that can be cut.

The recovery objective asks operators to be ready to restore operation when an attack disables critical systems. CISA describes this as "documenting systems, backing up critical files, and practicing the replacement of systems or the transition to manual" operation. The emphasis on practicing is the part that separates CI Fortify from a paper exercise. An organization that has documented its systems but never rehearsed bringing them back, or running them by hand, does not actually have the capability the guidance is asking for.

Around those two objectives, CISA's recommendations are concrete:

• Prepare to operate in isolation from internet and telecommunications services.
• Work with local emergency planners and military facilities.
• Understand dependencies with lifeline sectors such as chemicals and fuel.
• Determine acceptable downtime limits.
• Coordinate with vendors on emergency planning support.

The vendor coordination point and the recovery objective are where the software supply chain enters the picture, and it is worth drawing that connection out because it is easy to miss in a document framed around physical resilience.

The supply chain dimension of recovery

"Practicing the replacement of systems" sounds like a hardware and configuration exercise, and much of it is. But replacing or rebuilding a software-driven control system during a crisis, with the internet unavailable, surfaces a dependency that most operators have never tested: can you rebuild your software without reaching out to the public package registries, container registries, and update servers it normally pulls from?

For most modern systems the honest answer is no. A control application that builds from a package manifest will, on a clean rebuild, try to resolve dependencies from public registries. A containerized component will try to pull base images from a public registry. An appliance will try to validate or fetch updates from a vendor endpoint. Under the isolation objective, every one of those network calls fails, and the rebuild stalls.

This is the same offline-rebuild problem that air-gapped environments have always faced, now surfaced as a resilience requirement for a much broader population. The capability CI Fortify implies is that an operator can reconstruct a known-good version of a critical system from locally held materials. That, in turn, requires three things that are squarely supply chain hygiene:

1. A precise inventory of what each critical system is built from. Without a software bill of materials for the system, you do not know what to cache, and you cannot verify that a rebuilt system matches the version you trust.
2. Locally held copies of those materials. The packages, images, and artifacts that compose the system must be mirrored somewhere reachable without internet access, with their integrity verifiable offline.
3. A verifiable known-good baseline. When you rebuild, you need a way to confirm the result is the version you intended and has not drifted or been tampered with, ideally through signed artifacts and recorded provenance.

The recovery objective, read carefully, is asking operators to demonstrate exactly this. The isolation objective is what makes it hard, because it removes the network the normal build path assumes.

What a tested recovery baseline looks like

The following is an illustrative checklist, not a configuration, of what "practicing replacement" means for a software-driven critical system under isolation conditions.

# Illustrative offline-rebuild readiness check — not a script
[ ] SBOM exists for each critical system, current as of last release
[ ] All direct and transitive dependencies mirrored to an offline cache
[ ] Base container images mirrored to an internal registry reachable offline
[ ] Artifact signatures and provenance verifiable without internet access
[ ] Rebuild from cache succeeds with public network egress blocked
[ ] Rebuilt system hash/signature matches the recorded known-good baseline
[ ] Manual-operation runbook exists and has been rehearsed
[ ] Acceptable downtime limit defined per system, agreed with operations

The first six items are software supply chain work. The last two are the operational resilience work CI Fortify is primarily known for. The point is that they are not separable: you cannot rehearse system replacement if the rebuild path silently depends on the network you have just been told to assume is gone.

What detection and validation look like

CI Fortify is about readiness rather than threat detection, so the relevant signals are validation signals: ways to confirm the capability exists before a crisis tests it.

• Egress-blocked build runs. The most direct validation is to attempt a rebuild of a critical system with public network egress denied at the firewall. A build that succeeds proves the dependencies are mirrored; a build that fails reveals exactly which external dependency is unmet.
• Baseline drift checks. Comparing a freshly rebuilt system against the recorded known-good baseline catches both tampering and unintended drift in the dependency set.
• Connection inventory accuracy. For the isolation objective, periodically reconciling the documented set of network connections against observed traffic confirms you know which connections you would actually be cutting.
• Mirror freshness. An offline cache that has not been updated against the current release of each system is a false sense of security. Tracking the gap between the mirror's contents and the current build inputs is a maintenance signal worth monitoring.

What to do Monday morning

1. Generate or refresh an SBOM for each critical system. You cannot mirror, verify, or rebuild what you have not inventoried. Start with the systems whose loss would breach your acceptable downtime limit fastest.
2. Stand up or audit an offline mirror. Confirm that the packages, images, and artifacts your critical systems depend on are held somewhere reachable without internet access, and that their integrity can be checked offline.
3. Run an egress-blocked rebuild drill. Pick one critical system and attempt to rebuild it with public network access denied. Document every failure; each one is a dependency you did not know was load-bearing.
4. Map and classify your network connections. Separate connections required for safety and essential service from those that are conveniences, so the isolation objective can be executed without taking down the physical process.
5. Define acceptable downtime limits per system. Agree these with operations leadership, not just security. They drive the priority order for everything above.
6. Rehearse manual operation. For the systems where manual fallback is the recovery path, run the runbook with the people who would actually use it, and fix what the rehearsal exposes.

Why this keeps happening

Critical infrastructure has spent two decades connecting operational technology to enterprise networks and the internet for legitimate efficiency reasons: remote monitoring, vendor support, data analytics. Each connection added value and a little risk, and the aggregate is an operating model that quietly assumes constant connectivity. CI Fortify is, in effect, an acknowledgment that this assumption is a strategic vulnerability when the adversary is a nation-state willing to attack connectivity itself.

The recurring failure underneath is that resilience planning and software supply chain hygiene have lived in separate organizations. Resilience teams plan for power loss and physical failure; supply chain security teams worry about malicious dependencies and provenance. CI Fortify sits at the intersection, because the recovery objective requires the supply chain artifacts, the SBOMs, the mirrors, the signed baselines, that the supply chain team produces, applied to a scenario the resilience team owns. Organizations that keep these functions apart will discover the gap during the first egress-blocked rebuild drill, which is the right time to discover it.

The structural fix

The supply chain half of CI Fortify readiness is squarely about knowing and controlling what your systems are built from. Safeguard's SBOM Studio and SBOM capabilities produce the per-system inventory that tells you what to mirror and verify, and SLSA provenance plus signed artifacts give you the verifiable known-good baseline a rebuilt system can be checked against. Drift detection surfaces when a rebuilt or running system diverges from that baseline, which is exactly the validation the recovery objective needs. For the broader compliance posture, the supply chain compliance workflows keep this evidence current rather than as a point-in-time snapshot.

This does not make an operator immune to a connectivity-severing attack. What it does is make the recovery objective achievable: it shortens the time to rebuild a known-good system under isolation, and it reduces the chance that a rebuilt system carries unverified or drifted components into a crisis.

What we know we don't know

As reported, CI Fortify is an initiative with targeted assessments rather than a published rule with defined pass criteria. The specific scope of the targeted assessments, beyond the defense-critical examples Andersen named, is not detailed in the initial coverage, and it is not yet clear whether the assessments will produce binding remediation timelines or remain advisory. The interaction between CI Fortify's isolation objective and vendors' remote-support models is also unresolved in the public material: many critical systems depend on vendor connectivity for support, and the guidance asks operators to coordinate with vendors on emergency planning without specifying how that connectivity is reconciled with the goal of operating in isolation. Operators should treat the offline-rebuild readiness described here as the defensible interpretation of the recovery objective, while watching for more specific assessment criteria as the program matures.

References

• CISA tells critical organizations to prepare for cyber outages — Federal News Network (May 5, 2026)
• CISA unveils CI Fortify to help secure critical infrastructure during conflicts — Nextgov/FCW (May 2026)
• CISA home — agency homepage

Internal reading:

• SBOM Studio
• What is an SBOM
• SLSA provenance
• Drift detection
• Supply chain compliance
• Incident response