CI Fortify Defines Isolation as a Core OT Capability. Most Remote Access Architecture Cannot Satisfy It by Design

In May 2026, CISA launched CI Fortify, a nationwide initiative to strengthen the resilience of US critical infrastructure against the threat scenarios CISA now treats as baseline: nation-state actors already pre-positioned inside OT networks, operating quietly, waiting for a geopolitical trigger.

The guidance does not hedge. CISA's explicit planning assumption is that in a conflict scenario, third-party connections (telecommunications, internet, vendors, service providers, upstream dependencies) will be unreliable, and that threat actors will already have some access to the OT network. The question CI Fortify asks operators to answer is not how to prevent intrusion. It is how to survive after one.

Two capabilities sit at the center of CI Fortify: isolation and recovery. Isolation means deliberately severing connections to outside networks and business systems to prevent an attack from spreading to OT, while maintaining an operating mode capable of sustaining delivery of essential services for weeks or months. Recovery means restoring compromised systems while operating in that isolated state. CISA is conducting targeted assessments of participating operators to evaluate whether these capabilities actually exist.

This is where architecture starts to matter in procurement decisions.

What "Isolation Capability" Actually Means Under CI Fortify

The CI Fortify framing of isolation as a capability is meaningful, because capability implies something an operator must actively do. Sever connections. Cut third-party access. Switch to an isolated operating mode. This is the premise most OT security programs are built on: you build the isolation as an incident response step.

VPN, ZTNA, and software PAM gateways all satisfy this model, technically. You can disable a VPN tunnel. You can revoke ZTNA access policies. You can shut down a PAM gateway. In a conflict scenario where CISA's guidance says to isolate, an operator using any of these architectures would execute a severance event and document that they did so.

The gap in this approach is the window before severance. During an active conflict scenario, the network path between remote users and OT assets exists until someone closes it. The threat actors already pre-positioned in that network (per CISA's own planning assumption) have that window. If the decision to sever is delayed, misrouted, or disrupted by the same attack that triggered the isolation requirement in the first place, the capability degrades exactly when it is needed most.

This is reactive isolation: the network path exists as the default state, and isolation requires an action to achieve it.

How Fantom Satisfies CI Fortify Isolation by Architecture

The Fantom appliance operates on a different premise. It implements air-gapped remote access without an IP path between the remote user and the protected OT asset. The appliance transmits only pixels outbound. It accepts only mouse and keyboard input inbound. No packets cross the boundary in either direction. No IP connectivity is established.

The consequence of this architecture is straightforward: there is no third-party connection to sever in a conflict scenario, because no IP connection was ever established. CI Fortify asks operators to build the capability to cut. Fantom removes the need for a cut to occur.

This is structural isolation: the isolated state is the default operating condition, not a contingency mode the operator switches into.

For a CISA assessor evaluating an operator's isolation capability, the distinction is architectural. A software-defined access system demonstrates isolation capability by showing a documented severance procedure and an operational response plan. A hardware-enforced non-IP access system demonstrates isolation capability by showing that no IP path exists to sever. The architecture is the evidence.

The Procurement Implication

CI Fortify is not a compliance checkbox. CISA is conducting targeted assessments. Operators who participate will need to document and demonstrate their isolation capability, not just describe it in a policy document.

For procurement leads at energy, water, transport, and defense industrial base organizations, this creates a concrete architectural question: does the remote access architecture in use satisfy CI Fortify's isolation requirement structurally, or does it require an operational response to satisfy it?

Software-defined access architectures, including VPN, ZTNA, and PAM gateways, satisfy it operationally. The isolation capability exists in the procedure, not in the architecture. The architecture permits connection until the procedure is executed.

Hardware-enforced non-IP access satisfies it structurally. The architecture does not permit an IP connection. No procedure is required because no connection exists to sever.

For operators preparing for CISA targeted assessments, the architecture decision made during procurement is the isolation capability decision. There is no layer of policy or procedure that converts a connected architecture into a structurally isolated one.

Software-defined gateways illustrate what happens when the gateway itself is the attack surface (CVE-2026-0300 in PAN-OS is just the latest example, with active exploitation observed in the wild and root-level RCE on the appliance). The broader point from CI Fortify is earlier: the architecture that permits the connection is the architecture that must be severed. The more reliable approach is to not permit the connection in the first place.

See how Fantom delivers CI Fortify isolation by architecture, not by contingency. Book a demo.

‍