On July 28, 2026, CISA, the Australian Signals Directorate's Australian Cyber Security Centre (ACSC), the FBI, and international partners released "CI Fortify – Advice for Isolating Vital Systems." The guidance gives critical infrastructure (CI) operators a practical framework for disconnecting vital operational technology (OT) from corporate, internet-facing, and other less-trusted networks — and for continuing to deliver essential services while isolated. Nearly every step in that framework comes down to two questions: which devices matter, and what paths connect them to everything else. This post summarizes the guidance and outlines how Forward Enterprise helps answer both.
Who should read this post
- Network engineers and architects responsible for segmentation between IT, OT, and vendor/cloud networks
- Incident response and business continuity planners building isolation and crisis-response plan
- Security teams validating that segmentation and isolation controls actually work as designed
What is covered in this post
- Summary of the CI Fortify guidance and why it was issued now
- Key concepts and terminology: vital systems, isolation points, physical vs. graduated isolation
- How Forward helps identify vital-system devices and the paths that connect them
- An NQE query to discover OT/ICS equipment on the network by MAC vendor
Why CISA Issued This Guidance
CI Fortify was published against a backdrop of sustained targeting of critical infrastructure by state-sponsored and criminal actors:
- Volt Typhoon (China-linked) was found to have remained undetected in a U.S. critical infrastructure network for five years, positioning for potentially disruptive attacks during a future crisis.
- Salt Typhoon (China-linked) compromised major U.S. telecom carriers, including AT&T, Verizon, and Lumen, exploiting known vulnerabilities in edge networking devices to pivot between networks.
- Water sector incidents — including a 2024 cyberattack on American Water and a Kansas water treatment facility forced to manual operations — showed how OT compromise can force operational shutdowns.
- Pro-Russian hacktivists have actively sought out unsecured OT systems at water and other CI facilities.
The guidance's premise: organizations that wait until an attack is underway to figure out how to disconnect vital systems will fail to do it cleanly. Isolation has to be planned, mapped, and tested in advance.
Key Concepts in the Guidance
| Term | Description |
| Vital systems | The minimum OT and supporting systems required to deliver a critical service (e.g., water distribution, power delivery, telecom operation) |
| Isolation point | A predetermined location where connectivity between critical and non-critical networks can be disconnected to contain an attack |
| Physical isolation | Fully disconnecting vital systems from shared network/computing infrastructure — the most effective form of protection |
| Graduated isolation | Progressively restricting access as threat escalates (remote workers -> vendors -> corporate network -> all external connections) |
| Administrative network controls | VLANs, ACLs, and routing changes — useful as temporary measures, but not a substitute for physical isolation |
| Data diode | Hardware enforcing one-way data flow, reducing risk of traffic moving back into vital systems |
The recommended process: identify the minimum systems needed to keep a critical service running, document every connection those systems have to corporate networks, remote access, cloud, the internet, vendors, contractors, and other CI operators, then determine where each connection can be disabled. Plans should be tested as a complete isolation, not system-by-system — partial testing misses shared infrastructure and hidden dependencies. A secure offline or printed copy of the plan is also recommended, in case corporate systems are unavailable when it's needed.
The Hard Part: You Can't Isolate What You Haven't Mapped
CI Fortify's first step — identify the minimum systems needed to deliver a critical service — assumes organizations already know which devices are OT. In practice, that inventory is often incomplete. Industrial equipment gets connected to a switch during a project, nobody updates the asset list, and it sits there indefinitely. Connections accumulate the same way: a vendor support tunnel here, a historian replicating to a corporate data lake there, a jump host nobody remembers approving. Spreadsheet-based inventories and network diagrams go stale the moment either changes.
Getting this wrong has consequences in both directions:
- Missed device or connection: An isolation point is triggered, but an unaccounted-for piece of OT equipment, or an undocumented path — an old VPN, a shared switch, a secondary NAT rule — keeps a vital system reachable from the compromised network.
- Over-isolation: Systems are cut off that didn't need to be, disrupting operations unnecessarily during an already stressful incident.
How Forward Enterprise Helps
Identifying Vital-System Devices and Their Connections
Forward Enterprise builds a continuously updated digital twin of the network — routing tables, ACLs, firewall rules, NAT, and VLANs — built directly from actual device configuration and state. Instead of manually documenting which devices make up a vital system and every connection they have to corporate networks, remote access, cloud, and vendors, Forward can generate that inventory and connection map as a query. This turns CI Fortify's first two steps — identify vital systems, document every connection — from a manual survey into something repeatable and current.
Discovering OT/ICS Equipment by MAC Vendor
That first step also assumes the vital-system inventory is complete — and it often isn't. Forward doesn't need protocol-level access to OT equipment to help find it. Every device Forward collects from also reports the hosts attached to it, including the MAC addresses observed on its interfaces and VLANs. Cross-referencing those MAC addresses' IEEE-registered OUI (organizationally unique identifier) against known OT/ICS/SCADA manufacturers — Siemens, Rockwell, Schneider Electric, ABB, Honeywell, and others — surfaces industrial equipment (PLCs, HMIs, RTUs, industrial switches, sensors) present on the network, including on segments where it may not belong.
This uses data Forward already collects for every device — no protocol decoding or endpoint agents required — and gives OT/IT convergence and security teams a starting point for building or correcting the vital-systems inventory CI Fortify asks for. OUI matching is a hardware-vendor signal, not device-level confirmation, so treat matches as candidates to validate rather than a final classification — but on most production networks, it's a productive starting list.
NQE query to identify network endpoints whose MAC OUI resolves to a known OT/ICS equipment manufacturer:
// @intent: Identify network endpoints whose hardware (MAC) vendor is a known Operational Technology (OT) / industrial control system (ICS) equipment manufacturer.
// @description: Scans discovered endpoints (hosts) across all devices and flags any whose MAC address's OUI-registered organization name (from the IEEE OUI database, http://standards-oui.ieee.org/oui/oui.csv) exactly matches a known OT/ICS/SCADA vendor entity. The vendor list was compiled by searching the supplied IEEE OUI CSV export for organization names containing well-known OT manufacturer names (Siemens, Rockwell, Schneider Electric, ABB, Honeywell, Mitsubishi Electric, Emerson, Yokogawa, Omron, Phoenix Contact, Moxa, WAGO, Beckhoff, and others), then removing confirmed false-positive substring collisions. Used by security and OT/IT convergence teams to locate industrial equipment (PLCs, HMIs, RTUs, industrial switches, sensors) present on the IT network.
// @output:
// Device: The network device on which this endpoint was observed.
// Location: The location assigned to the device, if any.
// Host Name: The discovered name of the endpoint, if known.
// MAC Address: The endpoint's MAC address.
// OUI Assignee: The IEEE-registered organization name resolved from the MAC address's OUI.
// IP Addresses: The IP address(es) associated with this endpoint.
// VLANs: The VLAN(s) on which this endpoint's traffic was observed.
// Interfaces: The interface(s) on the device where this endpoint was seen.
// Host Type: The classification of the endpoint (e.g. inferred host, edge node).
targetVendors = [
"ABB AB, Cewe-Control ",
"ABB AG",
"ABB AS, Division Automation Products",
"ABB Australia",
"ABB Automation products GmbH",
"ABB Bomem, Inc.",
"ABB Genway Xiamen Electrical Equipment CO., LTD",
"ABB Global Industries and Services Private Limited",
"ABB INDUSTRIAL SYSTEMS AB",
"ABB Inc/Totalflow",
"ABB Ltd",
"ABB Oy",
"ABB Oy / Medium Voltage Products",
"ABB Oy Drives",
"ABB POWER T&D COMPANY, INC.",
"ABB Power Systems Power Generation",
"ABB Robotics",
"ABB SPA, ABB SACE DIV.",
"ABB SpA - DIN Rail",
"ABB Switzerland Ltd",
"ABB Switzerland Ltd.",
"ABB Xiamen Low Voltage Equipment Co.,Ltd.",
"ABB n.v. Power Quality Products",
"ADVANTECH CO., LTD.",
"ADVANTECH TECHNOLOGIES CO.,LTD",
"APC by Schneider Electric",
"Advantech AMT Inc.",
"Advantech Czech",
"Advantech Technology (CHINA) Co., Ltd.",
"Balluff GmbH",
"Balluff MV GmbH",
"Banner Engineering",
"Beckhoff Automation GmbH",
"Belden",
"Belden Deutschland GmbH",
"Belden Hirschmann industries (Suzhou) Limited",
"Belden India Private Limited",
"Belden Mooresville",
"Belden Singapore Pte. Ltd.",
"CONTEC CO., LTD.",
"Contec GmbH",
"Delta Electronics",
"Delta Electronics, Inc.",
"Eaton Automation AG",
"Eaton Corp. Electrical Group Data Center Solutions - Pulizzi",
"Eaton Corporation",
"Eaton Industries GmbH",
"Emerson",
"Emerson Appliance Motors and Controls",
"Emerson Climate Technologies GmbH",
"Emerson Energy Systems AB",
"Emerson Network Power Co.,Ltd",
"Emerson Network Power, Avocent Division",
"Emerson Process Management Power & Water Solutions, Inc.",
"Endress & Hauser GmbH & Co",
"FUJI ELECTRIC CO., LTD.",
"Festo AG & Co. KG",
"GENERAL ELECTRIC CORPORATION",
"General Electric Consumer and Industrial",
"General Electric Digital Energy",
"General Electric Global Research",
"General Electric Water & Process Technologies",
"Grass Valley, A Belden Brand",
"HIRSCHMANN AUSTRIA GMBH",
"HMS Industrial Networks",
"HMS Industrial Networks ",
"HMS Industrial Networks SLU",
"HONEYWELL-DATING",
"Hilscher GmbH",
"Hirschmann Automation",
"Hirschmann Automation and Control GmbH",
"Hirschmann Multimedia B.V.",
"Honeywell",
"Honeywell (China) Co., LTD",
"Honeywell Analytics",
"Honeywell CMSS",
"Honeywell Co., Ltd. (KOREA)",
"Honeywell Connected Building",
"Honeywell Environmental & Combustion Controls",
"Honeywell Environmental & Combustion Controls (Tianjin) Co., Ltd.",
"Honeywell Fire System (Shanghai) Co,. Ltd.",
"Honeywell GmbH",
"Honeywell International Inc",
"Honeywell Life Safety",
"Honeywell SPS",
"Honeywell Safety Products (Shanghai) Co.,Ltd",
"Honeywell Security (China) Co., Ltd.",
"Honeywell Video Systems",
"IFM Electronic gmbh",
"MITSUBISHI ELECTRIC AUTOMATION (CHINA) LTD.",
"MITSUBISHI ELECTRIC SYSTEM & SERVICE CO.,LTD.",
"MOXA TECHNOLOGIES CORP., LTD.",
"Mitsubishi Electric Corporation",
"Moxa.Inc",
"NATIONAL INSTRUMENTS CORP.",
"OMRON Corporation",
"OMRON HEALTHCARE Co., Ltd.",
"OMRON TATEISI ELECTRONICS CO.",
"Omron Healthcare Co., Ltd",
"Pepperl+Fuchs GmbH",
"Phoenix Broadband Technologies, LLC.",
"Phoenix Contact GmbH & Co. KG",
"Prosoft Systems LTD",
"Prosoft Technology, Inc",
"Red Lion Controls Inc.",
"Red Lion Controls, LP",
"Rockwell Automation",
"SECURITE COMMUNICATIONS / HONEYWELL",
"SHIMAFUJI ELECTRIC CO.,LTD.",
"SICK AG",
"SIEMENS AG",
"SIEMENS AG, Digital Factory, Motion Control System",
"SIEMENS BUILDING",
"SIEMENS ENERGY AUTOMATION",
"SIEMENS TELECOMMUNICATION SYSTEMS LIMITED",
"Schneider Electric",
"Schneider Electric (Australia) ",
"Schneider Electric Asia Pacific Ltd",
"Schneider Electric Canada Inc",
"Schneider Electric Fire & Security Oy",
"Schneider Electric Japan Holdings Ltd.",
"Schneider Electric USA",
"Schneider Electric Ultra Terminal",
"Shanghai HITE-BELDEN Network Technology Co., Ltd.",
"Siemens AG",
"Siemens AG Austria",
"Siemens AG Energy Management Division",
"Siemens AG I IA PP PRM",
"Siemens AG ICM MP UC RD IT KLF1",
"Siemens AG,",
"Siemens AG, Automations & Drives,",
"Siemens AG, Healthcare Sector",
"Siemens AG, Sector Industry, Drive Technologies, Motion Control Systems",
"Siemens AG, Transportation Systems",
"Siemens Building Technologies AG,",
"Siemens Canada",
"Siemens Canada Limited",
"Siemens Convergence Creators GmbH&Co.KG",
"Siemens Energy Global GmbH & Co.KG - GT PRM",
"Siemens Healthcare Diagnostics Manufacturing Ltd",
"Siemens Healthcare Diagnostics, Inc",
"Siemens Home & Office Comm. Devices",
"Siemens Industrial Automation Products Ltd., Chengdu",
"Siemens Industry, Inc.",
"Siemens Low Voltage & Products",
"Siemens Ltd.",
"Siemens Mobility Limited",
"Siemens NV (Belgium)",
"Siemens Network Convergence LLC",
"Siemens Numerical Control Ltd., Nanjing",
"Siemens Rail Automation SAU",
"Siemens Switzerland Ltd., I B T HVP",
"TURCK, Inc.",
"WAGO Kontakttechnik GmbH",
"Weidmüller Interface GmbH & Co. KG",
"Westermo Neratec AG",
"Westermo Network Technologies AB",
"Woodward Governor",
"YAMATAKE-HONEYWELL CO., LTD.",
"Yokogawa Digital Computer Corporation",
"ifm electronic gmbh"
];
@primaryKey(Device, "MAC Address")
foreach device in network.devices
foreach host in device.hosts
where isPresent(host.macAddress)
let assignee = ouiAssignee(host.macAddress)
where isPresent(assignee) && assignee in targetVendors
select {
violation: true,
Device: device.name,
Location: device.locationName,
"Host Name": host.name,
"MAC Address": host.macAddress,
"OUI Assignee": assignee,
"IP Addresses": host.addresses,
VLANs: host.vlans,
Interfaces: host.interfaces,
"Host Type": host.hostType
}
order by Device asc natural
Validating That Isolation Points Actually Work
An isolation point is only as good as its ability to block every path, including ones nobody remembers configuring. Forward's path analysis can compute, with certainty, whether any path exists between a given device — including OT equipment surfaced by the query above — and a designated non-critical network, before an isolation plan is ever executed. Organizations can model each stage of a graduated isolation plan (disconnect remote workers, then vendors, then corporate network) in the digital twin and confirm each step achieves the intended separation, without touching production.
Testing Isolation Plans Without the Risk of Testing in Production
CI Fortify recommends testing complete isolation regularly, but physically disconnecting production network links to test a plan carries real operational risk. Forward's digital twin lets teams simulate the removal of specific links, routes, or rules and see the resulting reachability — surfacing shared infrastructure and hidden dependencies the guidance warns about, without an actual outage.
Monitoring for Drift and Unauthorized Reconnection
After isolation, CI Fortify calls for monitoring routing tables, traffic, and IDS to confirm isolation holds — and, later, for confirming that reconnection to the outside world doesn't quietly restore an unwanted path. Forward's continuous collection and snapshot comparison let teams diff network state before and after an isolation event, flagging any new or restored path between vital-system devices and non-critical networks — as well as any newly discovered OT/ICS equipment that shows up where it shouldn't.
What You Should Do Right Now
- Inventory vital systems — Start from Forward's OT/ICS MAC-vendor discovery to surface candidate industrial equipment already on the network, then confirm and tag the systems that are actually vital.
- Map connections automatically — Use Forward Enterprise to generate a complete, current picture of every path between vital-system devices and corporate, cloud, vendor, and internet-facing networks.
- Define and validate isolation points — Confirm in the digital twin that each planned isolation point actually severs all paths, not just the obvious ones.
- Test full isolation, safely — Simulate each stage of a graduated isolation plan before committing to it operationally.
- Monitor continuously — Set up snapshot comparisons to catch new connections, newly discovered OT equipment, or configuration drift that could quietly undermine an isolation plan.
Final Thoughts
CI Fortify is a shift from reactive incident response to pre-planned resilience: know your vital systems, know every connection they have, and know exactly how to sever those connections before you're forced to do it under pressure. That plan is only as reliable as the device and path inventory it's built on — and that inventory has to include the OT equipment nobody remembered to document. Continuous, accurate visibility into which devices matter and how they connect isn't a nice-to-have for CI Fortify — it's the prerequisite for every step the guidance describes.
