This is a companion post to CISA Adds CVE-2025-53521 to KEV: What It Means for F5 BIG-IP APM Systems
If you manage Rockwell Automation/Allen-Bradley programmable logic controllers anywhere in your environment — or if you're responsible for any network that touches operational technology — this advisory is one of the most serious things to land in 2026.
On April 7, 2026, six U.S. government agencies issued a joint advisory: the FBI, CISA, NSA, EPA, Department of Energy, and U.S. Cyber Command. When that many agencies co-sign a warning, it reflects both the severity of the activity and the breadth of the threat. The advisory (AA26-097A) confirms that Iranian-affiliated advanced persistent threat (APT) actors are actively exploiting internet-facing Rockwell Automation/Allen-Bradley PLCs across multiple U.S. critical infrastructure sectors, resulting in operational disruptions and financial loss.
What's Happening
Since at least March 2026, an Iranian-affiliated APT group has been targeting internet-exposed PLCs — not to exfiltrate data, but to cause disruption. The playbook is notably physical in its intent: actors are manipulating project files on the PLC itself and falsifying the data displayed on Human Machine Interface (HMI) and SCADA screens. The result is operators seeing conditions that don't reflect reality, or losing the ability to control physical processes altogether.
The attackers are also deploying Dropbear SSH on compromised endpoints to maintain persistent remote access via port 22, giving them a durable foothold in OT environments long after initial compromise.
What makes this advisory particularly uncomfortable is the vulnerability at its center: CVE-2021-22681. This is not a new disclosure. Rockwell published guidance on this authentication bypass in 2021 — five years ago. It carries a CVSS v3.1 score of 9.8 (Critical), and for good reason.
The Vulnerability: CVE-2021-22681
The flaw lives in how Rockwell Automation Logix products protect the cryptographic key used to authenticate communication between Studio 5000 Logix Designer (the engineering software) and the Logix PLC itself. The key is insufficiently protected, meaning a remote, unauthenticated attacker who discovers or intercepts it can impersonate legitimate engineering software — bypassing all authentication and establishing a direct authenticated session with the controller.
No credentials. No user interaction. Low attack complexity. Full controller access.
The affected hardware spans a wide range of the Logix family:
| Product Family | Affected Models |
|---|---|
| CompactLogix | 1768, 1769, 5370, 5380, 5480 series |
| ControlLogix | 5550, 5560, 5570, 5580 series |
| Other Logix | DriveLogix, GuardLogix, SoftLogix 5800 |
| Software | RSLogix 5000 (v16–v20), Studio 5000 Logix Designer (v21.0+) |
The existence of this CVE since 2021 raises a hard question: if this vulnerability has been known for five years, why are Iranian APT actors still finding internet-exposed PLCs to exploit it against? The answer isn't that organizations are negligent — it's that OT environments are notoriously difficult to inventory and segment, and the IT/OT network boundary is rarely as clean as it looks on paper.
Who Is Targeted
The advisory specifically calls out three critical infrastructure sectors:
- Government Services and Facilities (including local municipalities)
- Water and Wastewater Systems (WWS)
- Energy
But the authoring agencies are clear that this threat extends beyond federal agencies. Any organization running internet-exposed Rockwell Automation Logix PLCs should treat this as directly relevant. The word "internet-exposed" is doing a lot of work here — and the challenge is that many organizations genuinely don't know which of their OT devices are reachable from the internet, because that question requires network-level analysis, not just an asset scan.
What the Advisory Requires
The six authoring agencies make the following core recommendations:
Immediate actions: Disconnect Rockwell PLCs from the public internet entirely. Rockwell's own guidance document (SD1771) reiterates this clearly — these devices were not designed to be internet-exposed, and any internet-facing deployment is an unacceptable risk posture given this active exploitation.
Patch and harden: Apply available mitigations per Rockwell's PN1550 guidance for CVE-2021-22681. Where patching is not immediately possible, implement compensating controls — firewall rules, ACLs, and strict network segmentation to prevent any internet-accessible path to PLC management interfaces.
Hunt for compromise: Review IOCs provided in the advisory (available in STIX format, both XML and JSON) against your environment. Look specifically for unexpected Dropbear SSH activity on OT endpoints and anomalous connections on port 22.
Validate HMI and SCADA integrity: If you operate in a targeted sector, verify that what your operators are seeing on HMI displays reflects actual physical state — and review audit logs for any unauthorized project file access or modification.
How Forward Enterprise Can Help
OT security incidents like this one tend to expose a fundamental gap: organizations know they have PLCs somewhere on the network, but they can't quickly answer the questions that matter most operationally — which of them are internet-reachable, what paths exist into the OT environment from untrusted segments, and where does the IT/OT boundary actually sit in practice versus in the documentation?
Forward Enterprise is built to answer exactly those questions. Here's where it helps:
1. Find Rockwell Devices Across Your Network Estate Using OUI Lookup
The first challenge is knowing where Rockwell hardware actually lives on your network. Rather than relying on device hostnames, CMDB records, or manual documentation — all of which tend to be stale in OT environments — Forward Enterprise can identify Rockwell-based hosts directly from MAC address data using the IEEE OUI (Organizationally Unique Identifier) registry.
The NQE query below cross-references every host in your network model against the IEEE OUI registry, filtering for MAC addresses assigned to Rockwell Automation. For each match, it returns the device it's seen on, its network addresses, VLANs, gateway interfaces, and host type — everything you need to understand where that hardware sits in the network.
/**
* @intent List Network Devices and/or Hosts containing hardware from specific OUI vendors registered with IEEE.
* @description Check everything in the model for OUI's corresponding to specific registered vendor names,
* according to the IEEE Registry at http://standards-oui.ieee.org/oui/oui.csv.
*/
// modify this list of comma-separated IEEE-registered OUI Vendor Names as desired
OUINames = ["Rockwell Automation"];
foreach device in network.devices
foreach host in device.hosts
where isPresent(host.macAddress)
where ouiAssignee(host.macAddress) in OUINames
select {
deviceName: device.name,
locationName: device.locationName,
addresses: host.addresses,
macAddress: host.macAddress,
vendor: ouiAssignee(host.macAddress),
interfaces: host.interfaces,
hostType: host.hostType,
vlans: (foreach vlan in host.vlans select vlan.from),
gatewayDevice: (foreach int in host.gatewayInterfaces select int.deviceName),
gatewayInterfaces: (foreach int in host.gatewayInterfaces select int.ifaceName)
}One honest caveat worth naming: not every result from this query will be a PLC. Rockwell manufactures a range of hardware — HMIs, drives, communication modules, and other industrial components all share Rockwell OUIs. What the query guarantees is that every result is Rockwell-based hardware, which is exactly the right starting population for this investigation. From there, the hostType and interface data help you triage which hosts warrant closer scrutiny.
2. Run a Blast Radius Analysis from the Internet to Those Subnets
Once you have the addresses and subnets where Rockwell hardware lives, the next question is the one this advisory is fundamentally about: can internet-sourced traffic actually reach them?
Forward Enterprise's reachability analysis lets you run a blast radius search — starting from an internet source and tracing every network path that could reach the subnets identified in the NQE query above. This is mathematically verified against your actual device configurations and routing state, not inferred from a network diagram or a firewall policy that may not be enforced the way it's intended. If a path exists between the internet and your Rockwell subnets, Forward finds it and shows you the exact hops, interfaces, and policy decisions that allow it.
This two-step workflow — inventory first, then reachability — is the most direct way to answer the question CISA is asking organizations to answer: do you have internet-exposed Rockwell controllers, and if so, where? The NQE query surfaces the targets; the blast radius search reveals the exposure.
3. Verify Network Segmentation Is Actually Enforced
IT/OT segmentation is frequently assumed but rarely validated at the control-plane level. Forward Enterprise lets you run continuous compliance checks that verify segmentation policies are actually enforced across your environment — not just declared in a network diagram. You can confirm that ACLs and firewall rules blocking traffic from the internet to OT segments are present, correctly configured, and not inadvertently bypassed through a routing exception or misconfigured policy.
4. Use NQE to Hunt for Exposure and Policy Violations
For teams that want to go deeper, Forward's Network Query Engine can be used to identify policy violations relevant to this advisory — including devices with unexpected open paths to port 22, EtherNet/IP endpoints reachable from untrusted segments, or Rockwell devices whose management interfaces are exposed where they shouldn't be. This kind of query-driven posture check can be run on-demand and saved as a continuous check that fires whenever the network state changes.
5. Track Remediation and Validate Closure
Once you've identified internet-exposed PLCs and moved to disconnect or protect them, Forward Enterprise gives you verifiable evidence that the remediation actually took effect. Because the digital twin reflects live network state, you can confirm that the path that existed before no longer exists — and set up a persistent check to alert you if it ever reappears.
My Take
What I find striking about AA26-097A is that the core mitigation — disconnect your PLCs from the internet — has been Rockwell's own recommendation since at least 2021 when CVE-2021-22681 was first disclosed. This isn't a zero-day situation where organizations were caught flat-footed by new research. This is a five-year-old critical vulnerability, with published guidance to remove internet exposure, being actively weaponized by a nation-state actor against water systems, energy infrastructure, and local governments.
That gap — between knowing a device shouldn't be internet-exposed and actually being able to prove it isn't — is one of the hardest problems in OT security. It requires network-level visibility that most organizations simply don't have in their OT environments. The network diagram says one thing; the routing table says another; and somewhere in between is the path an APT actor is using right now.
If you're working through your response to AA26-097A and want to discuss how Forward Enterprise can help you identify internet-exposed OT devices, validate segmentation, or model reachability into your ICS environment, feel free to reply here or reach out directly.
