The unpatchable flaw hitting water utilities.
CVE-2021-22681 is a Rockwell Logix hardcoded-key vulnerability in the picture around the coordinated July 2026 attacks on U.S. water-sector control systems. It is rated CVSS 10.0, and Rockwell’s own advisory states plainly that it cannot be fixed with a patch — the fix is architectural, deployed device by device. This is an open, honest, runnable resource for the small utilities that guidance forgets.
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.
Four 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.”
| Test | What it shows | Result |
|---|---|---|
test1 — baseline | An anonymous client reads and overwrites a live control tag over real EtherNet/IP with zero credentials. | EXPOSED |
test2 — the fleet-key shape | One shared key opens two devices. An illustrative model of the flaw’s shape — deliberately labelled as carrying no evidential weight. | illustration |
test3 — the fix | Per-device identity-bound mutual TLS. Includes the negative control: a CA-validity-only endpoint accepts a foreign fleet cert, proving the identity check is necessary — not just that it fires. Plus the reverse direction. | FIX HOLDS |
test4 — revocation | A still-valid, unexpired, CA-signed credential is granted — then revoked via a signed CRL and refused. A credential can be taken back. | REVOKED |
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.
| Requirement | What it covers | Tier |
|---|---|---|
CR 1.2 | Device identification & authentication | Demonstrated |
CR 1.9 | Strength of public-key auth (incl. revocation status) | Demonstrated |
CR 1.8 | PKI certificates — issuance, validation, revocation | Demonstrated* |
CR 1.14 | Strength of symmetric-key auth | the violated req |
CR 3.1 | Communication integrity | by construction |
* CR 1.8 demonstrated for issuance / validation / revocation; the one remaining lifecycle item (rotation) is named, not smuggled. CR 1.14 appears as the requirement the flaw violates — claimed as met by nothing. CR 3.1 comes with the TLS channel; a dedicated tamper test would move it to fully demonstrated.
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.
Run a small utility, or help one?
The full resource is free and open — the runnable proof of concept, the IEC 62443-4-2 mapping, and the phased rollout. If you want help applying it to a specific environment, or a walk-through of where you actually stand, reach out. No fear-selling — a straight technical conversation about living safely with a flaw that won’t be patched.