For years, warnings about cyberattacks on critical infrastructure have sounded almost cinematic: foreign hackers penetrate a water plant, seize industrial systems, and threaten the physical world from behind a keyboard. Then, over a few days in late July, something uncomfortably close to that scenario began playing out across the United States.
Attackers reached technology used to monitor or control municipal water infrastructure. More than 30 community water systems were reportedly affected in Minnesota. By July 30, utilities in at least seven states had reported incidents to federal authorities. By August 4, ABC News reported that the number had grown to at least 12 states.
And in at least one Minnesota town, the cyberattack crossed the line from a computer problem into a physical operational disruption. Attackers shut down operating controls in Braham, Minnesota, briefly taking the city's well and water treatment plant offline.
The water remained safe.
The absence of a water-quality impact is reassuring. But it shouldn't obscure the bigger story.
Someone reached systems connected to the physical operation of American water infrastructure—and the publicly described attack path suggests they may not have needed some extraordinary, nation-state-grade exploit to do it.
They found industrial controllers exposed to the internet. The attack path may be the most consequential part of this entire story.
This Wasn't Just Another IT Breach
Most cyberattacks happen in a world the public rarely sees: stolen passwords, encrypted servers, compromised email accounts, exfiltrated databases. Industrial cyberattacks are different.
A programmable logic controller, or PLC, isn't just another computer sitting in an office. It can help operate pumps, valves, pressure systems, tank levels, treatment equipment, and other machinery that makes physical infrastructure work.
The FBI and EPA specifically warned about internet-facing Rockwell Automation/Allen-Bradley MicroLogix 1100 and 1400 PLCs. According to the federal alert, attackers accessed controllers directly over the internet rather than entering through a victim VPN. They changed IP addresses and passwords, causing organizations to lose monitoring and control functionality.
At least one organization also discovered discrepancies in ladder logic—the programming that tells industrial equipment what to do.
Read that again.
Attackers weren't merely stealing information from business networks. They were reaching computers that participate in controlling physical processes.
That doesn't mean attackers could poison a city's water with the click of a button. PLCs perform different functions at different facilities, safety mechanisms exist, and operators can retain physical control even when remote visibility disappears. But it does mean the boundary between "cyber" and "physical" became very real.
The Attackers May Have Found the Front Door Open
There is still a great deal we don't know about how every affected utility was compromised. But the federal government's description of the campaign points toward a remarkably straightforward problem: some industrial controllers were directly reachable from the public internet. That changes how we should think about this incident.
The popular image of a critical-infrastructure hacker is someone defeating layer after layer of sophisticated security. The emerging picture here may be much less glamorous—and more troubling.
If a controller is listening on the public internet and accepts a connection, an attacker may not need to compromise an employee's laptop, defeat a corporate VPN, move laterally across an enterprise network, and spend weeks quietly navigating toward the operational environment. The attacker may already be standing at the digital equivalent of the equipment-room door.
Federal authorities are now explicitly telling organizations to remove direct inbound internet exposure from these controllers. That recommendation sounds obvious after an attack. The more uncomfortable question is how many controllers across America's distributed infrastructure are still reachable today.
Minnesota May Have Shown Us What the First Minutes Look Like
Braham experienced the clearest publicly reported physical disruption. Attackers shut down operating controls, and the city's well and water treatment plant went offline temporarily. Residents were asked to reduce water consumption for several hours. Officials reported no water-quality problem.
In Plymouth, the situation looked different but was arguably just as instructive. Communications with two water towers and multiple lift stations failed overnight beginning July 26. City workers switched to manual procedures.
Water levels remained safe. Water quality remained unaffected. Communications were eventually restored.
That is an operational success story. It is also a preview of industrial cyber resilience in action. When the digital layer failed, humans kept the physical system running.
Manual fallback wasn't an outdated backup plan. For a period of time, it was part of the cybersecurity architecture.
As critical infrastructure becomes increasingly connected, remotely managed, and automated, safe manual operation becomes even more valuable. The ultimate resilience feature may sometimes be the ability to operate safely when the computers stop cooperating.
And Then the Map Started Growing
Initially, Minnesota dominated the reporting. Then Michigan confirmed incidents involving nine municipal water systems. Two municipal systems in New Jersey were also reportedly affected.
By July 30, the FBI and EPA said utilities in at least seven states had reported incidents. By August 4, ABC News reported at least 12 states were dealing with cyberattacks on water systems. The complete list has not been made public.
With the complete list still undisclosed, filling a map with cities based on rumors or assumptions would be irresponsible.
But the trajectory points to something larger. What initially looked like a collection of local incidents increasingly resembled something larger.
And that raises another uncomfortable possibility: We may not yet know the true size of the exposed population.
Finding compromised systems is not necessarily the same thing as finding all vulnerable systems. An investigation can tell us where attackers have been detected. It does not automatically tell us how many similar devices remain reachable.
That distinction could become one of the most consequential questions to emerge from this campaign.
Everyone Wants to Know if Iran Did It
The answer right now is: maybe. Public reporting increasingly points in that direction, but the FBI has not publicly identified the perpetrator of the July-August water incidents. ABC News reported that Iran was the prime suspect.
A WaterISAC communication obtained by WIRED reportedly said the Minnesota activity aligned with an Iran-affiliated campaign previously described by federal agencies. There is plenty of historical reason investigators would examine that possibility.
CyberAv3ngers—also identified in federal reporting as the Shahid Kaveh Group—is an Iran-linked actor with a history of targeting internet-facing industrial controllers, including equipment in the water sector. Federal agencies have also documented a broader 2026 campaign involving Iran-affiliated actors targeting operational technology in water, government, and energy environments. WIRED reported another private-sector theory involving Handala, another Iran-linked possibility.
But none of those facts proves who conducted these specific attacks. So the most accurate conclusion is also the most interesting one: Iran appears to be the leading publicly reported theory. The FBI hasn't publicly closed the case.
And from a defensive perspective, waiting for that answer may be beside the point. Whether the person connecting to an exposed PLC is an Iranian operator, a hacktivist, a criminal, or a teenager experimenting with internet scanning, an unnecessarily internet-accessible industrial controller presents essentially the same immediate engineering problem.
Close the door.
This Could Have Been Much Worse
There is an understandable temptation to look at the outcome and conclude that the defenses worked.
- Water continued flowing.
- Water quality remained safe.
- Operators recovered.
- No catastrophe occurred.
All true. But that's not necessarily the right lesson. The more useful question is what prevented these incidents from becoming worse.
In Plymouth, humans took over manually. In other environments, fail-safe systems, physical safeguards, equipment design, operational procedures, or simply the limited function of a compromised controller may constrain what an attacker can accomplish. Those layers can limit the consequences.
But defenders shouldn't confuse a resilient outcome with an acceptable exposure.
The fact that operators successfully caught the ball doesn't mean we should keep throwing it at them.
If an attacker can remotely alter a controller's network configuration, change credentials, interfere with monitoring, or potentially modify controller logic, the objective should be to prevent that access—not merely become excellent at surviving it.
The Bigger Story Isn't One Brand of PLC
It would be easy for this episode to become "the MicroLogix vulnerability story." The underlying issue is architectural.
Water infrastructure is distributed by nature. Wells, towers, pumps, lift stations, and treatment facilities can be separated by miles. Small teams need ways to monitor equipment and troubleshoot problems without driving to every site.
Remote access isn't the mistake. Uncontrolled remote access is.
A controller should not need to sit directly on the public internet simply because an engineer needs to reach it remotely. The safer model is increasingly obvious: keep controllers behind segmented networks, broker remote sessions through controlled gateways or hardened jump hosts, require strong identity and phishing-resistant multifactor authentication, restrict which devices and people can connect, limit sessions to what is actually required, and record what happens. In other words, remote access should behave like access to critical infrastructure—not like connecting to a forgotten appliance.
There's Another Problem: We Don't Know What We Don't Know
The federal reporting contains details that deserve considerably more attention. Attackers changed controller IP addresses and passwords. At least one organization reported discrepancies in ladder logic.
In the broader Iran-affiliated operational-technology campaign documented earlier this year, federal agencies described project-file extraction, manipulated HMI or SCADA display data, common industrial communications ports, and remote-access tooling on victim endpoints. There is no public evidence that all—or even most—of those techniques appeared in the July water incidents.
Restoring communications is only the first question. The next questions are harder:
- What changed?
- What else did the attacker reach?
- Does the controller logic still match the known-good version?
- Were engineering files modified?
- Were credentials reused elsewhere?
- Did the attacker establish another access path?
- Can we prove the system we're bringing back online is the system we think it is?
For operational technology, "it's working again" and "we trust it again" are not necessarily the same statement.
The Fix Is Surprisingly Unsexy
There probably isn't one magical cybersecurity product that solves this problem. The highest-value work is much more mundane.
- Find every PLC, modem, engineering workstation, gateway, and vendor connection.
- Determine what is reachable from outside.
- Remove direct internet exposure wherever possible.
- Put necessary remote access behind controlled gateways.
- Restrict connections to known identities and expected devices.
- Compare controller configurations and logic against known-good copies.
- Keep offline backups.
- Protect logs.
- Practice operating manually.
- Practice restoring systems.
- Know who has the authority to switch operating modes when something goes wrong.
None of that sounds futuristic. Critical-infrastructure cybersecurity may depend less on building science-fiction defenses than on relentlessly eliminating ordinary, preventable exposure.
AI Could Help With the Part Humans Are Bad At
There is also an emerging opportunity here. A national cyber alert tells a utility what investigators are seeing across the country. It does not automatically tell that utility:
Does this apply to us?
Answering that requires comparing threat intelligence against local reality: controller models, firmware versions, exposed services, vendor access paths, network architecture, project files, known-good configurations, and operational dependencies. That's exactly the kind of information-reconciliation problem where carefully governed AI could become useful.
An AI-assisted defensive workflow could continuously ingest vetted public intelligence, compare it against an approved inventory, identify likely matches, flag missing information, and generate a facility-specific validation plan for human review. The important phrase is human review.
AI should help qualified operators and security teams understand their environment faster. It should not autonomously change PLC logic, isolate production systems, or make safety-critical decisions.
The interesting future isn't an AI running the water plant. It's an AI noticing at 2:13 a.m. that a new federal alert describes the exact controller sitting at Pump Station 7—and putting the right evidence in front of the right engineer before an attacker finds it first.
America May Have Just Received a Warning Shot
There is no evidence that the July-August attacks caused widespread unsafe drinking water. That's good news. But focusing only on what didn't happen risks missing what did.
Attackers reached technology involved in physical infrastructure. At least one community temporarily lost operating controls. Other operators lost communications and shifted to manual procedures.
Federal authorities say attackers directly accessed internet-facing industrial controllers and changed their configurations. Reports spread from Minnesota to utilities across at least 12 states. And investigators are examining possible links to a broader Iran-affiliated campaign targeting American operational technology.
That combination should get attention.
Not panic. Attention.
Because the most useful interpretation of these incidents may not be that America's water infrastructure was nearly brought down. It's that we just got to see what an early-stage attack on poorly isolated physical infrastructure can look like—and operators were able to recover before the consequences became severe.
- Next time, the target could be different.
- The operator could respond more slowly.
- The compromised controller could perform a more consequential function.
- The attacker could be more capable.
- Or the fallback systems might not work as well.
We don't know. That's speculation—but it's exactly the uncertainty critical-infrastructure operators are supposed to plan around.
The United States doesn't need to wait for investigators to put a flag next to the attacker's name before acting on the clearest lesson from this episode.
If a computer can control something important in the physical world, strangers on the internet should not be able to knock on its front door.
That door can start closing now.