The unpatchable flaw hitting water utilities.

A fix that assumes a security team you don’t have

CISA advisory AA26-097A (a joint FBI / CISA / NSA / EPA / DOE / U.S. Cyber Command / Treasury advisory) tracks an ongoing campaign against water-sector control systems. One vulnerability in that picture — CVE-2021-22681 — affects a large install base of Rockwell Logix controllers, and because the flaw is a hardcoded verification key rather than a software bug, it is not something a patch can close.

The remediation Rockwell points to — CIP Security — is real and correct. But its deployment guidance assumes a full enterprise environment: Active Directory, FactoryTalk, a dedicated security team. Most small municipal water and wastewater systems have none of those. A few staff, a contracted operator, a tight budget.

This work reproduces the fix principle with open tooling, maps it honestly to the relevant standard, and turns it into a phased plan a small utility can actually follow.

Three different failures — three different fixes

A disclosure that blurs these together helps no one. The proof of concept keeps them separate on purpose:

• No / absent authentication — a device exposed with no credential layer at all. The broad baseline the campaign leaned on.
• One hardcoded / shared key across a fleet — extract the one key once, forge fleet-wide. This is the specific shape of CVE-2021-22681.
• Default credentials — factory credentials never changed. Named here so it isn’t conflated with the two above.

The demonstrated fix — per-device identity binding — addresses the fleet-key failure.

Six runnable tests — open tooling, zero Rockwell software

The proof of concept uses only cpppo (an open EtherNet/IP implementation) and Python’s cryptography library. Each test could fail and is shown to do (or not do) exactly what is claimed — the standard for calling anything “demonstrated.”

IEC 62443-4-2 (SL 2) — every gap named

The evidence is mapped to the relevant component requirements of the standard, tiered honestly. “Demonstrated” means a test could have failed and didn’t; where the PoC only partially addresses a requirement, it says so. This is a mapping of what the PoC shows — not a product conformance claim, which is the vendor’s and an accredited lab’s call.

CR 1.14 appears as the requirement the flaw violates — claimed as met by nothing. The two items this page named as open on Jul 31 were closed on Aug 3, and both are listed above rather than quietly upgraded: test5 takes CR 1.8 from issuance/validation/revocation to the full lifecycle including rotation, and test6 takes CR 3.1 from “by construction” (we rely on TLS) to demonstrated (a bit was flipped on purpose and the AEAD tag caught it). Those are different tiers, and the earlier mapping said so honestly — which is precisely why the upgrade is stated here instead of assumed.

What is proven — and what is the vendor’s claim

Proven here: the architectural principle. A single shared secret across a fleet is compromised fleet-wide by one leak; per-device identity-bound authentication, with revocation, closes that. Demonstrated with running code, including a negative control.

The vendor’s claim, sourced not independently verified: that enabling CIP Security on real Rockwell hardware remediates CVE-2021-22681 exactly this way. That is Rockwell’s own advisory language — quoted, not tested by us against real Logix equipment:

“When properly deployed, CIP Security remediates this vulnerability… does not make use of any hardcoded keys.” — Rockwell Automation, advisory PN1550 (CVE-2021-22681)

These two are kept separate on purpose. The principle is proven; the vendor’s specific implementation is credible — it is their stated design intent — but untested by us against real equipment.

A phased rollout sized for a small utility

Because the flaw never gets patched away, mitigation is ongoing — and it is built so a utility gets most of the risk reduction regardless of whether its hardware can reach the full cryptographic fix.

• Phase 0 — stop the bleeding: get the PLC off direct internet exposure (the single highest-leverage, lowest-cost step), inventory devices, change defaults.
• Phase 1 — segment: OT on its own VLAN behind a firewall; allowlist only the required flows.
• Phase 2 — compensating controls: passive monitoring that alerts on unexpected writes to control tags — the durable control if the hardware can’t do CIP Security.
• Phase 3 — CIP Security / PKI: per-device certificates, identity binding, and revocation — only where the hardware supports it. Honest about that gate.
• Phase 4 — operate: revocation and rotation process, monitoring, a one-page incident runbook. The safe state is maintained, not installed once.

Responsible disclosure

• 2021 — CVE-2021-22681 is made public; the affected key was extracted by legitimate research. Rockwell publishes advisory PN1550: the flaw cannot be patched.
• Jul 26–27, 2026 — A coordinated incident disrupts Minnesota water/wastewater utilities; four are publicly disclosed. CISA advisory AA26-097A is active.
• Jul 31, 2026 — This open resource — PoC, 62443-4-2 mapping, and phased rollout — is built. Rockwell PSIRT is notified before anything is published. Two mapping items are published as open: certificate rotation, and a dedicated integrity test.
• Aug 3, 2026 — Rockwell PSIRT replies, pointing to their own Converged Plantwide Ethernet design guide when asked what a utility should do for hardware that cannot reach CIP Security. That guide is now cited as the authoritative architecture reference for the segmentation phase, rather than a from-scratch plan competing with it.
• Aug 3, 2026 — Both named gaps are closed. test5 demonstrates credential rotation with its own control; test6 demonstrates integrity by flipping a bit inside a live TLS record and watching the AEAD check reject it. The mapping is upgraded on the evidence, not on the calendar.