You can't Secure What You Don't See
HuFiCon Management Memo:
Journey with the CISO
A mountain climb to cyber security resilience. Find out how to get to the summit of cyber security resilience in Inge van der Beijl's management memo, from her presentation at the Human Firewall Conference (HuFiCon) on the 14.11.2024.
The climb will take you from the base camp of foundational security to the high-camp of a security conscious culture, all the way to the summit consisting of strategic security integration.
Inge van der Beijl
Director Innovation
Lessons from the Cyberattacks on US Water Systems
Over two days in late July 2026, more than 30 municipal water utilities across Minnesota were hit by a coordinated cyberattack. Confirmed activity has since been reported in at least 12 US states.
For anyone working in OT security, the story is worth reading closely — not because the attackers used anything extraordinary, but because they didn't need to.
What happened to the US water systems?
Between 26 and 27 July 2026, attackers gained access to internet-connected programmable logic controllers (PLCs) at municipal water and wastewater facilities. The initial reporting centred on Rockwell Automation / Allen-Bradley controllers, with follow-up advisories confirming that Schneider Electric and Siemens equipment was exposed to the same technique. The access method itself is what makes this campaign notable. Rather than deploying custom malware or exploiting a novel vulnerability, the attackers used the vendors' own legitimate engineering software — tools like Studio 5000, EcoStruxure Control Expert, and TIA Portal — connecting to controllers exactly the way an authorised engineer would, over the standard protocols those tools expect. Because this traffic looks like normal engineering activity, it may not trigger the alarms that custom malware or unusual protocol behaviour typically would (although the Northwave OT MDR service would detect this due to an unusual source address).
Once inside, the attackers changed IP configurations and administrative credentials, locking operators out of their own SCADA environments. In at least one confirmed case, they went further: disabling safety shutdown and alarm logic, while feeding operators falsified process data through the HMI. An operator watching what looked like a normal dashboard had no way of knowing anything was wrong. The operational consequences were immediate and, in places, severe. The treatment plant in Braham, Minnesota went offline for over an hour, leaving its water tower unable to refill and prompting a call for public conservation. Plymouth and South St. Paul fell back to manual operation at affected sites. Maple Plain declared a local emergency. Recovery in several cases required physically clearing tampered controllers by removing battery backups to wipe the altered configuration, then re-flashing a clean, known-good project file offline before restoring control. No contamination of the drinking water supply has been reported.
It's tempting to read this as a story about internet-facing PLCs. That's part of it, but not the whole picture.
The warning signs that were already there
What makes the incidents particularly hard to write off as bad luck is how well-documented the underlying exposure already was. Following the 2023 compromises of Unitronics PLCs at water utilities—attacks attributed to Iran-affiliated actors—US federal agencies issued repeated advisories warning the water sector specifically about internet-exposed OT assets and insecure remote access. Further guidance followed in 2024.
Just days before the Minnesota attacks, CISA updated advisory AA26-097A, again naming water and wastewater as a target sector and describing the exact categories of exposure that were exploited days later. In other words: this wasn't an unforeseeable event. The playbook had been published, more than once, well in advance. As such, the question isn't 'how did attackers find these systems?' since internet scanning makes that trivial. It's more important to understand why the exposure was still there to find.
Why this keeps happening, despite the warnings
Ask any experienced OT practitioner whether a PLC should be directly reachable from the internet, and the answer is immediate: no. And yet it keeps happening, for reasons that are often organisational rather than technical. Sometimes the person who deployed the connection didn't fully understand the security implications at the time. For example, a 4G router installed for convenience, without much thought given to what else it exposed.
Just as often, the connection was deliberate and justified: it existed for remote maintenance or troubleshooting, agreed with an integrator years earlier. Then, the people involved moved on, the documentation was never updated, and everyone downstream assumed the access had been removed, or was somehow contained. The asset owner believes the controller sits safely inside the OT network. The attacker, scanning the internet for exposed management ports, knows otherwise. This is where the conversation needs to move from 'was this preventable?' to 'how do organisations actually find out what they don't know?'.
The visibility challenge
It's not the technology creating the risk here; it's the absence of governance around it. In the OT security assessments we carry out, an internet-exposed PLC or other OT device is rarely the only surprise, and often not even the most interesting one. We regularly uncover forgotten internet connections that were installed for a project that ended years ago, undocumented maintenance connections left in place by a third-party integrator, VPN tunnels nobody remembered to decommission, and links between IT and OT networks that were never formally mapped or approved. In many cases, the people responsible for the environment genuinely did not know these paths existed. An asset inventory built from documentation looks complete right up until someone goes and physically verifies it.
This is precisely the gap that structured approaches like IEC 62443 are designed to close, not as a compliance exercise, but through the discipline of zone and conduit design. It defines what should be able to talk to what, and treats anything outside the model as something to investigate rather than assume away. For organisations operating in the EU, it's also directly relevant to NIS2. Drinking water and wastewater are both listed among the sectors of high criticality under the directive, which means the risk-management obligations—including asset visibility and supply-chain/remote-access controls—aren't optional extras. They're the baseline the regulation requires.
The recovery gap
Most organisations put the bulk of their time and budget into prevention and comparatively little into recovery. That balance deserves scrutiny after incidents such as those at the US water facilities. Resilience doesn't happen by accident. It requires planning and, critically, rehearsal. If someone altered your controller logic tomorrow, could your operators run the process manually, safely, and for as long as necessary? Could your team rebuild a controller from a known-good, verified project file—not in theory, but because they've actually done it before, under time pressure? Incident response plans read very differently on paper than they do at 03:00 on a Sunday morning, with a plant down and a tower running low.
Recovery training should not be a lesser priority than prevention. In fact, with today’s increased global tensions and AI powered vulnerability research, it may need to be considered even more important than prevention.
What every OT operator can take away from these incidents
The lesson from Minnesota isn't really about a specific vendor, protocol, or even a specific threat actor. It's that you can't secure assets you don't know you have, and you can't recover systems your team has never practised rebuilding. Everything else, including patching, segmentation, monitoring, depends on getting those two things right first.
A few questions worth putting to your own organisation today:
- Do we know, with certainty, which controllers and OT assets are reachable from the internet right now—not according to the network diagram, but according to an actual scan?
- Who has remote access to our OT environment, what is their security maturity, why do they have access, and is that access still needed?
- If a controller's logic was altered today, could we detect it, and could we recover from a clean, verified backup?
- Has anyone on the team actually rehearsed a manual fallback and a controller rebuild, rather than just documented the procedure?
- Can we replace controllers at short notice? Do we have our own stock of spares?
If any of those questions gave you pause, that's worth acting on before it becomes someone else's incident report.
For additional expert recommendations, download our free Global Threat Landscape report 2026, which contains specific advice for OT security.
How Northwave can help
Wondering what forgotten remote access paths, undocumented connections, or exposed assets might still exist in your own OT environment? That's exactly the kind of gap our OT security assessments are built to uncover — starting with our fixed-fee IEC 62443 SL1 Quick Scan for organisations that want a fast, concrete picture of where they stand, through to full gap assessments and NIS2 readiness support for more complex environments. Contact us today to get started.
We are here for you
Need help with your cyber security or wondering how secure your business really is?
Get in touch and we will help you find the best solution.