A fast-moving, low-tech wave
The disruption began in Minnesota, where more than thirty water systems started showing signs of a coordinated intrusion on July 26. Within about ten days it had spread to at least a dozen states, producing boil-water notices, pressure drops, and localized flooding. The Federal Bureau of Investigation and the Environmental Protection Agency described the pattern plainly: attackers got into internet-connected devices, changed their IP addresses and passwords, and effectively took the controls away from the people meant to hold them. Multiple news reports have pointed toward Iranian-linked actors, but public reporting has not settled on a single, universally confirmed attribution — and the more interesting story isn’t really about who did it. It’s about how astonishingly easy it was.
Most affected facilities got water flowing normally again within hours by switching to manual operation. That is genuinely good news for anyone who depends on a tap working. But "back online quickly" and "secure" are not the same claim, and treating them as interchangeable is exactly the mistake that let this happen in the first place.
The devices at the center of it all
The equipment being hijacked was not exotic. Programmable logic controllers, or PLCs, are the small industrial computers that translate a command — open this valve, run this pump — into a physical action. They sit at the boundary between digital instructions and the real world, and versions of them run pumps, conveyor belts, and treatment equipment in nearly every industrial setting in the country, water utilities included. Many have been quietly working for decades, installed long before anyone worried about internet exposure, and they are rarely patched with the urgency of an office laptop.
That long service life is precisely why they became targets. According to the CNET account of the incident, once attackers located an exposed PLC, exploiting it required no advanced technique at all: look up the manufacturer, pull the default login from a published manual, and type it in. Michael Garcia, policy director at the Operational Technology Cybersecurity Coalition, put it bluntly — these were controllers that "shouldn’t have been connected to the internet" in the first place, protected by "either no passwords… or weak passwords like ‘1234’ or ‘password’". On July 30, the research firm Censys catalogued 4,148 internet-exposed hosts made by one major PLC manufacturer alone, the majority located in the US. That figure describes exposed devices, not confirmed victims — a distinction worth holding onto, since not every reachable controller was necessarily accessed, and the number of exposed hosts is not the same as the number of affected utilities.
From exposure to disruption: a familiar chain
Strip away the news-cycle drama and the incident follows a fairly consistent sequence, one that shows up again and again in critical-infrastructure security cases:
| Stage | What happens | Why it’s possible |
|---|---|---|
| Discovery | Attacker scans public internet-search tools for exposed control devices | PLC management interfaces are visible on the open internet |
| Identification | Device model and manufacturer are identified from network fingerprints | Little effort is made to obscure or firewall device details |
| Access | Default or weak factory credentials are entered directly | Passwords are shared across installations and often published in manuals |
| Takeover | IP addresses and passwords are changed, locking out operators | No monitoring flags the sudden loss of legitimate access |
| Fallback | Utility switches to manual operation to restore service | Physical override remains possible even when digital control is lost |
Read this way, the story isn’t a tale of clever hacking — it’s a tale of things nobody was tracking. Nobody had a reliable list of which controllers were internet-facing. Nobody had rotated the credentials that shipped with the hardware. Nobody had an alert for "this device just went dark to us."
The visibility problem underneath the password problem
This is where the story stops being a narrow cybersecurity item and becomes a data-governance one. Passwords are the visible symptom; the underlying condition is that most utilities cannot answer basic questions about their own infrastructure — what’s connected, where it’s reachable from, who is authorized to log in, and how quickly that access can be verified or revoked. Without accurate, current data about the devices themselves, "improve security" has no starting point.
flowchart LR A[Device inventory: what exists] --> B[Network exposure: where it's reachable] B --> C[Access rules: who can log in] C --> D[Credential hygiene: default vs. changed] D --> E[Operator visibility: can we detect a takeover]
Each link in that chain is a data problem before it’s a hacking problem. You cannot secure a controller you don’t know is online. You cannot enforce access rules on a device that isn’t inventoried. And you cannot detect a lockout quickly if there’s no baseline record of who normally logs in and when. CISA had actually warned about this exact failure mode as far back as 2023, and again in April of this year with specific device types named — the second warning arriving only days before the Minnesota attacks began. The gap wasn’t unknown; it was un-fixed, which is a different and arguably more solvable problem.
Manual control is a stopgap, not proof of safety
It’s tempting to read the fast recoveries as evidence the system worked. Manual operation clearly limited how bad things got — most people never lost water service at all. But falling back to manual control mainly proves that human operators could still physically run the plant; it does not, by itself, establish that a compromised controller was thoroughly checked, cleaned, or restored to a known-good configuration before being trusted again. Operational continuity and security assurance are different achievements, and conflating them is how the same exposed devices end up back online, unexamined, a year later.
Why this keeps happening
Part of the answer is structural. There are roughly 156,000 public water systems in the US, and 97% of them serve 10,000 people or fewer — meaning most are run on thin budgets with little dedicated IT staff. Federal grant money aimed at helping smaller utilities modernize has largely run out, and a reauthorization effort has stalled in Congress. Maurice Dawson, a critical-infrastructure researcher at the Illinois Institute of Technology, summarized the trajectory: security erodes gradually as systems age, until "that system is very vulnerable, and it’s expensive to repair". Garcia’s warning is similarly sobering — this pattern has repeated for years without a mass-casualty event, "but there is that potential".
The real lesson
None of this requires exotic threat intelligence to fix. It requires something less glamorous: accurate inventories of what devices exist, disciplined rules about who can reach them, and routine credential hygiene that doesn’t rely on a factory default sitting in a downloadable manual. A password is easy to change. Knowing which of your 156,000 water systems has a controller sitting exposed on the open internet, right now, is the harder — and far more important — question.
