More than 30 community water systems across Minnesota were targeted in what state officials called a coordinated cyberattack on July 26 and 27.

The public details are still limited. Minnesota IT Services (MNIT) said state and federal partners were responding, assessing affected systems, and helping utilities restore operations. Officials did not ask residents to change their drinking-water use.

At least one community experienced a real operational impact. In Braham, malicious activity shut down operating controls for the well and water treatment plant. Public works employees restored service, and city officials said the incident did not affect water quality or cause physical damage to the facility.

That is enough to take seriously. It is not enough to know exactly how the attackers got in.

What “coordinated” does—and does not—tell us

The word coordinated can make an incident sound like a highly customized campaign against 30 carefully selected targets.

Maybe it was. But there is another common explanation.

When many organizations use similar equipment, software, remote-access tools, vendors, or configurations, one successful technique can be repeated quickly. An attacker does not need to study every water utility individually. Once the attacker finds a useful weakness, internet-scanning services can help identify other systems that look the same.

That weakness could be an exposed management interface, a default or reused password, remote access without multi-factor authentication, an unpatched device, or another shared configuration problem. Federal agencies have repeatedly warned water utilities about each of those conditions.

To be clear, officials have not publicly identified the initial access method in the Minnesota incidents. We do not yet know which weakness was exploited, whether a common vendor or deployment pattern connected the targets, or whether the attackers used Shodan or another internet-scanning service to find them. Shodan is not an attacker; it is a search engine for internet-connected systems that both defenders and criminals can use to identify exposed technology.

But MNIT officials have said the affected organizations used very similar technology and configurations. That makes shared exposure an important possibility. A deployment pattern copied across many locations can also copy the same risk across every location.

This matters because the fix is different from the headline. If the incident was enabled by a repeatable configuration weakness, replacing one password or taking one device offline at one utility will not solve the larger problem. Every similar deployment needs to be found, reviewed, and corrected.

“Sophisticated” is often the wrong question

Cybersecurity reporting tends to focus on who the attacker was and how sophisticated the campaign may have been. Attribution matters to law enforcement and national security, but it is not the first question a utility operator or city leader needs answered.

The more useful questions are:

  • What business or operational process could have been interrupted?
  • Which technology can directly affect that process?
  • How can someone reach that technology?
  • What would stop one compromised account or device from reaching the plant floor?
  • Can the utility continue operating safely if the automation is unavailable?
  • How quickly can the environment be restored to a known-good state?

A capable threat actor will use an easy path when one is available. Internet-exposed industrial equipment, default credentials, weak remote access, and flat networks do not become less dangerous because the attacker behind the keyboard is considered advanced.

The goal is not to win an argument about attacker sophistication. The goal is to remove the simple paths and limit the damage when one control fails.

Water operations should not share the internet’s level of trust

Water utilities depend on both information technology and operational technology.

Information technology includes email, office computers, billing, file storage, and ordinary business systems. Operational technology includes the systems that monitor or control pumps, wells, valves, chemical processes, alarms, and treatment equipment.

Those environments serve different purposes and carry different consequences. A compromised office laptop is a serious problem. A compromised controller that can change a physical process is a different category of risk.

The Purdue Model is a useful starting point for separating those environments. It organizes industrial systems into layers, from enterprise technology at the top to control systems and physical processes below. The practical point is simple: an email account, vendor laptop, or internet-facing service should not have a direct, unrestricted path to the equipment running a plant.

That does not mean every utility can simply unplug everything. Remote monitoring and vendor support may be necessary, especially for small communities with limited staff. But remote access should be an intentional exception with strong controls—not a permanent shortcut added for convenience.

For a water utility, that generally means:

  • Inventory every IT and OT asset, including cellular connections and vendor-managed equipment.
  • Identify every path into the OT environment.
  • Remove direct internet exposure wherever possible.
  • Place firewalls and controlled intermediary systems between business and control networks.
  • Require multi-factor authentication for remote access.
  • Give users and vendors only the access they need, for only as long as they need it.
  • Log and review remote sessions and configuration changes.
  • Maintain offline or otherwise protected backups of critical configurations.
  • Test manual operation and recovery procedures before an emergency.

CISA and the EPA have been direct about these priorities. Their guidance for water systems calls for reducing public internet exposure, changing default passwords, inventorying IT and OT assets, using multi-factor authentication for remote access, segmenting networks, and exercising incident response and recovery plans.

Start with the operation, not the product

Security programs often begin with a product demonstration. Critical infrastructure needs to begin with the mission.

For a water utility, the first step is to identify the processes that must continue: drawing water, treatment, maintaining pressure, monitoring quality, issuing alarms, and supporting safe manual operation. The technology review comes next.

This is how Minnesota Risk & Cybersecurity Advisory would approach the work:

  1. Identify mission-critical processes. Document what must continue, acceptable downtime, safety consequences, and manual alternatives.
  2. Map the full technology stack. Include controllers, human-machine interfaces, SCADA systems, workstations, network equipment, cellular modems, cloud services, vendor connections, and business systems.
  3. Review technical and business controls. Look beyond firewalls and antivirus. Examine ownership, approvals, remote-support practices, account management, contracts, backups, monitoring, and incident authority.
  4. Build a practical mitigation roadmap. Separate urgent exposure reduction from projects that require budgeting, engineering, or scheduled downtime.
  5. Prioritize by likelihood and consequence. Address the paths most likely to be used and the failures capable of causing the greatest operational harm.
  6. Track each risk through validation. A risk is not closed because someone bought a product or checked a box. Confirm that the control works and document whether the risk was reduced, avoided, transferred, or formally accepted.

The first few actions may be unglamorous: disable an unused remote-access service, change a default credential, document a cellular modem, restrict a vendor account, or test whether operators can run a process manually.

That is the point. Good risk reduction is often ordinary work performed consistently.

The larger lesson for Minnesota

The immediate response should focus on restoring affected systems and learning how the attackers gained access. The next phase should examine whether the same exposure exists elsewhere.

If similar technology and configuration connected these incidents, Minnesota does not have 30 isolated security problems. It has a repeatable risk that needs a coordinated defensive response: shared indicators, a common inventory effort, configuration guidance, vendor involvement, and validation across every comparable deployment.

Water systems do not need to be designed like the public internet. Pumps, valves, and treatment controls should operate in a lower and more tightly controlled ring of trust. Where connectivity is necessary, it should be limited, authenticated, monitored, and built so that one compromised account cannot become control of a physical process.

Minnesota Risk & Cybersecurity Advisory can help utilities and other critical-service organizations identify the systems that matter most, find the exposure between IT and OT, and build a mitigation roadmap that fits real operational constraints.

References