In late July, a coordinated cyberattack hit the operational technology (OT) at more than 30 community water systems in Minnesota, the first state to confirm what has since grown into a much larger campaign.
Cyberattacks on water and wastewater systems have now been reported in at least 12 states, including Michigan, Georgia, New Jersey, and South Dakota. In Minnesota, the attack knocked Braham’s water plant offline for about two hours and forced utilities in Plymouth and South St. Paul to switch to manual operation. In Georgia, cyber activity against the Clayton County Water Authority, which serves roughly 300,000 customers near Atlanta, caused a water pressure drop and a boil water advisory before service was restored within hours.
The FBI, the Environmental Protection Agency (EPA), and the Cybersecurity and Infrastructure Security Agency (CISA) have warned utilities nationwide to pull internet-exposed controllers offline and harden credentials. Federal investigators suspect Iran-backed hackers but have made no formal attribution. The tactics resemble a 2023 campaign by CyberAv3ngers, a group tied to Iran’s Islamic Revolutionary Guard Corps that has targeted U.S. water controllers before.
This string of attacks is pushing years of warnings into action. In early August, the American Water Works Association, whose member utilities supply drinking water to much of the country, sent a letter to Congressional leaders urging federal support and backing legislation that would set minimum cybersecurity standards for the water sector.
The centerpiece is the Water Risk and Resilience Organization Establishment Act, which would create an independent, nongovernmental body to develop those requirements under EPA oversight, modeled loosely on how the North American Electric Reliability Corporation (NERC) oversees the power grid.
Mandatory water standards are within reach. But if water utility cybersecurity becomes mandatory, what should the requirements actually accomplish? The most meaningful standard is measurable operational resilience, judged by whether essential water service continues to run when an attacker gains access, rather than by how much cybersecurity activity a utility can document.
What Strong Water Cybersecurity Standards Should Require
Cybersecurity regulation tends to produce what is easy to document, such as policies, assessments, asset inventories, scans, training records, and patching logs. Those records have real value, but they do not reveal what would happen if an attacker gained access to the systems controlling pumps, valves, pressure, and treatment. In OT environments, the consequences of an intrusion extend beyond data and into physical operations.
A strong standard should start with the basics, and the recent attacks show why. The intrusions did not rely on advanced techniques. They exploited programmable logic controllers (PLCs) that were connected to the public internet with weak or default protections, allowing attackers to change passwords, lock out operators, and disrupt visibility and control. Foundational requirements address exactly this scenario, with security measures like asset inventory, secure configuration, credential management, network segmentation, keeping controllers off the public internet, and vulnerability management. Any serious standard has to require them.
Those foundations raise the bar for getting in, but they do little once an attacker is already manipulating a device. As RunSafe CEO Joe Saunders put it, “The shift toward mandatory cybersecurity standards is understandable as cyberattacks are now visibly threatening physical operations. However, regulation will only improve resilience if it focuses on measurable security outcomes.”
The outcome that matters most is service continuity under active compromise, which the recent attacks demonstrated. Automated controls were affected, and some operators ran systems by hand, yet drinking water remained safe, and most services continued to run.
Getting there means protecting the devices and the software inside them, so that reaching a controller does not automatically translate into stopped or interrupted service. A resilient standard should push utilities to answer a tighter set of operational questions.
- Can they identify the software and devices actually running in the operational environment?
- Can a compromised system be isolated without shutting down the service it supports?
- Can operators keep critical functions going if automated control becomes unavailable?
- Can vulnerable software keep running safely when an immediate patch is not available?
- Can unauthorized software behavior be constrained before it reaches a physical process?
- Can the utility show that these controls work in practice?
Those questions move compliance away from documenting that an activity was performed and toward demonstrating that essential systems are meaningfully harder to disrupt. For critical infrastructure, perimeter defense is only half the job. The other half is making sure that when an attacker does get in, and these attacks show they can, the access cannot be turned into a physical consequence.
Patching Matters, But It Can’t Cover Every OT Risk
Vulnerability management belongs in any water cybersecurity standard, but it cannot carry the whole load. OT is a very different patching environment from enterprise IT. Industrial devices stay in service for years or decades, updates often need extensive testing, systems cannot always be taken offline the moment a vulnerability is disclosed, and some equipment runs software the utility neither wrote nor can easily modify. Meanwhile, the volume of disclosed vulnerabilities keeps climbing. That combination guarantees a window between the moment a vulnerability exists and the moment it is finally fixed.
So operators need both remediation and mitigation. Remediation removes the vulnerability, while mitigation reduces an attacker’s ability to exploit it or limits the damage if exploitation happens anyway. For fielded OT devices that may run long after their software was written, mitigation is often the only protection available during the months or years before a patch can ship.
Saunders frames the operator’s job the same way: “Water utilities need to know what software and devices they’re running, identify exposed components, protect systems that cannot be patched quickly, and constrain unauthorized behavior before a cyber compromise becomes a physical consequence.”
Procurement Standards Can Push Security Upstream
One of the more consequential choices before Congress is where responsibility for water cybersecurity should lie. Utilities carry real obligations as operators. They have to configure systems securely, manage access, segment networks, and keep visibility into their environments. Asking them to compensate indefinitely for insecure software embedded in products they merely purchased is a different matter.
Procurement standards can shift some of that weight upstream. They can push utilities to evaluate whether the software and devices they buy include protections that reduce exploitability, whether vendors support products across their full operational life, and whether security holds up when fast patching is impractical. That begins to move security from something bolted onto a deployed system toward something designed into the products that critical infrastructure depends on.
Building Toward Resilient Water Service
No regulation will guarantee that a water utility never gets compromised, and that was never the right measure of success. Attackers will continue to find exposed devices, weak credentials, and unpatched software.
The standard worth writing is the one that keeps those weaknesses from turning into consequences, so a breached system can be isolated, essential services continue, and an incident is contained before it changes what happens to the water.
Mandatory rules may be coming to the sector. If they arrive, policymakers have a chance to define resilience in operational terms and require operators and technology providers to prove it, not just to document that they tried.
Learn how RunSafe Protect reduces software exploitability and protects water systems from attacks at runtime.







