Last Sunday night, while most of Minnesota was winding down the weekend, operators at more than 30 community water systems got a call nobody wants. Their automated controls were down, and the pumps weren't responding. In Braham, a town of about 1,700 people, the water plant went completely offline and the water tower couldn't fill. In nearby Plymouth, cellular communications failed at two water towers and several wastewater lift stations. Then South St. Paul and Maple Plain scrambled to switch to manual operations. Maple Plain's mayor declared a local state of emergency.
I want to sit with that for a second…. a local state of emergency…over a cyberattack…on a water plant. All this in a town most people outside Minnesota have never heard of.
If you work in this industry long enough, you start seeing everything on two metaphorical screens at once. On one screen, the headlines about nation-state actors and advanced persistent threats and sophisticated campaigns. On the other, the version you hear from the people who were actually there… a public works crew driving to a pump station at 11pm on a Sunday to manually fill a water tower because a PLC stopped responding. Those two screens are supposed to be showing the same story, but they never quite feel like they belong together. Until they do.
This is one of those moments.
The Minnesota attacks landed on July 26 and 27. Within days, CISA, the FBI, and the EPA issued warnings that were simultaneously urgent and depressingly familiar. Cyber threat actors are targeting internet-exposed programmable logic controllers (PLC) in water and wastewater systems. Once in, they're modifying passwords to lock out operators. The activity has resulted in boil water notices and sustained manual operations in multiple communities. Federal investigators are looking at a possible Iran connection, though attribution hasn't been formally confirmed.
None of this should surprise anyone who's been paying attention. It should, however, make a lot of people uncomfortable. Because the truth is, we've known this was coming for a long time. We just haven't done enough about it.
I'll be honest with you. I'm not an OT security specialist. I've spent most of my career on the enterprise IT side of the house, dealing with the usual suspects (endpoints, identities, cloud configurations, the occasional existential audit). Yet I've been in enough rooms with enough OT teams and leaders to understand the fundamental disconnect that makes stories like this possible. The people running water treatment don't think of themselves as cybersecurity targets, they think of themselves as water people…they maintain pumps and valves and chemical feeds, all the stuff that keeps the system running. The fact that all of those pumps and valves now have IP addresses on them is something that happened to them, not something they actively chose.
That distinction matters more than anyone in cybersecurity wants to admit. Let's talk about what actually happened here, because the details matter more than the headlines.
CISA's advisory, AA26-097A, was originally published back in April 2026 to warn about Iranian-affiliated APT groups targeting internet-connected PLCs across U.S. critical infrastructure. In July, they updated it with expanded scope and new detection guidance. The original advisory focused on Rockwell Automation Allen-Bradley controllers. The update added Schneider Electric BMX P34 and Modicon M340 series PLCs, Siemens S7-1200 series PLCs, and a note that devices from other manufacturers may also be at risk.
Think about that expansion for a minute. It went from "they're targeting this one brand" to "they're targeting these three brands and probably others." That's not a vulnerability in a product…. that's a campaign against a business category.
The attackers aren't doing anything exotic, that's what makes it so frustrating. At one victim site, the FBI observed APT actors downloading a malicious project file to a targeted PLC using the same configuration software the operators use every day. The project file kept the existing ladder logic for downstream operations (so the plant keeps running and nothing looks obviously broken) but added instructions that overrode specific instruction sets responsible for maintaining safe operating parameters. Read that again. They didn't disable the system, instead they changed how it thinks about safety.
They're also manipulating data on HMI and SCADA displays just so operators think everything looks normal while the underlying process is being tampered with. They're exfiltrating files over remote command-and-control channels. They're changing passwords to lock operators out of their own equipment. In some cases, they're using Dropbear Secure Shell software to establish persistent remote access.
I always get nervous when things look normal.
The July 22 update to the CISA advisory added something that should concern anyone who works with industrial control systems: guidance on detecting malicious changes in reusable code modules within PLC programs. That's a specific enough detail to tell you that the attackers have moved beyond just flipping switches. They're modifying the building blocks of the control logic itself; the kind of change that could survive a project file reload if nobody knows to look for it. The tradecraft is maturing even though the initial access method remains embarrassingly simple.
That last point, the password changes, is maybe the most viscerally unsettling. Imagine you're a water plant operator in a small town. You've been doing this job for fifteen years. You know every valve, every pump, every quirk of the system. Then one night your SCADA login doesn't work. The HMI at the plant says everything is fine, but you can't actually control anything. You're locked out of equipment you could physically walk up to and touch. That's not a theoretical scenario anymore.
The Iran connection runs through a group that private industry knows by several names: CyberAv3ngers, Hydro Kitten, Storm-0784, Bauxite. They're affiliated with the Islamic Revolutionary Guard Corps, specifically the IRGC Cyber-Electronic Command. They have a long track record of targeting small water utilities and municipal facilities. Back in late 2023, this same group compromised at least 75 Unitronics PLC devices with HMI interfaces across U.S. critical infrastructure. In 2020, Iran-linked actors hit water facilities in Israel by exploiting vulnerable cellular routers as entry points.
The pattern is consistent and, if we're being honest, kind of predictable. They target devices that are exposed to the internet, running default or weak credentials, in organizations that have minimal monitoring and no dedicated security staff. They don't need zero days. They don't need sophisticated malware. They need a Shodan search and some patience.
This is where the story gets uncomfortable for our industry, because we've built an entire ecosystem around protecting enterprises from advanced threats while largely ignoring the infrastructure that actually keeps society running.
Consider the timing. The same week these water plants were going offline in Minnesota, the cybersecurity world was consumed by the story of an OpenAI agent that autonomously hacked Hugging Face's production infrastructure. Fascinating story. Genuinely important implications for AI safety and security testing. It dominated every security feed, every LinkedIn hot take, every podcast. Meanwhile, 30 water plants got hit with techniques that would have been preventable with basic network segmentation and a password change. We talked about what's novel, but we didn't talk enough about what's lethal. An AI agent escaping a sandbox is a research problem. A nation-state actor turning off water treatment in 30 communities is a public safety crisis. Guess which one got more coverage.
The United States has more than 148,000 public drinking water systems. When you add publicly owned wastewater treatment systems, you're looking at somewhere between 165,000 and 170,000 facilities. The overwhelming majority of those are small. Approximately 90 percent of public water supplies serve fewer than 10,000 people. Many serve a few hundred. They're run by small municipalities, rural co-ops, or regional authorities operating on budgets that would make a mid-market IT department wince.
Here's the asymmetry that keeps me up at night: a technique that would be easily contained in a well-resourced utility can cause prolonged operational impacts in a small system with limited monitoring, limited segmentation, and no dedicated cybersecurity personnel. Adversaries scale effortlessly, while the small municipal systems cannot. The attacker can hit 30 water plants in one weekend with the same playbook. Each of those 30 plants has to respond individually, with whatever resources and expertise they happen to have on hand.
I've been guilty of this kind of thinking myself. When you work in financial services or healthcare or any of the big, regulated verticals, it's easy to think of critical infrastructure protection as someone else's problem. We've got our own compliance frameworks, our own threat landscape, our own fire drills. Water and power are just… there. They work. Someone else handles that. Until they don't.
The regulatory picture makes it worse. If you compare the water sector to its nearest peer, electrical utilities, the gap is stunning. Electric utilities are subject to nearly 50 federally mandated preventive controls under NERC CIP. The water sector's equivalent, America's Water Infrastructure Act, requires a risk assessment. That's it… Not controls, not implementation, not verification…. just a risk assessment. The policy exists. The behavior does not always follow.
The EPA tried to change this in March 2023, introducing a rule that would have required states to evaluate and report on cybersecurity during routine sanitary surveys. By October 2023, after legal challenges from Missouri, Arkansas, Iowa, and water utility trade associations arguing the rule exceeded EPA authority and burdened smaller systems, the agency withdrew it. The regulatory retreat left cybersecurity oversight for water largely voluntary at the federal level.
New York stepped in this year with the first mandatory state-level cybersecurity regulation for water and wastewater systems, targeting utilities serving over 3,300 people. Governor Hochul paired it with a $2.5 million SECURE grant program. It's a meaningful step, but $2.5 million across an entire state's worth of water utilities is not exactly a war chest. It's a signal, and signals are good, but PLCs don't patch themselves because a governor gave a press conference.
Meanwhile, the State and Local Cybersecurity Grant Program that many states use to fund security work at smaller water systems has been lurching through continuing resolutions, expiring, getting reinstated, and currently living on borrowed time through September 2026. If you're a utility director trying to plan a multi-year cybersecurity investment, building your budget on a grant program that might not exist next fiscal year is not a strategy. It's a prayer.
I think the hardest conversation we need to have is about what "cybersecurity" actually means for a water utility serving 1,700 people. It doesn't mean hiring a SOC team. It doesn't mean deploying a SIEM. It doesn't mean buying the platform that the vendor at the conference promised would solve everything. It means disconnecting the PLC from the internet. It means changing the default password. It means setting up network segmentation between the OT environment and the business network (if there even is a business network distinct from the operator's laptop connected to the plant WiFi). It means knowing what's on your network and who can reach it.
These are not advanced concepts. They are the absolute basics. The kind of thing we teach in the first week of any security fundamentals course. The kind of thing every CISA advisory since the beginning of time has recommended.
So why hasn't it happened?
Because basics cost money, and money comes from somewhere, and in a small municipality "somewhere" means the same budget that also pays for road repair, snow removal, fire services, and the part-time IT person who also manages the city website. Because the person operating the water plant is not a cybersecurity professional and never wanted to be one. Because disconnecting the PLC from the internet means someone has to physically drive to the pump station to check on it instead of monitoring it remotely, which means more staff hours, which means more budget, which means another line item the city council has to approve. Because the OT vendor sold the system with remote access enabled as a feature, not a liability. Because the integrator who set up the SCADA system five years ago used TeamViewer for remote support and never came back to harden anything.
I've talked to utility operators at conferences (the ones who actually show up to the OT security track instead of the AI keynote) and the story is always some version of the same thing. They know the risks. They've read the advisories. They understand, in theory, what network segmentation means. What they don't have is the time, the money, or the staffing to do anything about it. One operator told me his "cybersecurity team" was him, and he was also responsible for water treatment, maintenance scheduling, and regulatory compliance with the state health department. He said he'd love to implement CISA's recommendations if someone could show him where the extra twelve hours in his week were hiding.
Every one of those "because" is a real constraint, not an excuse, but a real constraint. There is a difference, and if you don't acknowledge that difference, you end up writing advisories that nobody can actually implement. We keep treating this as an awareness problem. It is not an awareness problem. It is a resource problem. The awareness is there. The capacity is not.
CISA's core recommendation is straightforward: disconnect vulnerable PLCs from the internet. Validate external connections. Review project files for unauthorized changes. Apply manufacturer guidance for secure configuration. These are all correct. They're also all things that require time, expertise, and funding that many of these utilities don't have. Telling a small-town water operator to "validate external connections" when they have one IT person who also maintains the phone system is like telling someone to perform surgery with a first-aid kit. The instructions are technically accurate. The capacity isn't there.
I think the path forward must involve something more structural than advisories and grant programs. We need a model where cybersecurity services are delivered to small water utilities the way we deliver public health services to rural communities (through state and federal programs that provide actual hands-on support, not just guidance documents). Some of this is already happening. Minnesota IT Services activated its cybersecurity incident response across the state after the attacks. CISA has its own technical assistance programs. The National Guard cyber units have engaged with local utilities in some states. But these are reactive measures, crisis responses, not a sustained operating model.
What would a sustained operating model look like? It starts with treating water system cybersecurity like public health infrastructure, not like an individual facility's IT problem. Centralized monitoring services for small utilities that can't afford their own. State-managed OT security baselines that are implemented, not just published. Funded positions for regional OT security specialists who can serve multiple small utilities. Mandatory segmentation requirements tied to the type of controller, not the size of the utility. And vendor accountability for shipping internet-connected OT equipment with default credentials and no meaningful security hardening.
None of this is easy. All of it costs real money. But here's a question worth asking: What does it cost when 30 water systems go down in a weekend? What does it cost when a community issues a boil water notice and residents lose confidence in the system? What does it cost when an operator has to work 36 straight hours because the automation that was supposed to make their job manageable just became the attack surface? We keep treating cybersecurity as an expense. It is increasingly becoming the cost of keeping the lights on and the water flowing.
The Minnesota attacks hit 30 systems in a single weekend. Next time it could be 300. The playbook is public, the targets are exposed, and the attackers have demonstrated both capability and intent.
The CyberAv3ngers and their cousins are not going to stop targeting small water utilities because we published another advisory. They're going to stop when the economics change, when attacking a water plant in Braham, Minnesota is no longer trivially easy. Right now, it is. Default credentials, internet-exposed PLCs, no monitoring, no segmentation, no incident response plan. That's not a security posture. That's a welcome mat.
Here's the thing that keeps nagging at me. We got lucky this time. The Minnesota attacks disrupted operations, forced manual overrides, triggered a state of emergency in one town. But nobody got hurt. The water stayed safe. No contamination. No public health crisis. Just a very bad weekend for a lot of hardworking people in small towns who suddenly had to figure out how to run a water system the old-fashioned way.
We might not be lucky next time. The CISA advisory specifically calls out attackers overriding safety parameters in PLC logic. Safety parameters exist for a reason. They keep chemical dosing within safe ranges. They prevent pressure from exceeding what pipes can handle. They shut systems down before something physically dangerous happens. When you modify those parameters and simultaneously make the HMI display look normal, you're not just disrupting service. You're creating the conditions for something much worse. The 2021 Oldsmar, Florida incident (where an attacker briefly increased sodium hydroxide levels to more than 100 times the safe amount) was caught by an alert operator watching his screen in real time. Not every plant has that operator. Not every attack will be that obvious.
I keep coming back to a simple question that I think everyone in our industry should be asking themselves: If the water in your town stopped running tomorrow because of a cyberattack, who would you call? Not which vendor. Not which framework. Which actual human being would drive to the plant and know what to do?
If you don't know the answer, there's a chance that neither does your town.