CISA Warns of Attacks on PLCs Across U.S. Critical Infrastructure
If your PLCs are reachable from the internet, they may already be compromised.
Last week CISA, the FBI, the NSA, and other federal agencies jointly issued an urgent cybersecurity advisory: “Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure“. The advisory describes an active campaign targeting internet-facing PLCs — primarily Rockwell Automation/Allen-Bradley devices — across water, energy, and government facilities.
The attacks are not theoretical. Threat actors used overseas IP addresses and standard configuration software to connect directly to exposed PLCs, extract project files, and manipulate HMI and SCADA displays. “In a few cases, this activity has resulted in operational disruption and financial loss,” the CISA advisory states. The actors’ intent, according to the authoring agencies, was “to cause disruptions” to U.S. critical infrastructure.
The attack vector is remarkably simple: the PLCs were internet-accessible. No zero-day exploit was needed.
Executives and Plant Leadership – What Should Concern You
This is not a software bug that can be patched. It is an architectural failure in how OT is connected to the outside world. The business implications go beyond operational disruption:
- Financial loss from unplanned downtime and incident response
- Reputational damage when customers and regulators learn that basic network segmentation was absent
- Regulatory exposure under NIS2, NIST CSF 2.0, and sector-specific CISA directives
- Theft of proprietary engineering designs and production logic
CISA’s first recommendation is blunt: “Disconnect the PLC from the public-facing internet,” and “remove inbound port exposure” so OT systems are “never directly exposed to the internet or external networks.”
The instinct to hand this to IT is understandable, but traditional IT approaches — VPNs, remote desktop, perimeter firewalls with inbound rules — are precisely the patterns that created this exposure. This is an OT network architecture issue. The right conversation with your engineering teams starts with: Which of our OT devices are accessible from external networks? Do any firewall rules allow inbound connections to the plant? If we closed every inbound path today, what data access would we lose?
The goal is not to stop data from flowing. It is to ensure nothing can flow in.
A Structural Solution
The architecture that prevents this class of attack uses outbound-only connections from the OT network, carrying data across a DMZ to IT or cloud systems without opening any inbound ports. DataHub tunnel/mirror technology from Skkynet does exactly this — and has for over two decades. The attack described in this advisory is architecturally impossible when no inbound path to the OT network exists.
This advisory also validates two other core DataHub design principles: a fractal namespace architecture that isolates each operational level so a compromise cannot cascade across the enterprise, and DMZ-compatible network segmentation that maintains guaranteed data consistency across multiple network hops — something standard MQTT and OPC UA cannot provide.
Control Engineers and Integration Teams – What Should Concern You
The CISA advisory (AA26-097A) describes Iranian-affiliated APT actors accessing internet-exposed CompactLogix and Micro850 PLCs using Studio 5000 Logix Designer. They connected on ports 44818, 2222, 102, and 502 — standard OT ports. They extracted .ACD project files, manipulated SCADA displays, and deployed Dropbear SSH for persistent access. The targeting of Siemens S7 ports indicates this is not limited to Rockwell devices.
Short-Term Mitigations
- Disconnect PLCs from the public internet; place them behind gateways and firewalls
- Set physical mode switches to run position to prevent remote logic modification
- Create and test offline backups of PLC logic and configuration
- Implement MFA for any remote OT access from external networks
- Monitor OT ports for connections from unexpected IP ranges and check logs against the published IOCs
These are necessary but tactical. They reduce immediate exposure without solving the architectural problem.
Long-Term Solutions
The long-term answer is an architecture where inbound access to the plant is structurally impossible:
- Outbound-only tunnel/mirror connections that initiate from inside the OT network, with all firewall ports closed inbound and SSL encryption throughout. Even a compromised receiving side cannot reach back into the plant.
- DMZ-based network segmentation with guaranteed data consistency at every hop. Unlike MQTT, whose QoS guarantees do not propagate past a single broker, DataHub tunnel/mirroring flags stale or disconnected data immediately at every node in the chain.
- A fractal UNS that isolates each operational level — machine, line, site, enterprise — so lateral movement from a compromised node is constrained by architecture, not just policy.
This advisory validates what DataHub’s architecture was built to prevent. The attack succeeded because OT devices were directly accessible with no segmentation, no mediation, and no architectural barriers. An outbound-only, DMZ-compatible architecture eliminates that entire attack surface — and keeps production data flowing where it needs to go.
