Jherrod ThomasThe Lion of Functional Safety™

May 10, 2026 · 16 min read

IEC 62443IEC 61511NIST SP 800-82

When the Manual Was the Exploit

The April 7, 2026 joint advisory from CISA, the FBI, NSA, EPA, DOE, and U.S. Cyber Command's CNMF — AA26-097A — reads like an indictment of an industry, not of an attacker. The Iranian-affiliated actors known as CyberAv3ngers didn't burn a zero-day. They read the Rockwell manual, scanned Shodan, and walked in through ports that nobody had any business leaving open in 2026. Every claim in this post is sourced; every mitigation maps to a clause that already exists in IEC 62443 and IEC 61511.

I write a lot about automotive and aerospace, but the cleanest functional-safety / cybersecurity convergence story of the last 30 days is in the process industry: a confirmed disruption of Rockwell Automation CompactLogix and Micro850 PLCs at U.S. water, wastewater, energy, and government-facility sites. Treated as a SOTIF / random-fault story, it makes no sense. Treated as a missing IEC 62443-3-2 zone-and-conduit boundary, a missing IEC 62443-3-3 SR-1.1 / SR-1.2 control, and an IEC 61511 §11 independence violation between the BPCS and the SIS, it makes complete sense — and it is solvable.

This post does what the rest of the blog does: re-frames the headline as a missing artifact. Same shape as my other write-ups — public record, standards lens, worked snippet, derived requirements.

1. The public record

On April 7, 2026, CISA published advisory AA26-097A — co-signed by the FBI, NSA, EPA, DOE, and CNMF — confirming that since at least March 2026, an Iranian Islamic Revolutionary Guard Corps Cyber Electronic Command (IRGC-CEC)–affiliated group operating as CyberAv3ngers (also tracked as Shahid Kaveh Group, Hydro Kitten, Storm-0784, UNC5691) has been actively exploiting internet-exposed Rockwell Automation CompactLogix and Micro850 PLCs across U.S. critical infrastructure (CISA AA26-097A).

The targeted sectors are:

The intrusion technique is, by the advisory's own description, unsophisticated. The actors:

  1. Scanned the public internet for Rockwell PLCs reachable on EtherNet/IP TCP/UDP 44818, TCP 2222, S7 TCP 102, Modbus TCP 502, and management-plane SSH on 22 — the same default ports listed in the Rockwell installation guide.
  2. Connected from overseas IPs and leased third-party hosting, using legitimate Rockwell Studio 5000 Logix Designer to push project files.
  3. Where authentication was required, they leveraged default credentials or the long-disclosed CVE-2021-22681 (CVSS v3 10.0) — a Studio 5000 / RSLogix 5000 issue in which the verification key used to authenticate engineering-station traffic is recoverable, enabling an unauthenticated third party to push code to the controller. Rockwell publicly states the underlying issue cannot be patched and must be mitigated by CIP Security with a 1756-EN4TR module and physical run-mode switch position (CISA ICSA-21-056-03).
  4. Once on the controller, they altered project files and HMI/SCADA display values — the same playbook CyberAv3ngers ran against Israeli-built Unitronics Vision PLCs in November 2023, where they compromised at least 75 devices including 34 in the U.S. WWS sector and left a defacement message on operator HMIs (CISA AA23-335A).

Nozomi Networks put the technical posture bluntly: "these Iranian-affiliated attackers didn't need a zero-day; they just used the manual" (Nozomi blog, April 2026). Censys reported that thousands of Rockwell PLCs remain reachable from the public internet at U.S. address space, with device type and firmware version exposed in the banner — a multi-year regression problem, not a new one (Industrial Cyber, April 2026).

The financial-impact line in the advisory is the line that should make every utility C-suite read this twice: "organizations… experienced disruptions through malicious interactions with project files and manipulation of data displayed on human machine interface and SCADA displays, resulting in operational disruption and financial loss." That is not a theoretical risk. That is a closed-loop confirmation that the BPCS authority was held, briefly, by an adversary.

2. The standards lens

This is not a functional-safety failure in the classical IEC 61508 random-hardware-fault sense. It is a cybersecurity-induced functional-safety failure — the path covered explicitly by IEC 62443 (industrial automation and control systems security) and, crucially, by the IEC 61511 process-safety amendment for security risk assessment of safety instrumented systems. Three layers should have caught this. None did.

Layer A — IEC 62443-3-2: zones and conduits

