When people think about a cyberattack on water infrastructure, they often imagine the most dramatic outcome: a malicious actor changing a setpoint, stopping a pump, manipulating chemical treatment, or interfering with a physical process.
Those scenarios deserve attention, but they can distract from a more immediate and often overlooked operational risk.
An attacker does not always need to change the process to create an incident. Sometimes, taking away an operator’s ability to see, access, administer, or confidently recover a system is enough.
Recent federal warnings have highlighted malicious activity targeting internet-facing programmable logic controllers, or PLCs, in the Water and Wastewater Systems Sector. Reported activity included changing passwords to lock out operators and changing IP addresses, disrupting normal access to affected systems.
A changed password or IP address may sound like a routine IT support problem. In an operational environment, it can rapidly become a resilience problem.
If the people responsible for a process cannot reach a controller through normal engineering tools, they may not be able to verify its current state, investigate alarms, confirm network communications, or make a necessary change with confidence. The controller may still be operating, but the organization has lost a trusted management path.
At that point, the incident has already begun.
The overlooked impact: loss of trusted control
Security teams often define compromise through familiar IT outcomes: stolen data, ransomware deployment, privilege escalation, or a confirmed outage.
Operational environments require a broader definition. The question is whether authorized personnel can still exercise trusted control.
Trusted control means more than having a valid username and password. It means that the right people can identify a device, reach it through an expected network path, authenticate safely, confirm its state, understand recent changes, and restore it without creating additional operational risk.
When those capabilities are lost, uncertainty increases quickly.
Consider a PLC that no longer responds at its documented IP address. It may be operating normally. It may be isolated from the management network. Its configuration may have changed. It may be reachable only through a different interface or by someone onsite. Until the team can validate the situation, the operational status of the device becomes uncertain.
That uncertainty can force a utility into manual procedures, require personnel to travel to remote sites, and create an urgent dependency on engineering staff, vendors, or system integrators. The physical process may continue, but the normal operational model has been disrupted.
The recent PLC activity is therefore more than a story about exposed devices. It is a reminder that loss of management access can be an operational impact in its own right.
Operational disruption often starts as friction
Not every water-sector cyber incident begins with an alarm, shutdown, or visible equipment failure. Sometimes, it begins with friction.
An operator cannot access a human-machine interface, or HMI. An engineer’s credentials unexpectedly fail. A remote-support connection no longer works. A controller disappears from its normal network location. A cloud dashboard fails to display current information. A vendor is the only party able to access a device, but the access process is unclear or unavailable.
Individually, each issue may appear manageable. During an incident, they compound.
They delay decision-making, complicate communication, consume the attention of operations staff, and make it harder to distinguish a cybersecurity event from a technical failure. In an environment responsible for treatment, distribution, pumping, or wastewater processing, that delay matters.
This is a useful red-team lens: the objective is not always to create an obvious outage. An attacker may instead create enough friction, uncertainty, and loss of visibility that the organization is forced into recovery mode under pressure.
A system does not need to be offline to become untrusted. And an untrusted operational system can be as disruptive as an unavailable one.
What water-sector attacks can target
Water and wastewater environments contain more than PLCs. They include engineering workstations, HMIs, remote-access services, vendor connections, historians, cloud dashboards, sensors, gateways, and supporting enterprise infrastructure.
Those connections create several potential paths to operational disruption.
Internet-facing PLCs
The most direct risk is a PLC or other operational technology device exposed to the public internet.
Water-sector organizations should remove publicly exposed PLCs and OT devices from the internet. Remote access should sit behind a virtual private network, gateway, or other controlled access point rather than connecting directly to a PLC. Organizations should use strong password protection, remove default credentials, allowlist approved source IP addresses where appropriate, and retain a known-clean PLC image in case access must be restored after unauthorized changes.
A publicly exposed controller creates a direct route to a high-consequence device. Even when an attacker does not modify logic or setpoints, unauthorized changes to credentials or network configuration can deny access to the authorized operators who need to monitor and manage the system.
The defensive priority is clear: direct internet exposure should be removed wherever possible. Remote access should be deliberate, strongly authenticated, logged, limited to approved systems, and designed for recovery.
Human-machine interfaces and engineering workstations
PLCs are often managed through engineering workstations and observed through HMIs. These systems bridge the gap between the operator and the physical process, making them high-value targets.
An attacker who compromises an engineering workstation may gain access to configuration files, controller-management software, stored credentials, or trusted network paths to OT systems. An attacker who disrupts an HMI may degrade an operator’s ability to view alarms, device state, or process information.
Federal guidance has warned that organizations in multiple critical-infrastructure sectors have experienced configuration wiping, software-based mechanical sensor tampering, and disruption of HMIs.
The security implication is not that every HMI issue is malicious. It is that operators need independent ways to validate the process when a primary management or visualization system becomes unreliable.
Engineering workstations and HMIs should be treated as high-consequence assets: hardened, closely monitored, tightly controlled, and separated from routine user environments.
Vendor and remote-access pathways
Water utilities often rely on equipment manufacturers, system integrators, managed-service providers, and contractors. Remote vendor access can be operationally necessary, especially where facilities are geographically distributed or local technical resources are limited.
It can also create a trusted route into an operational environment.
A red-team assessment should examine whether vendor access is constrained by named accounts, multi-factor authentication, approval workflows, time limits, source restrictions, session monitoring, and clearly defined network permissions. The relevant question is not whether vendors have remote access. It is whether compromise of a vendor identity, remote-support portal, or contractor endpoint could bypass the utility’s normal operational boundaries.
Standing access is particularly important to review. Temporary support connections often outlive the project that justified them. A connection installed for a vendor, integrator, cellular modem, or emergency maintenance purpose may not appear in routine asset inventories or external exposure scans.
IT-to-OT dependencies
Not every attack on a water utility starts with operational technology. Ransomware, identity compromise, or disruption of corporate IT can affect operations when OT depends on shared enterprise services such as remote access, identity services, DNS, file storage, backups, documentation repositories, or communications platforms.
This does not mean IT and OT must be isolated from one another in every respect. It means that dependencies need to be intentional and understood.
If the corporate network becomes unavailable, can operators still reach critical engineering systems? Can they identify the current configuration of a PLC? Can they safely restore access? Can they continue operating through local or manual procedures?
These are resilience questions, not merely network-design questions.
Segmentation should protect recovery
Segmentation is often framed as a way to stop lateral movement. That is true, but it is incomplete.
In water and wastewater environments, segmentation should also preserve the organization’s ability to recover.
If a user workstation, camera, sensor, contractor laptop, VPN account, or vendor portal is compromised, that event should not provide a route to an engineering workstation, HMI, PLC, identity platform, or backup environment. At the same time, compromise of one zone should not eliminate every authorized path that operations personnel need for safe recovery.
Effective segmentation is not a VLAN diagram. It is a set of enforced, monitored rules that define which systems can communicate, for what purpose, and through which management path.
|
Security zone |
Typical systems |
Security objective |
|
User environment |
Employee laptops and mobile devices |
Keep routine business activity separate from privileged and operational systems |
|
IoT environment |
Cameras, sensors, smart devices, printers |
Limit communications to required gateways, monitoring systems, and approved update paths |
|
Operational environment |
PLCs, controllers, pumps, treatment systems |
Protect availability, integrity, safety, and process continuity |
|
Management environment |
Jump hosts, engineering workstations, monitoring tools |
Centralize, authenticate, and monitor privileged administration |
|
Integration environment |
VPNs, proxies, gateways, remote-support services |
Mediate access across trust boundaries |
|
Critical-services environment |
Identity systems, backups, databases, financial platforms |
Apply the strongest access controls, monitoring, and recovery protections |
The practical test is straightforward: if one connected asset is compromised, what can it actually reach?
If a device can communicate with systems beyond its documented purpose, or if a remote-access path can reach sensitive OT assets without strong control and visibility, the organization has created more trust than the device needs.
The recovery question teams miss
Many organizations ask whether they can prevent unauthorized access to a controller. They should also ask whether they can recover if an attacker changes how that controller is accessed.
For every high-consequence device, the organization should be able to answer:
- Who owns the device operationally and technically?
- What process does it support?
- Which people and systems are authorized to administer it?
- Where is the known-good controller image, configuration, and engineering project file stored?
- How can the device be identified if its network settings change?
- Which logs show changes to credentials, IP addresses, firmware, controller mode, or remote access?
- Can the process continue safely if the central management path is unavailable?
- Who can respond onsite if remote access is lost?
- What role does the vendor play in recovery, and is that dependency documented and tested?
These are not documentation exercises. They are operational resilience questions.
A backup is valuable only if it can be located, validated, and restored safely. An asset inventory is useful only if it identifies the owner, process dependency, network location, management method, and recovery requirements. An incident-response plan works only if operations, engineering, IT, security, and vendors understand their roles before an incident occurs.
Any assessment involving operational technology should be explicitly authorized, jointly planned with operations and engineering teams, and designed to avoid changes to live processes, device availability, or safety functions.
What to prioritize now
Water and wastewater operators do not need to solve every cybersecurity challenge at once. They should start with the conditions most likely to turn a technical weakness into an operational disruption.
- Identify every internet-facing asset, including remote-access services, vendor portals, cellular-connected devices, cloud management platforms, gateways, and OT systems.
- Remove direct internet exposure from PLCs and other high-consequence operational devices.
- Route remote access through a controlled VPN, gateway, or jump host rather than directly to an operational device.
- Replace default, shared, and stale administrative accounts with unique identities and strong authentication.
- Restrict PLC and OT management access to approved engineering workstations and required OT assets through source allowlisting and default-deny rules where practical.
- Harden and monitor engineering workstations, HMIs, and the systems that store controller configurations and project files.
- Limit vendor access by system, user, role, time period, and network destination; remove access when it is no longer required.
- Alert on unexpected changes to passwords, IP addresses, controller configuration, firmware, remote-access settings, and privileged accounts.
- Maintain known-clean PLC images and test recovery procedures for lost credentials, changed network settings, unavailable management interfaces, and failed remote-access paths.
- Conduct authorized, safety-conscious red-team exercises that test how external exposure, identity weaknesses, vendor access, and network trust could combine into a path toward operational systems.
A better standard for resilience
The water sector’s cyber risk is not limited to a device being compromised. It is about whether that compromise can interrupt the organization’s ability to operate, see, decide, and recover.
That is why the red-team perspective matters. It connects external exposure to internal trust, technical weaknesses to operational consequences, and individual configuration gaps to realistic attack paths.
The most important question is not simply: “Can an attacker get in?”
It is: “If they do, can they take away our ability to see, manage, and recover the systems that keep operations running?”
For water utilities and for any organization operating connected infrastructure that is the standard worth testing.
Sources
- Cybersecurity and Infrastructure Security Agency, “CISA Urges Water and Wastewater Systems Sector to Protect OT Against Activity Targeting PLCs,” July 30, 2026.
https://www.cisa.gov/news-events/alerts/2026/07/30/cisa-urges-water-and-wastewater-systems-sector-protect-ot-against-activity-targeting-plcs - Federal Bureau of Investigation, “Malicious Cyber Actors Targeting Water and Wastewater Sector Internet-Facing Programmable Logic Controllers, Causing Operational Disruptions,” July 30, 2026.
https://www.fbi.gov/investigate/cyber/alerts/2026/malicious-cyber-actors-targeting-water-and-wastewater-sector-internet--facing-programmable-logic-controllers-causing-operational-disruptions - U.S. Government Accountability Office, “Critical Infrastructure Protection: EPA Urgently Needs a Strategy to Address Cybersecurity Risks to Water and Wastewater Systems,” August 1, 2024.
https://www.gao.gov/products/gao-24-106744 - U.S. Environmental Protection Agency, “EPA, FBI, CISA, NSA Issue Joint Cybersecurity Advisory to Water System Regarding Iranian-Affiliated Cyber Attacks,” April 7, 2026.
https://www.epa.gov/newsreleases/epa-fbi-cisa-nsa-issue-joint-cybersecurity-advisory-water-system-regarding-iranian