Share this
Water Utility Cybersecurity in 2026: EPA and AWWA Tools, and How to Evaluate OT Security
by William Toll on Jul 30, 2026, 9:00:00 AM
Quick answer. Across July 26 and 27, 2026, more than 30 Minnesota community water systems were targeted in a coordinated attack on operational technology. One treatment plant went offline for about two hours. No city on the record issued a boil-water advisory, and no agency has attributed the attacks to any actor.
Updated July 30, 2026
This guide was first published in October 2025 and has been rewritten for 2026. New in this version: coverage of the July 2026 attacks on Minnesota community water systems and the CISA mitigations that followed; a section on AWWA G430, J100, and the Cybersecurity Guidance and Assessment Tool, and how each maps to EPA and CISA obligations; vendor-neutral criteria for evaluating OT segmentation, including a comparison of architectural approaches and a checklist a utility can hand to any vendor; and new answers to the questions water and wastewater teams ask most.
What Happened in the July 2026 Minnesota Water System Attacks?
The scale is the unusual part. More than 30 Minnesota community water systems were targeted across July 26 and 27, 2026, in what state officials describe as a coordinated attack on operational technology, and one treatment plant lost its computerized controls for about two hours. Braham asked its residents to minimize water use while its plant was down. No city on the record issued a boil-water advisory, no other city on the record asked residents to change the amount of drinking water they consume, and no government agency has attributed the attacks to any actor.
Minnesota IT Services (MNIT) disclosed the campaign on July 28, confirming that the state activated its cybersecurity incident response and is coordinating with the Minnesota Fusion Center, the state health and pollution control agencies, CISA, the EPA, the FBI, and the affected utilities. “Cyberattacks against critical infrastructure require a coordinated, whole-of-government response,” said John Israel, MNIT Assistant Commissioner and Minnesota Chief Information Security Officer.
Four cities have described specific impacts. Braham found its computerized operating controls disabled and its treatment plant offline for about two hours on July 27, drawing from the city’s water tower until service was restored, and attributed the outage to a malicious cyberattack by unknown actors. With the tower holding only a limited quantity, Braham asked residents to minimize water use, which it spelled out as not watering lawns and not using water for recreation until the plant was back. Plymouth disconnected cellular-connected equipment at two water towers and several wastewater lift stations to contain the activity and ran operations manually. South St. Paul said it identified a cyberattack on July 27 that affected certain automated controls, and Maple Plain declared a local state of emergency without asking residents to adjust consumption. Beyond Braham’s request to minimize use during its outage, no other city on the record asked residents to change the amount of drinking water they consume, no city on the record issued a boil-water advisory, and the Minnesota Department of Health said it was not aware of any active requests from Minnesota cities for residents to modify their drinking water usage.
The timing matters. Four days before the Minnesota activity began, seven federal agencies including the FBI, CISA, NSA, and EPA updated a joint advisory (AA26-097A) on Iranian-affiliated actors exploiting programmable logic controllers across U.S. critical infrastructure, first issued on April 7, 2026. According to the CISA advisory’s technical details, the actors used the manufacturers’ own configuration software on leased, third-party hosted infrastructure to exfiltrate device project files, then modified and deleted project file logic and manipulated data displayed on HMI and SCADA displays. The advisory states that those changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies. The July 22 update expanded the controller families in scope beyond Rockwell Automation to include Schneider Electric and Siemens.
What is confirmed, and what is not. Confirmed: the scale of more than 30 systems targeted, the July 26 to 27 window, the impacts the four cities described themselves, Braham’s request that residents minimize water use during its outage, and that no city on the record issued a boil-water advisory.
Not confirmed: attribution. Tenable has written that “the operational pattern is consistent with the CyberAv3ngers threat ecosystem” while stating plainly that “Federal and state officials have not publicly attributed the Minnesota attacks to any specific actor.” No official has named an actor or identified a specific controller family, access method, or vulnerability used in Minnesota, and TJ Sayers, senior director of threat intelligence at the Center for Internet Security, has said it is unclear whether the attacks involved the programmable logic controllers the advisory describes. Any account that names a specific exploit for Minnesota is running ahead of the evidence.
What the Minnesota Attacks Reveal About Water System Architecture
No agency has described how the Minnesota systems were reached, so what follows is an argument about architecture rather than a finding about Minnesota. Start with the arithmetic. Reaching more than 30 water systems inside a 48-hour window would not require 30 separate campaigns. A single repeatable path against an architecture that hundreds of small utilities share would be enough, and that shared architecture is the part your utility can act on regardless of what the investigation concludes.
Small and mid-size community water systems converge on a common design. They buy from the same regional integrators, run the same few controller and HMI families, follow the same reference architectures, and inherit the same default configurations. The population is uniform. A technique proven against one plant transfers cleanly to the next town over, which is what makes a wide campaign cheap to run against it.
Geography compounds it. Water is a distributed process by nature: pump stations, lift stations, tank sites, and wells sit miles from the treatment plant, and cellular or radio backhaul is often the only practical link. That link then becomes the perimeter. Plymouth’s containment action is instructive precisely because it was blunt. A city spokesperson told StateScoop that Plymouth’s IT division “disconnected the affected equipment from the network to stop the cyberattack and avoid any potential retargeting while the equipment is reconfigured.” Nobody in Plymouth said it was the only boundary available, and the reading that follows is an inference rather than a finding: where the communications path is the boundary that can be actuated fastest, disconnection reads as the containment tool of first resort. Check whether that describes your own remote sites before an incident forces the question.
Behind that link, flat OT networks remain common. Controllers accept instructions from anything that can route to them, which means reachability functions as authorization. The devices cannot resolve this themselves: legacy PLCs and RTUs frequently cannot authenticate a peer, cannot host security software, and in some cases cannot be patched at all. Add third-party access to the same picture. The integrator who commissioned the SCADA system, the instrumentation contractor who calibrates analyzers, and the pump service crew often serve dozens of utilities in a region with the same tooling and the same support workflows, so a path can cross organizational boundaries even when networks do not.
Be clear about the boundary segmentation does not cross. Reducing what can reach a controller closes the paths an attacker would use to arrive there from somewhere they should not be. It doesn’t stop an attacker who’s already operating from an engineering workstation that is authorized to program that controller, and that is precisely the tradecraft the advisory describes: project files pulled and altered with the manufacturer’s own configuration software. Segmentation narrows the approach. Project-file baselining, change control over who may download logic, independent verification of process state, and the credential and multifactor controls on your remote access path sit alongside it rather than behind it.
Read the July 2026 mitigation guidance against that backdrop and each item turns into an architectural prerequisite. Logging cellular modem connections presumes you have enumerated every cellular-connected asset and know what a normal connection looks like, and restricting controller access to authorized systems presumes “authorized” has been written down somewhere as policy and is enforced somewhere in the path. Inspecting running project files presumes a known-good baseline. Every one of these is an inventory question and a policy question stated as an operational one.
That’s the durable lesson here, independent of who turns out to be responsible. Detection reports what happened; architecture sets what an intruder could reach while it was happening. Nate George, the mayor of Braham, wrote in a post on X the day after the outage that Minnesota’s local governments are “expected to defend essential systems against foreign adversaries and sophisticated criminals, often with limited staff, aging technology and inadequate resources.” For a utility working under those conditions, design decisions are the lever you can still move.
How Do the July 2026 CISA Mitigations Map to Architectural Controls and Standards?
Federal mitigation guidance tends to be written as actions. Utilities have to implement it as architecture, then evidence it to a state primacy agency, an insurer, or a board. We mapped eight items from the July 2026 advisory, seven recommendations drawn from its mitigations section and one technique drawn from its technical details, each to the control that delivers it, the standard a utility can anchor it to, and the artifact that proves it was done. Two cautions before you read it. The advisory’s mitigations section is longer than eight items, so this is a subset rather than the whole. And no single product covers what is here: rows one, four, five, and six are logging, configuration management, and backup disciplines that belong to your operations and engineering teams, and a segmentation platform does not deliver them. Rows two, three, seven, and eight are where network policy and identity-based access control do the work.
| Advisory item (AA26-097A, July 2026) | Architectural control that delivers it | Standards anchor | Evidence a utility can produce |
|---|---|---|---|
| Mitigation: enable and review logs for connected cellular modems | A complete inventory of cellular and radio-connected sites, with connection logging and a baseline of expected telemetry patterns per site | NIST SP 800-82r3 (OT monitoring and logging); CISA Cross-Sector CPGs (log collection); AWIA risk and resilience assessment (asset and dependency inventory) | Site inventory reconciled to billing records for every active SIM; retained connection logs |
| Mitigation: strictly control network access to controllers, allowing only expected control system devices | Per-device policy zones around PLCs, RTUs, and HMIs with an explicit allow list of engineering workstations, historians, and protocols, and a default deny for everything else | ISA/IEC 62443 zone and conduit design; NIST SP 800-82r3 (network segmentation and least privilege); CISA Cross-Sector CPGs (network segmentation) | Exported policy showing which identities may reach each controller, plus a denied-traffic report |
| Mitigation: remove controllers from direct internet exposure via a secure gateway and firewall | Brokered remote access through a hardened gateway, with no controller reachable from a public address and no shared standing credentials for vendors | CISA Cross-Sector CPGs (no exploitable services on the internet); NIST SP 800-82r3 (remote access); ISA/IEC 62443 (conduit control) | External exposure scan of every utility-owned address range, repeated on a schedule |
| Mitigation: review project files running on controllers for unauthorized changes | Version-controlled known-good project files, scheduled comparison of running logic against that baseline, and change control over who may download to a controller | NIST SP 800-82r3 (configuration and change management); ISA/IEC 62443 (integrity of control logic); AWWA G430 (operation and management practices) | Dated comparison report per controller, tied to approved change records |
| Mitigation: verify a backup does not contain malicious logic before restoring from it | Offline, integrity-checked backups of controller logic, HMI projects, and historian data, with restoration tested against a spare or bench controller rather than a live process | AWIA emergency response plan; CISA Cross-Sector CPGs (tested backups); AWWA G440 emergency preparedness practices | Restoration test record with date, asset, and result, retained with the ERP |
| Mitigation: return controllers with a physical mode selector to run position, and validate project files first | A documented recovery sequence in which physical mode position is the last step, gated on a completed logic comparison, and a quarantine path that keeps the controller reachable only by the recovery workstation | AWWA G430 (operation and management practices); ISA/IEC 62443 (recovery of the control system); NIST SP 800-82r3 (incident recovery) | Written recovery runbook, signed off by operations, exercised in a tabletop |
| Mitigation: change device passwords from their default, and implement multifactor authentication for access to the OT network from an external network | Credential hygiene and multifactor authentication on the remote access path itself, with identity-bound reachability for every operator, contractor, and integrator underneath it, scoped to the assets named in the work order and with no shared accounts on the OT side. A segmentation layer does not authenticate anyone; it constrains what an already authenticated session can reach | CISA Cross-Sector CPGs (default passwords, multifactor authentication); NIST SP 800-82r3 (access control); ISA/IEC 62443 (identification and authentication control) | Access review listing every third party with OT reach, the assets in scope, and the expiry date |
| Observed technique, not a mitigation: changes that disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators | Independent verification of process state that does not depend on the same path as the HMI, plus isolation of safety and alarm functions from general control traffic | ISA/IEC 62443 (separation of safety-related functions); NIST SP 800-82r3 (OT safety considerations); AWIA risk and resilience assessment (consequence analysis) | Documented out-of-band check for each critical process value, with an operator procedure for disagreement |
The first column paraphrases CISA advisory AA26-097A rather than quoting it, including the term used for the physical mode selector on a controller, and the final row restates a technique from the advisory’s technical details rather than a recommendation from its mitigations section. Read the advisory itself as the authoritative text. The standards column names the framework a control most naturally anchors to, not a certification claim: NIST SP 800-82 Rev. 3 (September 2023) is the current final edition, and you should confirm the current editions of the CISA Cross-Sector Cybersecurity Performance Goals and the ISA/IEC 62443 series before citing them in a regulatory submission.
Where Water Utility Cybersecurity Stands in 2026
Water infrastructure cybersecurity remains at a critical inflection point in 2026. In October 2024, American Water, the largest regulated water and wastewater utility company in the United States, was forced to shut down its billing systems following a cyberattack that disrupted services for millions of customers. Just months earlier, in January 2024, a water tank in Muleshoe, Texas overflowed after threat actors exploited default passwords to access control systems. These incidents make one point plainly. Water utilities have become prime targets for nation-state adversaries and cybercriminals seeking to disrupt essential services that millions of Americans depend on daily.
Against this backdrop of escalating threats, the Environmental Protection Agency (EPA) released four cybersecurity planning resources in October 2025, designed to help water and wastewater utilities strengthen their defenses, respond to incidents, and maintain operational continuity. For CISOs and security leaders at water utilities, these resources remain the working baseline at a moment when federal mandates, insurance requirements, and board-level scrutiny all demand demonstrable progress toward cyber resilience.
This guide covers the July 2026 attacks on Minnesota water systems and what they reveal about water system architecture, the federal mitigation guidance issued alongside them, the EPA planning resources and the AWWA standards that sit next to them, the regulatory obligations that apply under AWIA and the Safe Drinking Water Act, implementation strategies for utilities working under real budget and staffing constraints, and vendor-neutral criteria for evaluating OT segmentation, including a comparison of architectural approaches, a checklist a utility can hand to any vendor, and answers to the questions water and wastewater teams ask most.
What Are the Top Cyber Threats to Water Infrastructure in 2026?
The cybersecurity challenges facing water utilities extend far beyond isolated incidents. According to research from Claroty’s Team82 State of OT Exposures Report, adversaries are targeting operational technology with greater frequency in the hopes of impacting national security, economic stability, and, in some cases, public safety. The opening in an OT attack is often the inadvertent exposure of a device that is insecurely connected to the internet, including OT assets that are directly connected online rather than through secure access technology.
The Scale of Vulnerability in Water System Cybersecurity
Water systems face a convergence of vulnerabilities that create substantial risk exposure. The Cybersecurity and Infrastructure Security Agency (CISA) released foundational guidance in 2025 titled “Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators” that emphasizes operational technology includes a broad set of technologies covering process automation, instrumentation, cyber-physical operations, and industrial control systems. Many OT systems are increasingly connected to business operations and applications that rely on process data, and if not assembled and integrated securely, these connections introduce paths for cyber actors to move between networks.
The challenge is particularly acute because water utilities typically operate SCADA systems, programmable logic controllers (PLCs), remote terminal units (RTUs), and distributed control systems that were designed to prioritize consistent functionality over cybersecurity. These devices often cannot accommodate security agents, lack modern authentication mechanisms, and run on legacy operating systems that no longer receive security patches. According to research on operational technology security in critical infrastructure, these vulnerabilities continue to increase year over year.
Nation-State Threat Actors Targeting Water Infrastructure
The past three years have brought a documented increase in sophisticated attacks against water infrastructure by well-financed state-sponsored threat actors. China-linked groups including Volt Typhoon and Salt Typhoon have infiltrated U.S. military and critical infrastructure operations. CISA has labeled Volt Typhoon’s activity as disruptive or potentially destructive in the event of a major crisis or conflict with the United States, as documented in their advisory on state-sponsored actors. These groups use native legitimate tools on systems they infiltrate by exploiting weak or default passwords for access.
Russian intelligence-linked groups, particularly Sandworm, have demonstrated capability and willingness to target critical infrastructure. This APT is responsible for several attacks against Ukraine’s power grid and the deployment of Industroyer malware, purpose-built tooling that targets industrial equipment communicating over IEC-104 protocols. Iran-affiliated actors, operating under the watch of the Islamic Revolutionary Guard Corps, have also targeted water facilities. The CyberAv3ngers group targeted Unitronics integrated HMI/PLC devices inside U.S. water facilities in late 2023, as reported in threat intelligence from Claroty and other cybersecurity firms.
How Do Cyberattacks Use Lateral Movement in Water Systems?
The most prevalent attack pattern involves initial compromise through weak authentication, followed by lateral movement across flat networks to reach critical operational systems. Speed is what makes this pattern hard to interrupt. CrowdStrike’s 2026 Global Threat Report, published in February 2026, puts the average eCrime breakout time, the window between initial access and the first lateral move, at 29 minutes. Sophos, in the Active Adversary Report it published in April 2024, found remote desktop protocol abuse in 90% of the incident response cases its team handled in 2023, the highest rate it had recorded since the series began. By the time defenders detect unusual activity, attackers may have already exfiltrated data, deployed ransomware, or established long-term surveillance within the network.
Water utilities face several common vulnerability patterns that enable these attacks. Default passwords and weak authentication mechanisms provide initial access. Internet-exposed HMI and SCADA systems create direct pathways to operational technology. Poor network segmentation means that once an attacker gains a foothold in the IT environment, they can move laterally to OT systems with limited resistance. The absence of comprehensive asset inventories means many utilities lack visibility into what devices exist on their networks, how those devices communicate, and where communications lead.
What Are the EPA Cybersecurity Tools for Water Utilities?
The EPA has developed four interconnected resources that provide water utilities with practical frameworks for incident response, emergency planning, vendor evaluation, and operational continuity. Each resource addresses specific gaps in existing guidance while working together to create a comprehensive cybersecurity program. These resources are available through the EPA’s Water Sector Cybersecurity Program.
Resource 1: Emergency Response Plan Guide for Wastewater Utilities
The updated Emergency Response Plan Guide provides wastewater utilities with a comprehensive framework for developing and maintaining emergency response capabilities. This resource covers strategies, procedures, and considerations for various incident types including cyber incidents, natural disasters, equipment failures, and intentional attacks. The guide emphasizes the critical importance of having documented procedures that enable manual operations when automated systems are compromised.
What distinguishes this updated version is its explicit treatment of cybersecurity incidents as a category requiring specific response protocols. The guide recognizes that cyber incidents may simultaneously affect IT systems, OT systems, and business operations, requiring coordinated response across multiple teams. Implementation requires utilities to identify key personnel, establish communication protocols, define decision-making authorities, and conduct regular exercises to test response capabilities.
Resource 2: How Do Water Utilities Respond to Cyberattacks? The CIRP Template
The Cybersecurity Incident Response Plan (CIRP) template provides a structured framework for developing organization-specific incident response plans. This template is particularly valuable because it helps utilities translate general cybersecurity guidance into specific, actionable procedures tailored to their operational environment. The template covers critical elements including incident detection and analysis, containment strategies, eradication procedures, recovery operations, and post-incident review processes.
Customization is essential. A large regional utility serving millions of customers will require substantially different procedures than a small community water system. The template guides utilities through considering their specific risk profile, available resources, technical environment, and regulatory requirements. Effective implementation requires integration with existing emergency response plans, clear definition of roles and responsibilities, established communication channels, and regular testing through tabletop exercises and simulations.
Resource 3: Incident Action Checklists for Water Utility Emergency Response
The EPA has developed two comprehensive checklists that provide water utilities with step-by-step response procedures for multiple emergency types including wildfires, floods, power outages, and cyber incidents. These checklists translate complex response requirements into sequential, actionable steps that operators can follow during high-stress incident conditions.
The value of these checklists extends beyond their use during actual incidents. Utilities should use these checklists as the foundation for conducting tabletop exercises that test their response capabilities, identify gaps in procedures or resources, and build muscle memory among response teams. Regular exercises using these checklists help ensure that when a real incident occurs, teams can execute established procedures efficiently rather than improvising under pressure.
Resource 4: What Are the Cybersecurity Procurement Best Practices for Water Systems?
This cybersecurity procurement checklist addresses a critical control point that many utilities overlook: vendor and supply chain security. Every new device, software system, or service introduces potential vulnerabilities into the operational environment. The procurement process provides an opportunity to establish security requirements before solutions are selected and deployed.
The checklist guides utilities through assessing vendor cybersecurity practices, evaluating product security features, understanding support and patching procedures, and managing supply chain risks. Key questions include: Does the vendor follow secure development practices? How quickly does the vendor release security patches? What authentication mechanisms does the product support? Can the product integrate with existing security monitoring tools? Does the vendor maintain an incident response capability?
Implementing effective procurement controls requires collaboration between IT, OT, procurement, legal, and operational teams. The goal is not to create bureaucratic barriers but rather to ensure that security considerations inform purchasing decisions before investments are made.
Understanding Your Obligations: What Are AWIA Cybersecurity Requirements for Water Systems?
Water utilities operate under a complex regulatory framework that mandates specific cybersecurity and emergency preparedness activities. Understanding these requirements is essential for building compliance-driven business cases for security investments.
America’s Water Infrastructure Act (AWIA) Requirements
The America’s Water Infrastructure Act of 2018 includes Section 2013, which requires community water systems serving more than 3,300 people to develop or update Risk and Resilience Assessments (RRAs) and Emergency Response Plans (ERPs). These requirements explicitly include cybersecurity considerations, recognizing that cyber threats pose material risks to water infrastructure resilience.
The timing requirements are based on system size. Systems serving more than 100,000 people were required to complete RRAs by March 2020 and certify ERPs by September 2020. Smaller systems have later deadlines extending through 2021 for the smallest covered systems. The EPA has enforcement authority to compel compliance and can impose administrative penalties for failures to meet requirements.
Safe Drinking Water Act Section 1433 Mandates
Section 1433 of the Safe Drinking Water Act requires community water systems to conduct vulnerability assessments and develop emergency response plans. While originally focused on physical security following 9/11, the statute’s broad language regarding “malevolent acts” clearly encompasses cyber incidents. Regulatory interpretations and EPA guidance increasingly emphasize that water systems must address cyber vulnerabilities as part of their Section 1433 obligations.
Importantly, federal law provides protections for vulnerability assessment information that utilities submit to EPA, recognizing the sensitivity of detailed security information. These protections should give utilities confidence to be transparent about vulnerabilities when seeking federal assistance while maintaining appropriate information security.
CISA Cybersecurity Performance Goals and Guidance
While not legally binding, CISA’s Cybersecurity Performance Goals (CPGs) provide practical guidance that many utilities use as a roadmap for improving security maturity. These goals emphasize fundamentals including asset inventory, vulnerability management, network segmentation, and incident response capabilities. CISA also provides free cyber hygiene services that utilities can use to identify gaps and prioritize improvements.
The relationship between EPA and CISA is collaborative rather than duplicative. EPA maintains regulatory authority over water sector compliance, while CISA provides technical cybersecurity expertise, threat intelligence, and operational support. Utilities benefit from engaging with both agencies to access the full range of available federal resources.
What Do AWWA Standards Require, and How Do They Relate to EPA and CISA Guidance?
The American Water Works Association (AWWA) publishes the water sector’s own security standards and the assessment tool most utilities use to satisfy the cybersecurity portion of an AWIA risk and resilience assessment. EPA sets the legal obligation, CISA supplies cross-sector goals and threat guidance, and AWWA translates both into water-specific practice. Most utilities need all three.
What Is the AWWA Cybersecurity Guidance and Assessment Tool?
The AWWA Cybersecurity Guidance and Assessment Tool is a questionnaire-driven instrument that asks which technologies and use cases a utility actually operates (SCADA, remote telemetry, vendor remote access, cloud-hosted historians) and returns a prioritized list of recommended controls mapped to the NIST Cybersecurity Framework. AWWA positions it as a voluntary route to fulfilling the cybersecurity provision in AWIA Section 2013.
What it produces is a prioritized control list, an implementation-status view, and a report. What it does not produce is an asset inventory, a network diagram, or evidence that a control is operating in production, because the status it records is self-attested. That’s the gap. Establishing what is actually true in production falls to instrumentation and enforcement, and that work sits between a completed assessment and a defensible posture.
What Are AWWA G430 and G440?
AWWA G430, Security Practices for Operation and Management, is the standard that asks whether a utility runs a security program at all: leadership commitment, defined roles, resourcing, physical and cyber practice, contractor and visitor control, and periodic review. It is a management-system standard. It does not catalog technical controls, which is why it pairs with the recovery, change-control, and third-party access rows in the table above. AWWA G440, Emergency Preparedness Practices, covers the response side and sits alongside the emergency response plan an AWIA-covered system must certify to the EPA.
What Is AWWA J100 (RAMCAP) and When Do You Use It?
AWWA J100, Risk and Resilience Management of Water and Wastewater Systems, is the RAMCAP methodology many utilities use as the analytical engine behind their AWIA assessment. It works in threat-asset pairs, scoring consequence, vulnerability, threat likelihood, and resilience for each pair. The cyber pair is where utilities stall. The construction that works: the asset is the process the control system commands (chemical feed, distribution pressure, lift station operation), and the score is the consequence of that process being manipulated or halted. Scoring the controller as an object is where the pairing usually breaks down.
Where WaterISAC Fits
WaterISAC’s 12 Cybersecurity Fundamentals for Water and Wastewater Utilities is the sector’s operational checklist. Network segmentation and controlled remote access sit among its recommendations. WaterISAC also fills a gap the standards documents structurally cannot. It distributes sector-specific advisories as events unfold, which is how many utilities received the July 2026 controller-targeting update in the days before the Minnesota incidents.
Evaluating vendors? That section now has its own page. The approach comparison, the fourteen questions to ask any OT segmentation vendor, and the proof of value protocol used to sit here. They have moved to Water Utility OT Segmentation: How to Evaluate Vendors, which carries all of it: seven approaches compared side by side with the licensing model and infrastructure prerequisites named for each, fourteen questions written so a procurement officer can send them to every vendor unchanged, and a staged proof of value with acceptance criteria and an honest account of the utility-side staff time it takes. The disclosure travels with it. Elisity sells one of the seven approaches, and that row states its own limitations in the same language as the rest.
How Can Small Water Utilities Improve Cybersecurity on Limited Budgets?
Having comprehensive policies and templates provides necessary foundation, but translating guidance into operational reality requires addressing technology, processes, people, and budget constraints that water utilities face. This section examines practical implementation strategies across these dimensions.
Conducting Comprehensive Cybersecurity Assessments
Effective cybersecurity programs begin with understanding current state. Utilities should use the free assessment programs available through EPA’s Water Sector Cybersecurity Program Case Studies and CISA before making significant technology investments. These assessments provide external validation of vulnerabilities and help prioritize remediation efforts based on risk rather than arbitrary criteria.
Internal assessments are equally important. Following CISA’s guidance, utilities should create comprehensive inventories of all operational technology assets including SCADA systems, PLCs, RTUs, HMIs, network devices, and monitoring systems. For each asset, document its function, criticality, communication patterns, security posture, and dependencies on other systems.
CISA’s Foundations for OT Cybersecurity offers illustrative criticality examples for water and wastewater systems, and states plainly that they “are not authoritative taxonomies for these sectors.” Its appendix groups high-criticality examples such as SCADA systems, emergency shutdown systems, and primary treatment systems; medium-criticality examples including remote terminal units, programmable logic controllers, and what CISA’s own table lists as “Network switches”; and low-criticality examples such as HMIs for non-critical processes and ambient sensors. Treated as examples rather than as a classification standard, this framing helps a utility decide where to focus security investments and monitoring resources for maximum risk reduction.
What Is the Difference Between OT and IT Security in Water Treatment?
Understanding the distinction between operational technology (OT) and information technology (IT) security is fundamental to effective water utility cybersecurity. OT systems control physical processes: pumps, valves, chemical treatment, and water quality monitoring. These systems prioritize availability and safety over all other considerations. A SCADA system that goes offline can mean communities lose access to safe drinking water.
IT systems, by contrast, manage data and business processes: billing, customer service, human resources, and administrative functions. While important, IT system outages rarely create immediate public safety risks. This fundamental difference means that security approaches developed for IT environments often fail when applied directly to OT environments without modification.
Network segmentation represents one of the most effective controls for protecting OT systems while allowing necessary IT/OT integration. The NIST Special Publication 800-207 Zero Trust Architecture provides a framework for implementing identity-based security controls that continuously verify users and devices before granting access to resources. According to NIST, Zero Trust is defined as “a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.”
How to Implement Network Segmentation in Water Systems
The CISA Zero Trust Maturity Model provides a structured framework for organizations to implement Zero Trust principles across five core pillars: Identity, Devices, Networks, Applications and Workloads, and Data. These pillars are supported by three cross-cutting capabilities: Visibility and Analytics, Automation and Orchestration, and Governance. Organizations progress through maturity stages from Traditional to Initial, Advanced, and Optimal, with each stage requiring greater levels of protection and dynamic policy enforcement.
For water utilities, effective network segmentation requires separating IT networks from OT networks, creating security zones within OT environments based on criticality and function, implementing strict access controls between zones, and monitoring all inter-zone communications for anomalous behavior. The key principle is defense in depth, multiple layers of controls that require attackers to overcome numerous obstacles rather than a single perimeter.
Traditional segmentation using VLANs and firewalls creates broad security zones, but modern threats require more granular controls that can enforce least-privilege access policies at the device level. This is where microsegmentation becomes valuable. Modern microsegmentation approaches enable utilities to create dynamic, identity-based policies that follow devices regardless of their network location, a capability particularly important for water utilities with distributed infrastructure across wide geographic areas.
Real-World Implementation: Case Studies in Water Utility Microsegmentation
Two anonymized water utility deployments, carried out between 2024 and 2025 and described here with identifying details removed, show how water utilities implement modern network segmentation to meet compliance requirements and improve security posture.
Southwestern City Water Utility: Rapid Compliance Achievement
A water utility in the southwestern United States faced urgent federal cybersecurity mandates in 2024 including EPA Safe Drinking Water Act Section 1433 requirements for water services to strengthen security and implement network segmentation. The utility’s network was largely a flat Layer-2 environment with minimal internal segmentation, posing risks of unrestricted lateral movement especially given the mix of IT and operational technology devices (many legacy or unpatched) on the network.
In late 2024, the utility deployed a cloud-managed microsegmentation platform (Elisity) across five city sites including on-premises data center, offices, and water treatment facilities. The solution was layered onto the utility’s existing network infrastructure requiring no new hardware or major reconfigurations, a key requirement for rapid time to value. Virtual edge nodes were installed on the infrastructure the utility already ran, including its hypervisors, establishing a cloud-managed policy enforcement plane without changing how that infrastructure forwards traffic.
Within days of deployment, automated device discovery and classification identified approximately 1,883 devices across the utility’s network spanning IT, IoT, and OT assets. The platform categorized devices into dynamic policy groups including 256 physical security systems (surveillance cameras, door badge controllers), 129 network printers, 62 industrial automation devices (SCADA/PLC equipment in water plants), and 51 collaboration/VoIP devices. Integration with Active Directory and endpoint security tools provided additional context to identify verified assets versus unverified or potentially rogue devices.
By early 2025, the utility rolled out microsegmentation across all sites with granular zero-trust zones enforcing least-privilege access and eliminating the broad trust implicit in the old flat network. The Elisity platform’s simulation mode allowed the team to review and refine policies before enforcement, catching anomalous device communications that would have caused operational issues. Once policies were validated, the utility activated them globally, restricting lateral movement such that even if one device is compromised, it cannot freely access others. This transformation was achieved without new VLANs or manual ACL management, dramatically improving real-time visibility and control over every connected device while meeting federal water infrastructure cybersecurity guidelines.
Mid-Atlantic Regional Water District: Comprehensive OT/IT Segmentation
One of the largest water, wastewater, and sanitation districts in the mid-Atlantic region operates multiple treatment plants, pump stations, labs, and offices across a wide geographic area. The district’s mission-critical infrastructure includes industrial control systems at over 100 pump stations and 9 major plants, as well as traditional IT networks for corporate and plant operations.
Prior to implementing modern microsegmentation, the district relied on legacy network access control for authentication but lacked flexible segmentation, and internal networks still permitted too much lateral movement between IT and OT assets. The organization also uses endpoint detection and response, vulnerability management, and anomaly detection tools to monitor threats, but needed a way to enforce least-privilege access based on intelligence from these systems.
In 2025, the district’s leadership sought to enhance network security and visibility by implementing zero-trust segmentation across the enterprise with goals including gaining real-time traffic awareness of all devices, preventing malware spread by reducing lateral movement, and managing the full range of IoT and OT devices under a unified policy framework. This had to be achieved without extensive network downtime, using the infrastructure the utility already ran for enforcement.
A proof-of-value pilot at one operations center discovered approximately 885 devices within a short period, ranging from office IT devices to plant control systems. By integrating with Active Directory and endpoint security tools, the platform immediately correlated many assets with existing identities. About 336 devices matched entries in directory services and 517 had security agents installed. The remaining devices were identified via network discovery, including previously unknown or unmanaged endpoints. This rapid inventory highlighted gaps in the district’s visibility: passive network monitoring had seen up to 4,000 active IP addresses, but the utility had estimated roughly 1,800 wired and 239 wireless devices in their environment.
Following the successful pilot, the district moved forward with full deployment in Q4 2025. The deployment architecture uses virtual edge nodes on virtualization platforms and existing network infrastructure, all managed via cloud control. The solution integrates with the district’s security stack: Active Directory for user and device context, endpoint security for device health status, and planned integration with vulnerability management for risk profiles, enabling policies that consider device risk. The cloud-based policy engine segments the district’s network by creating logical groups for IT devices, OT/SCADA equipment, IoT devices, and unverified devices, each with tailored access rules.
The pilot was scoped to reach full segmentation at the operations center, with policies deployed first in learning and simulation mode to map normal communication patterns. That baseline informs fine-grained allow lists that permit only the flows the process actually needs. The design for the wider rollout covers 13 or more facilities and 130 or more remote pump stations, and it separates them the way any honest remote-site plan has to. Enforcement happens on managed network infrastructure. A remote site whose controller sits behind an unmanaged device or plugs straight into a modem is classified as visibility-only: it gets discovery and visibility, and its policy is enforced at the nearest capable hop upstream rather than at the site itself. Enforce-capable sites take the same centrally authored policy set as the plants. The design intent is to ring-fence critical OT systems, constraining what a compromised device or an unauthorized session from the IT side can reach, while enforcing a least-privilege model for user and device access. Any utility evaluating this pattern should ask a vendor to walk its own remote site list and mark which sites the vendor enforces at and which it can only observe.
Both deployments demonstrate key principles of modern microsegmentation for critical infrastructure: rapid deployment without infrastructure replacement, automated discovery and classification of all devices, integration with existing security tools, and policy enforcement that stops lateral movement without impacting operations.
Overcoming Budget and Resource Constraints
Many water utilities, particularly smaller community systems, face significant budget and staffing constraints that can seem to preclude major security investments. However, substantial security improvements are achievable even with limited resources through a combination of low-cost technical controls, process improvements, and free federal assistance.
Low-cost and no-cost security improvements should be the first priority. Eliminating default passwords and implementing strong authentication policies costs nothing but staff time. Disconnecting unnecessary internet-facing systems immediately reduces attack surface. Conducting regular vulnerability scans using free tools like CISA’s cyber hygiene services identifies critical exposures. Implementing foundational network segmentation using existing VLAN capabilities on the infrastructure already in place provides substantial risk reduction without new hardware purchases.
Free federal resources significantly extend limited budgets. EPA provides free vulnerability scanning and assessment services through its Water Sector Cybersecurity Program. CISA offers free services including vulnerability scanning, web application scanning, and access to cybersecurity professionals. Both agencies also provide free training, guidance documents, and templates that utilities can use to build security programs without expensive consultants.
Grant opportunities can fund larger security initiatives. The EPA’s Water Infrastructure Finance and Innovation Act (WIFIA) program includes cybersecurity projects as eligible uses. State revolving funds administered by state agencies increasingly recognize cybersecurity as eligible for low-interest financing. The Infrastructure Investment and Jobs Act includes substantial funding for water infrastructure improvements, with cybersecurity explicitly recognized as a fundable category.
Managed service providers offer an alternative staffing model that allows utilities to access specialized expertise without hiring full-time security staff. MSPs can provide 24/7 monitoring, incident response, vulnerability management, and compliance reporting at costs significantly lower than building internal capabilities. When evaluating MSPs, utilities should prioritize providers with demonstrated experience in OT environments and understanding of water utility operations.
Building Incident Response Capabilities: From Planning to Execution
Having comprehensive incident response plans provides limited value unless organizations build actual capabilities to detect, contain, and recover from incidents. Effective incident response requires people, processes, technology, and regular practice.
Establishing Incident Response Teams and Roles
Incident response requires coordination across multiple stakeholders with different areas of expertise. At minimum, water utilities should establish an incident response team that includes representatives from IT, OT/SCADA operations, facility operations, executive leadership, legal, communications, and external support including law enforcement and regulatory agencies.
Each team member requires clear definition of their role and decision-making authority. Who has authority to take systems offline during an incident? Who communicates with regulators? Who makes decisions about whether to pay ransom? Ambiguity during a crisis leads to delays and confusion, so these questions must be resolved during planning rather than during response.
Regular training ensures team members understand their roles and can execute procedures effectively. This training should include both technical skills (e.g., how to collect forensic evidence, how to restore from backups) and non-technical skills (e.g., how to communicate during crisis, how to make decisions under pressure with incomplete information).
Conducting Cybersecurity Tabletop Exercises
Tabletop exercises provide safe, low-cost opportunities to test incident response procedures, identify gaps, and build team cohesion. The EPA’s incident action checklists provide excellent scenarios for tabletop exercises. Effective exercises should be scenario-based, time-bound, and focused on specific learning objectives.
A good exercise scenario for water utilities might involve: “At 2 AM on Saturday, your SCADA system begins showing erratic readings. Your on-call operator logs in remotely and discovers ransomware has encrypted several critical systems. What are your first three actions? Who do you call? How do you verify water safety? When do you notify customers?” Working through this scenario reveals whether procedures are clear, whether contact information is current, whether communication templates are ready, and whether teams understand their roles.
Exercises should occur at least quarterly with varying scenarios that test different aspects of response capabilities. Following each exercise, conduct an after-action review that documents lessons learned, identifies procedure gaps, and assigns remediation tasks. Track these action items to completion before the next exercise. Best practices for tabletop exercises emphasize realistic scenarios tailored to the organization’s specific threat profile.
Developing Manual Operation Procedures as Backup
One of the most critical but often overlooked aspects of cyber resilience is the ability to operate essential functions manually when automated systems are compromised. For water utilities, this means having documented procedures that operators can follow to maintain safe water production and distribution even when SCADA systems are offline.
Manual operation procedures should document normal operating parameters, safety thresholds, manual override procedures, and decision criteria for operators. These procedures must be kept current, easily accessible (in physical binders, not just electronic documents), and practiced regularly. Operators who have never performed manual operations will struggle to do so effectively during a crisis when stress levels are high and information is incomplete.
The Strategic Imperative: Water Cybersecurity as National Security Priority
The cybersecurity of water infrastructure extends far beyond individual utilities to represent a strategic national security concern. Water disruptions create cascading effects across communities, economies, and public health that nation-state adversaries understand and have sought to exploit during periods of geopolitical tension.
Water represents a strategic national asset that underpins virtually all economic and social activity. CISA designates the ability to supply water and manage wastewater as a National Critical Function, meaning a function so vital to the United States that its “disruption, corruption, or dysfunction would have a debilitating effect on security, national economic security, national public health or safety, or any combination thereof.” Water infrastructure also connects to broader critical infrastructure including energy, healthcare, and communications sectors, meaning attacks on water systems could have ripple effects across multiple sectors.
Geopolitical tensions drive increased cyber warfare implications. As documented in threat intelligence reporting from firms like Palo Alto Networks Unit 42, China, Russia, and Iran have all demonstrated capability and willingness to target U.S. critical infrastructure including water systems. These activities represent pre-positioning for potential future conflicts, reconnaissance of vulnerabilities, and attempts to establish persistent access. Water utilities should plan on the assumption that access of this kind can be exercised, not only observed.
Federal coordination has intensified in response to these threats. Multiple White House executive orders have strengthened cybersecurity requirements for critical infrastructure. The 2021 Executive Order 14028 laid the foundation for improved cybersecurity including mandatory incident reporting, supply chain security, and zero trust architecture adoption. CISA’s expanded role includes providing threat intelligence, technical assistance, and coordinated response capabilities for water sector cybersecurity incidents.
Frequently Asked Questions About Water Utility Cybersecurity
What are the most common vulnerabilities in water treatment SCADA systems?
The most common are internet-exposed HMI and remote access interfaces, default or shared credentials on controllers, unpatched legacy operating systems, and flat networks that let an intruder move from a billing workstation to a treatment controller. The July 2026 attacks on more than 30 Minnesota community water systems put this class of exposure back under scrutiny. Officials have not publicly identified the access method used.
These four categories keep appearing because of how water systems are built and funded. Control equipment is specified for a 20-year service life and then kept in production longer. Remote sites are commissioned by integrators who need reachback. The reachback path outlives the project. Addressing all four turns on visibility into what is actually connected and a policy layer that constrains what each device can reach.
How do water utilities detect cyberattacks on operational technology?
Water utilities detect OT attacks by watching for what does not belong. That means unexpected communication between devices that never talk, remote sessions outside maintenance windows, configuration or logic changes on controllers, and process values that drift without an operator action. Passive network monitoring paired with SCADA and directory logging into a SIEM gives the correlation that any single tool misses.
Detection in OT differs from detection in IT in one important way. In a business network an anomaly is usually a data event. In a treatment plant it is often a physical one, visible first to an operator looking at a trend line before any security tool registers it. That operator is a detection channel. Programs that work treat it as one and give operators a defined path to escalate.
What is the difference between a water system incident response plan and an emergency response plan?
A cybersecurity incident response plan is the technical playbook for detecting, containing, eradicating, and recovering from a cyber event. An Emergency Response Plan is the broader document AWIA requires, covering natural disasters, contamination, equipment failure, and cyber incidents together, and the EPA Cybersecurity Incident Response Plan template is built to sit inside that ERP as its cyber annex.
In practice the failure mode is having both documents and no connection between them. Two plans, two owners. An incident response plan says to isolate an affected segment; the emergency response plan says who has authority to move the plant to manual operation. If those two decisions are made by different people reading different documents at 2 a.m., the utility loses time it does not have.
How can water utilities implement Zero Trust architecture with limited budgets?
Start with the controls that cost time rather than capital: a complete asset inventory, removal of default and shared credentials, multi-factor authentication on every remote access path, foundational segmentation using VLAN capability the utility already licenses, and free CISA vulnerability scanning. Identity-based policy can then be layered onto the infrastructure already in place instead of a network rebuild.
Funding is a real constraint. There are real routes through it. State revolving fund cybersecurity set-asides, WIFIA financing, and technical assistance from state drinking water administrators and rural water associations all exist for this purpose. Cyber insurance underwriters have also begun asking water systems specific questions about segmentation and multi-factor authentication, which means the same work that reduces risk can also affect premium and coverage terms.
What cybersecurity requirements does AWIA mandate for water systems?
According to the EPA, AWIA requires community water systems serving more than 3,300 people to complete a Risk and Resilience Assessment that explicitly evaluates cybersecurity, and to prepare or update an Emergency Response Plan addressing the threats that assessment identifies. Both must be certified to the agency and reviewed and recertified at least once every five years, and the agency holds the enforcement authority.
AWIA stops short of prescribing controls. It requires that you assess, plan, and certify, and it leaves the choice of technology to the utility. That is why the sector leans on AWWA instruments and CISA cross-sector goals to translate the obligation into practice, and why two utilities of identical size can both be compliant with very different security postures.
How does microsegmentation prevent ransomware spread in water utilities?
Ransomware needs lateral paths after initial access. Microsegmentation removes them by placing each device in a policy group that may reach only the systems it needs, so an infected billing workstation cannot scan or encrypt treatment assets. The intrusion still happens, but the blast radius stops at one device instead of crossing the whole flat network.
This is why segmentation appears in nearly every water-sector guidance document as a compensating control. It does not depend on knowing the malware, patching the target, or detecting the intrusion in time. It changes what is reachable, which is a standing property of the network. The boundary matters here as well. Reducing reachability does not stop an attacker already operating from a host that is authorized to reach the target, which is why backup, tested recovery, and change control sit alongside segmentation instead of behind it.
How do you protect PLCs and SCADA systems that cannot be patched?
Use compensating controls. Put each controller in its own policy zone, allow only the specific engineering workstations, historians, and protocols it actually needs, and deny everything else. The vulnerability stays, and the paths an attacker would use to reach that controller from elsewhere on the network are closed. This is the standard answer for devices that cannot be patched.
Some controllers in service at water utilities have no vendor patch available at all, and some have one that cannot be applied without a plant outage the utility cannot schedule. Treating those two situations identically is the correct instinct: assume the vulnerability is permanent, then reduce reachability and add monitoring for configuration and logic changes on the device. Be clear about the boundary. Reducing reachability closes the paths an attacker would use to arrive at a controller from somewhere they should not be. It doesn’t stop an attacker who has already taken over an engineering workstation that is authorized to program that controller. That case is why project-file baselining, change control on who may download logic, and independent verification of process state sit alongside segmentation rather than behind it.
How do you secure contractor devices and vendor remote access at a water utility?
Treat every contractor device as untrusted. Scope what it can reach to one asset group and one protocol set. SCADA integrators, instrumentation technicians, chemical feed vendors, and pump service crews rarely need anything beyond the equipment they service. Keep the brokered remote access path, the credential hygiene, and the multifactor requirement in place, and add a policy layer underneath so that even a valid session lands on a device that can only reach its own equipment.
Third-party access is a recurring initial-access path into industrial environments, and water utilities carry more of it than most sectors because so much specialist work is outsourced. The failure is almost never exotic. It’s a standing VPN account created for a 2019 commissioning project that nobody closed, on a laptop the utility has never inspected.
How do you secure an OT environment without taking it offline?
Water treatment cannot pause for a security project, so the sequence that avoids downtime is observe, model, then enforce. Inventory and classify every device without interrogating it, watch real traffic across a full operational cycle to learn what normal looks like, model the proposed policy against that traffic, and enforce only once the model shows no legitimate flow is blocked. Any architecture can be run in that order, and a vendor that cannot show you each step in its own product is asking you to skip one.
What causes outages is rarely the enforcement itself. It is the work some approaches require first. Re-IP and VLAN redesign break production because process traffic depends on addresses that controllers expect and that integrators hard-coded years ago, so subnet-based segmentation is normally staged plant by plant inside outage windows. Approaches that bind policy to something other than the address, whether that is a host agent filtering at the operating system or a network policy bound to device identity, leave addressing untouched and can advance in stages instead of a single cutover. Admission-based approaches carry a different risk, since qualifying a fragile controller at the moment it connects is itself the event that knocks it offline.
How do you prove segmentation will work before enforcing it in production?
Run the policy in simulation against live traffic first. Simulation applies the proposed rules to real observed flows and reports what would have been blocked without blocking anything, so you review that list line by line with operations, correct the false positives, and enforce only when the simulated deny list contains nothing a treatment or distribution process depends on.
The review meeting matters as much as the tooling. Operations staff know that the analyzer at the north plant polls a server nobody documented, and that a vendor laptop reaches a controller once a quarter during calibration. Ask each vendor how simulation works in its own architecture, because the coverage differs: a host-based product simulates only on hosts that can run its agent, a network or identity-based product simulates across everything it observes but inherits whatever its classification got wrong, and an admission control system has no equivalent of a dry run at all. None of them removes the need for the line-by-line review with operations.
How do you discover every device on a water utility network?
Start from the traffic the network already carries. Active scanning can crash legacy controllers, so most water utilities combine passive flow observation with industrial protocol decoding, then correlate what they see against directory, endpoint, and asset management records. Utilities routinely find a different device population than their records describe, including cameras, printers, badge readers, and automation controllers nobody inventoried.
Discovery is a separate capability from enforcement, and it is worth buying deliberately, because different tools see different things. A protocol-decoding sensor identifies a controller by how it speaks Modbus TCP or DNP3. An admission control system sees a device at the moment it connects and not afterward. A host agent sees only machines that can run one. A directory knows about accounts, not about the analyzer nobody registered. Expect the gap between the asset register and reality to be large and to run in both directions: devices appear that were never recorded, and devices in the register turn out to have been decommissioned years ago while their firewall rules remain. Reconciling that gap is the real first deliverable of any segmentation program, well before any policy is written.
Can a water utility achieve zero trust without replacing its network?
Yes. Zero trust is a policy model, not a hardware purchase. The enforcement point can sit on the host, on the network infrastructure the utility already operates, on a firewall already in the path, or on new inline hardware, and a utility can reach a comparable policy outcome by more than one of those routes. Which route is cheapest depends on what the utility already owns and on what its assets are able to run.
According to NIST SP 800-207, zero trust is a set of principles for per-request authorization, and the CISA Zero Trust Maturity Model lays out a staged progression toward them. Neither document defines a product category and neither names an enforcement point, so a vendor presenting its own architecture as the zero trust architecture is adding something the source material does not say. Ask instead which principle each product implements, and where. We have written our own reading of that question for this sector in zero trust for water utilities.
How do you segment a municipal network that includes city hall, public works, and the water plant?
Municipal segmentation has to cover one shared network carrying city hall, police, public works, and the treatment plant, plus dozens of remote pump and lift stations. Two structures are available. Rule sets authored and maintained at each site are cheap to start and expensive to keep consistent. Policy authored centrally and distributed costs more up front and holds its shape as the estate changes. Either way the requirement is the same: a compromised office endpoint cannot reach treatment controls.
This is the structural problem that distinguishes municipal water from private utility or industrial environments. The water system is a tenant on a converged network it does not own, sharing infrastructure with departments that have entirely different risk profiles and their own IT priorities. Walk the site list before any vendor promises to cover it. A remote site sitting behind unmanaged equipment or plugged straight into a modem is a site that most architectures can observe and few can enforce at, and the accurate answer for those sites is enforcement at the nearest capable hop upstream rather than at the site itself.
How do you isolate a compromised industrial system quickly?
Pre-build the isolation action before you need it, and decide in advance which mechanism you will use: an access control list or port shutdown on the local network equipment, a quarantine group in a segmentation product, a host rule pushed by an agent, or a technician pulling the uplink. In water operations the action must be reversible and reviewable. Isolating the wrong controller has physical consequences for treatment or distribution.
Whether isolation should be automatic or reviewed is a decision the utility has to make deliberately, whichever mechanism it lands on. Do it per asset class. Automatic quarantine is appropriate for a camera or a badge reader. For a controller on a chemical feed loop it is not, and the right design is an alert plus a one-click action that a named person takes with the operator on the line.
Was the July 2026 Minnesota water utility cyberattack attributed to Iran?
No. As of late July 2026, no federal or state authority has attributed the Minnesota incident to a named actor. MNIT confirmed that more than 30 community water systems were targeted on July 26 and 27, 2026. The Minnesota Department of Health said it was not aware of any active requests from Minnesota cities for residents to modify their drinking water usage, and no city on the record issued a boil-water advisory.
The distinction matters, because attribution language spreads faster than attribution evidence. Researchers have described the pattern as consistent with known Iran-linked activity, which is not the same as attribution. MNIT activated a statewide response with the Minnesota Department of Public Safety, the Minnesota Department of Health, the Minnesota Pollution Control Agency, CISA, EPA, and the FBI. The investigation is ongoing, the impact varied by system, and the operational lesson does not depend on who was responsible.
Your Action Plan: Practical Steps for Immediate Implementation
Understanding the threat picture, regulatory requirements, and available resources is valuable only when translated into concrete action. This section provides a phased approach that water utility leadership can implement starting today.
Immediate Actions (Week 1)
Download all four EPA resources from the EPA Water Sector Cybersecurity Program and distribute them to relevant stakeholders including IT, OT, operations, and leadership teams. Ensure these resources are reviewed and understood as the foundation for subsequent planning.
Conduct an inventory of internet-facing systems to understand attack surface exposure. Use tools like Shodan or free CISA vulnerability scanning services to identify what systems are publicly accessible. Document findings and develop a plan to eliminate unnecessary internet exposure.
Review current password policies and immediately remediate any use of default passwords on critical systems. Default passwords represent the single most common initial access vector in water utility compromises according to CISA threat analysis. Changing these costs nothing but reduces risk dramatically.
Identify a cybersecurity point person who will coordinate security improvements across the organization. This role requires someone with sufficient authority to convene stakeholders, allocate resources, and drive accountability. For smaller utilities without dedicated security staff, this might be the IT manager, operations director, or even a general manager who delegates technical execution while maintaining overall responsibility.
Short-Term Actions (Weeks 2-4)
Schedule a free EPA or CISA assessment to get external validation of vulnerabilities and prioritize remediation efforts. These assessments typically take 1-2 days on-site and provide detailed findings with specific recommendations. The assessments are confidential and non-regulatory, meaning findings cannot be used for enforcement actions.
Begin CIRP template customization to develop an organization-specific water utility incident response plan. Start with the EPA template and modify it based on your organizational structure, technical environment, and available resources. This does not need to be perfect initially. A working plan that can be refined beats a delayed one.
Conduct your first tabletop exercise using the EPA incident action checklists as a scenario. Keep the first exercise simple and focused on core procedures rather than complex scenarios. The goal is to build familiarity with the exercise format and begin identifying procedural gaps.
Review vendor cybersecurity practices using the EPA procurement checklist. For existing critical vendors, conduct assessments to understand their security posture. For new procurements, integrate security requirements into RFP processes and vendor selection criteria.
Long-Term Strategic Planning (Beyond the First 90 Days)
Develop a 5-year cybersecurity roadmap that aligns with your utility’s strategic plan, budget cycles, and capital improvement programs. This roadmap should identify specific milestones for maturity improvements, technology investments, staffing needs, and compliance requirements. Share this roadmap with leadership, boards, and relevant oversight bodies to build consensus and secure necessary resources. Consider using the CISA Zero Trust Maturity Model as a framework for assessing current state and planning progression.
Budget allocation for security improvements should reflect realistic assessment of needs and available resources. While major technology investments may require multi-year planning, incremental improvements can begin immediately. Consider both operating expense (staff, training, services) and capital expense (infrastructure, tools) needs. Many utilities find that dedicating 3-5% of IT budget to security initiatives provides sufficient resources for meaningful progress while remaining achievable within existing budget constraints.
Staff training and awareness programs represent critical investments in human capability. Technical staff need specialized training in OT security, incident response, and threat detection. Operational staff need awareness training on social engineering, physical security, and reporting procedures. Leadership needs strategic training on governance, risk management, and compliance obligations. External training resources, professional certifications, and information sharing organizations provide cost-effective ways to build these capabilities.
Continuous improvement and reassessment cycles ensure that security programs evolve as threats and organizations change. Schedule quarterly reviews of security metrics, annual reassessments of risk profiles, and regular updates to policies and procedures. Participate in information sharing organizations like the Water Information Sharing and Analysis Center (WaterISAC) to stay informed about emerging threats and proven practices.
Conclusion: Building Resilience Through Proactive Action
The cybersecurity challenges facing water utilities in 2026 are substantial but not insurmountable. The EPA resources provide practical frameworks that utilities can adapt to their specific circumstances regardless of size or resources. Federal agencies stand ready to provide free assistance through assessments, training, and technical support. Proven technologies including modern network segmentation capabilities enable utilities to implement controls that dramatically reduce risk without requiring complete infrastructure replacement.
The urgency of action cannot be overstated. Nation-state adversaries continue probing water infrastructure for vulnerabilities. Ransomware operators increasingly target critical infrastructure sectors including water utilities. Regulatory requirements and insurance underwriters demand demonstrable security improvements. Most importantly, the communities that water utilities serve depend on the reliable delivery of safe water, a responsibility that requires protecting operational systems from cyber threats.
The path forward requires commitment from utility leadership, engagement from technical and operational teams, collaboration with federal partners, and sustained investment in people, processes, and technology. No single action will solve all challenges, but the cumulative effect of systematic improvements creates genuine resilience against evolving threats.
Start with one concrete step today. Download the EPA resources. Schedule a CISA assessment. Change default passwords. Conduct a tabletop exercise. Each action reduces risk and builds momentum toward comprehensive cyber resilience.
The water sector now operates in conditions where cybersecurity is not optional but essential to mission success. Those utilities that act proactively will be positioned to maintain operational continuity, meet regulatory requirements, and fulfill their critical responsibility to the communities they serve. Those that delay will find themselves increasingly vulnerable to the very threats this article has documented.
Take the Next Step: Partner with Industry Leaders
Building a comprehensive cybersecurity program requires the right combination of expertise, technology, and support. While the EPA resources provide essential frameworks, implementing effective network segmentation and Zero Trust architecture often benefits from proven solutions designed specifically for operational technology environments.
Modern microsegmentation solutions enable water utilities to rapidly implement identity-based security policies across their entire network infrastructure. Leading platforms like Elisity’s Cloud Control Center provide comprehensive visibility into IT, IoT, and OT devices, automated device classification, and dynamic policy enforcement, all without requiring hardware replacement or network downtime.
Learn more about protecting your water infrastructure:
- Schedule a consultation to discuss your specific security challenges and compliance requirements: Request a Demo
- Download the Microsegmentation Buyer’s Guide and Checklist for detailed evaluation criteria and implementation best practices: Get the Buyer’s Guide and Checklist.
- Watch customer success stories. Hear how modern microsegmentation solved lateral movement prevention and did not cause downtime or a large number of change control windows for network reconfiguration projects.
- Explore the blog for additional insights on preventing lateral movement in critical infrastructure and how microsegmentation protects water and wastewater infrastructure
Essential Federal Resources:
- CISA Cybersecurity Performance Goals - Practical guidance for improving security maturity
- CISA Free Cyber Hygiene Services - Vulnerability scanning and professional assistance
- NIST Zero Trust Architecture (SP 800-207) - Framework for identity-based security
- CISA Zero Trust Maturity Model - Roadmap for ZT implementation
- EPA Water Sector Cybersecurity Program - Tools, assessments, and case studies
- CISA OT Asset Inventory Guidance - Foundational guidance for asset management
- America’s Water Infrastructure Act Information - Compliance requirements
- Safe Drinking Water Act Resources - Regulatory framework
Originally published October 30, 2025. Substantially revised and expanded July 30, 2026 to cover the July 2026 attacks on Minnesota community water systems, the CISA mitigations that followed, AWWA standards, and vendor-neutral criteria for evaluating OT segmentation.
Share this
- July 2026 (5)
- June 2026 (4)
- May 2026 (5)
- April 2026 (10)
- March 2026 (6)
- February 2026 (14)
- January 2026 (4)
- December 2025 (4)
- November 2025 (2)
- October 2025 (5)
- September 2025 (4)
- August 2025 (5)
- July 2025 (5)
- June 2025 (5)
- May 2025 (4)
- April 2025 (5)
- March 2025 (6)
- February 2025 (3)
- January 2025 (5)
- December 2024 (4)
- November 2024 (5)
- October 2024 (7)
- September 2024 (5)
- August 2024 (3)
- July 2024 (4)
- June 2024 (2)
- April 2024 (3)
- March 2024 (2)
- February 2024 (1)
- January 2024 (3)
- December 2023 (1)
- November 2023 (1)
- October 2023 (2)
- September 2023 (3)
- June 2023 (1)
- May 2023 (3)
- April 2023 (1)
- March 2023 (6)
- February 2023 (4)
- January 2023 (3)
- December 2022 (7)
- November 2022 (3)
- October 2022 (1)
- July 2022 (1)
- May 2022 (1)
- February 2022 (1)
- November 2021 (1)
- August 2021 (1)
- May 2021 (2)
- April 2021 (2)
- March 2021 (3)
- February 2021 (1)
- November 2020 (2)
- October 2020 (1)
- September 2020 (1)
- August 2020 (3)

No Comments Yet
Let us know what you think