IEC 62443-3-2 requires the asset owner to perform a cybersecurity risk assessment, partition the system into zones (groups of assets that share the same Security Level Target, SL-T) and conduits (the communication paths between them), and explicitly document the trust boundary at each conduit (Wiseplant, Understanding Zones and Conduits; MDPI, Security Aspects of Zones and Conduits in IEC 62443). For a water utility, the canonical zoning is:

The conduit from Zone 1 to anywhere outside Zone 2 is supposed to be inspected, authenticated, and rate-limited. A CompactLogix that is reachable on EtherNet/IP 44818 from the public internet is, by definition, a zone with no upstream conduit — the boundary doesn't exist. There is no SL-T to evaluate because the assessment was either never performed or was performed and ignored.

Layer B — IEC 62443-3-3: system requirements

IEC 62443-3-3 defines seven foundational requirements; the two that this advisory pins on every affected utility are:

The Iranian actors didn't bypass IAC and RDF — they walked past their absence.

Layer C — IEC 61511 §8 and §11: BPCS / SIS independence and security risk assessment

The 2016 edition of IEC 61511-1 added §8.2.4, which requires a security risk assessment for the SIS as part of the H&RA process, and §11.2.10, which mandates that the SIS shall be designed to be sufficiently independent from the BPCS that a failure (or compromise) of the BPCS cannot disable or defeat the SIS function. For a water utility with chlorination dosing or a wastewater plant with hypochlorite or caustic feed, this independence claim is what separates "operator notices and intervenes" from "public health event."

If your BPCS PLC is reachable from the internet and your SIS shares the same physical Ethernet trunk, or worse, the same controller and the same project file, the §11.2.10 independence claim is a paper claim — and a paper claim is not a barrier in a process-safety LOPA.

The technical takeaway in one sentence: AA26-097A is what happens when an organization treats IEC 62443 as IT's problem, IEC 61511 §8.2.4 as the SIS vendor's problem, and the line between them as nobody's problem.

3. A worked snippet — IEC 62443-3-2 risk row + fault tree

Below is the kind of row that should have lived in the zone risk register for a representative small WWS utility (~25 ksvc population, single chlorination plant, one CompactLogix BPCS, one Allen-Bradley GuardLogix SIS).

Threat-risk row

| ID | Zone | Threat scenario | Vector | Likelihood | Worst-case consequence | Inherent risk | SL-T | SL-A | Gap | Treatment | |---|---|---|---|---|---|---|---|---|---|---| | TR-Z1-01 | Zone 1 (BPCS) | Unauthorized project upload to CompactLogix via internet-reachable EtherNet/IP TCP 44818 | External actor, no credentials, Studio 5000 + CVE-2021-22681 | High | Setpoint manipulation of chlorine dosing or pump cascade; HMI value spoofing masking the change | Catastrophic — public-health event | SL 3 | SL 0 (no conduit, default keys) | 3 levels | Remove internet exposure; deploy 1756-EN4TR + CIP Security; controller key-switch in RUN; SIEM forward CIP Class 3 ops | | TR-Z1-02 | Zone 1 (BPCS) | Lateral movement from engineering workstation in Zone 2 to BPCS PLC after phishing compromise | Phished engineer, compromised Studio 5000 host | Medium | Same as TR-Z1-01 | High | SL 2 | SL 1 (shared VLAN, no MFA on workstation) | 1 level | MFA + jump-host for any engineering session into Zone 1; CIP message-integrity required at conduit | | TR-Z2-01 | Zone 2 (SCADA) | Operator HMI display manipulated to mask BPCS state during attack on TR-Z1-01 | Tag-value injection in HMI server | High | Delayed operator response; loss of MTTR margin before SIS demand | High | SL 2 | SL 1 | 1 level | Independent secondary indication of chlorine residual on a hardwired loop terminating in the SIS, not the BPCS HMI | | TR-SIS-01 | SIS | Loss of §11.2.10 BPCS/SIS independence — same Ethernet trunk, same engineering account | Architectural | Medium | SIS demand coincident with BPCS compromise → SIS may not respond | Catastrophic | SL 3 | SL 1 | 2 levels | Physically separated SIS network; separate Studio 5000 / FactoryTalk credentials; dedicated SIS engineering workstation in its own zone |

That last row is the one that lets a process-safety engineer connect AA26-097A to an IEC 61511 LOPA. If the BPCS can be commandeered and the SIS shares the same trust boundary, the LOPA "independent protection layer" credit you were taking for the SIS is gone — the layer is no longer independent of the threat that creates the demand.

Fault tree (top event: hazardous chlorine over/under-dose at a treated-water outlet)

Top: Hazardous chlorine concentration delivered to distribution
        OR
        ├── A. BPCS setpoint manipulated by external actor
        │       AND
        │       ├── A1. PLC reachable from untrusted network
        │       │       OR
        │       │       ├── A1a. CompactLogix EtherNet/IP TCP 44818 exposed to internet
        │       │       ├── A1b. Cellular modem with public IP and no IP allowlist
        │       │       └── A1c. Plant DMZ → Zone 1 conduit allows engineering protocol unrestricted
        │       └── A2. PLC accepts unauthenticated or weakly authenticated program write
        │               OR
        │               ├── A2a. Default Studio 5000 / FactoryTalk Security keys in use
        │               ├── A2b. CVE-2021-22681 mitigation (CIP Security + 1756-EN4TR) not deployed
        │               └── A2c. Controller key-switch in REMOTE (not RUN) during normal operation
        ├── B. SIS does not respond to demand
        │       AND
        │       ├── B1. SIS shares trust boundary with compromised BPCS (IEC 61511 §11.2.10 gap)
        │       └── B2. Independent SIS engineering credentials reuse same compromised account
        └── C. Operator does not detect and intervene in time
                OR
                ├── C1. HMI tag values manipulated to hide BPCS state
                ├── C2. No independent indication of chlorine residual outside BPCS HMI
                └── C3. Alarm philosophy depends on BPCS for SIS-side alarms (anti-pattern)

Two structural notes for anyone planning to copy this tree into a real LOPA:

  1. A1 / A2 are AND-gated. Internet exposure alone does not place hands on the controller; weak auth alone does not either. The two together are the box on the threat-risk row.
  2. B1 / B2 are AND-gated under the SIS branch. If you can honestly claim §11.2.10 independence — separate trunk, separate accounts, separate engineering workstation, separate change-management — that whole subtree collapses and the SIS continues to be a credible IPL even if Zone 1 falls.

4. Derived requirements (excerpt)

These are the rows I would expect to see in a remediation plan after a tabletop on AA26-097A. They are written in the same style as the cybersecurity goals I've used in my TARA-style work — stable IDs, numeric thresholds, traceable to an IEC 62443 / IEC 61511 clause.

I am deliberately not writing a requirement that says "patch CVE-2021-22681." You cannot patch CVE-2021-22681 — Rockwell has been explicit about that since the 2021 disclosure. The requirement is defeat-in-depth: assume the credential primitive is weak, and design the zone, conduit, and SIS architecture so that defeating it doesn't reach the safety function.

5. What the headline really tells us

If you read AA26-097A as an attacker story, it reads as a sophisticated nation-state operation. If you read it as a defender story, it reads as eight years of unbuilt artifacts — the zone-and-conduit drawing nobody finished, the SL-T table nobody assigned, the CIP Security rollout nobody scheduled, the §11.2.10 independence claim nobody re-validated when the BPCS got a cellular modem two years ago for "remote support."

The attackers didn't bring a new capability. They brought time, free Shodan queries, and a publicly available copy of the Rockwell installation manual. The defenders' missing artifact is not a new control — it is the discipline to fill out the table that IEC 62443-3-2 already tells them to fill out.

Two more uncomfortable things this advisory should make every WWS and energy operator say out loud:

  1. An IEC 61511 §11.2.10 SIS-from-BPCS independence claim that hasn't been re-walked since the last network change is no longer a claim — it is a hope. Cellular modems, vendor remote-support tunnels, and "temporary" engineering workstation bridges all puncture this claim silently. The next time you sit in a LOPA review, ask whether the SIS independence claim has been re-verified against the current network drawing, not the one from commissioning.
  2. The CVSS 10.0 vulnerability is not the lesson. The lesson is that the compensating control (CIP Security + EN4TR + mode-switch + IP allowlist) was published in 2021 and is still not deployed on tens of thousands of internet-reachable controllers in 2026. The exploitability of the manual outpaces the deployment of the mitigation by half a decade.

If you operate a treatment plant, a substation, a pump station, or a refinery and you don't already have the equivalent of the threat-risk table above in your live OT risk register — that gap is the actionable thing. Not the headline.

If you want help structuring this — zone partitioning, SL-T assignment, IEC 61511 §8.2.4 security risk assessment, or a LOPA refresh that doesn't quietly assume a §11.2.10 claim you can't defend — the contact link on the main site is the fastest way to reach me.

— Jherrod Thomas, The Lion of Functional Safety™

Sources