How Can Water Utilities Protect Their Control Systems From Cyberattacks?

Water utilities protect control systems by reducing exposed connections, separating operational equipment from business networks, tightly controlling remote access, monitoring for abnormal changes, maintaining tested backups, and rehearsing safe manual operation. The goal is not merely to keep attackers out. It is to prevent one compromised account or device from changing treatment, stopping pumps, hiding alarms, or delaying recovery.

Why water cybersecurity is different

A water utility uses information technology for email, billing, customer records, and office work. It also uses operational technology (OT) to observe and control pumps, wells, tanks, valves, chemical dosing, filtration, pressure, and wastewater processes. A cyber incident can therefore affect both information and physical service.

Availability and safety often outrank confidentiality in OT. Shutting down a controller immediately may be acceptable in an office test environment but dangerous when it manages pressure or treatment. Defenders must understand the physical process, safe operating ranges, and consequences of interruption before applying ordinary IT responses.

What makes up a control environment?

Together, these components may form an industrial control system (ICS). The labels vary by utility, but the security question is consistent: which path can carry data or commands from a less trusted zone to physical equipment?

Start with an evidence-based asset inventory

A utility cannot protect a device it does not know exists. The inventory should include model, firmware, physical location, network addresses, owner, function, criticality, configuration backup, support status, communication peers, and every remote-access route. It should cover radios and cellular routers installed by contractors, not only equipment purchased by the IT team.

Passive network discovery is generally safer than aggressive scanning on fragile OT protocols. Configuration files, switch tables, engineering drawings, firewall rules, procurement records, and physical walkdowns help reconcile the list. The inventory must be maintained as an operational process, not produced once for an audit.

Remove controllers from the public internet

A PLC or operator panel should not expose its management interface directly to the internet. Search engines for connected devices and routine automated scans make discoverable equipment easy to find. Default credentials or an old service may turn exposure into control without sophisticated malware.

When remote monitoring is necessary, place it behind a managed access path. A secure architecture typically uses a firewall, a demilitarized zone, a hardened jump host, strong authentication, and explicit rules allowing only required protocols and destinations. “Hidden” addresses and nonstandard ports are not security controls.

Segment networks to limit consequences

Segmentation divides the environment into zones based on function and trust. Business users should not connect directly to controllers. Internet-facing services should not share an unrestricted network with SCADA. Critical processes can be divided further so a wastewater lift station compromise cannot automatically reach drinking-water treatment.

Firewalls between zones should deny by default and allow documented flows. Data historians may send selected operational data outward through an intermediary, while inbound commands face stronger controls. Segmentation is effective only if alternate paths, including Wi-Fi, vendor laptops, cellular modems, dual-homed servers, and temporary maintenance links, are found and governed.

Make remote access exceptional and observable

Remote support can shorten outages, particularly for small utilities without every specialist on staff. It also creates a high-value route into the plant. Safer access includes:

• individual accounts rather than shared vendor credentials;
• phishing-resistant multifactor authentication where supported;
• approval before a session and automatic expiration afterward;
• a jump host that records connections and administrative actions;
• access limited to the required asset, protocol, and time window;
• managed vendor devices with appropriate security checks;
• immediate revocation when personnel or contracts change.

A VPN encrypts a path but does not make the user, laptop, or destination trustworthy. It should be one component of access control, not the entire design.

Protect identities and controller logic

Default passwords should be replaced, shared accounts reduced, and privileges matched to roles. Engineering software and PLC programming access deserve stronger protection than read-only monitoring. Where the technology supports it, use signed logic, write protection, key switches, or separate modes that prevent casual program changes.

Utilities should maintain approved baselines for PLC logic, setpoints, alarm limits, firmware, and workstation software. An unexpected difference can reveal tampering or an undocumented maintenance change. Change control must be practical enough that operators use it during urgent work.

Patch by risk, not by reflex

Old OT systems can contain serious vulnerabilities, yet an untested patch may interrupt a process or break vendor support. A defensible program tracks vulnerabilities and exposure, tests changes in a representative environment where possible, coordinates downtime, and documents compensating controls when immediate patching is unsafe.

Removing internet exposure, restricting protocols, isolating an unsupported device, and monitoring its traffic can reduce risk while replacement is planned. “Cannot patch now” should lead to a documented treatment and deadline, not permanent acceptance.

Detect changes that matter to the physical process

OT monitoring should combine cyber and operational signals. Useful alerts include a new device, a connection from an unexpected zone, PLC programming outside a maintenance window, repeated failed logins, changed logic or firmware, disabled alarms, unusual command frequency, or a setpoint outside an approved range.

Process data provides context. A pump command that conflicts with tank level, valve state, expected schedule, or redundant sensor readings may be more significant than an unusual packet alone. Logs should be sent to a location an attacker on the affected workstation cannot erase.

Backups must restore operation, not merely files

A complete recovery set may include PLC logic, human-machine-interface projects, SCADA configuration, historian settings, recipes, network-device configuration, licenses, firmware, encryption keys, engineering software, and instructions for rebuilding hardware. Copies should be offline or otherwise protected from the same credentials that operate production.

Testing is essential. A backup that cannot be loaded into available spare hardware, depends on an expired license, or lacks the correct firmware is not a recovery capability. Exercises should measure how long it takes to restore a minimum safe service.

Manual control is a resilience layer

Manual fallback is not a slogan. Operators need current procedures, reachable controls, working gauges, safe staffing, communications, and training. They must know which processes can run manually, for how long, with what sampling and regulatory checks, and which conditions require shutdown or public notification.

Practice reveals hidden dependencies. A nominally manual valve may be inaccessible; a local panel may still depend on the failed network; or the only employee who remembers a procedure may be off duty. Exercises should include loss of remote visibility, false readings, unavailable vendors, and simultaneous business-IT disruption.

Respond without destroying evidence or safety

1. Confirm the physical state. Use independent readings and operator observation before trusting or changing a compromised display.
2. Stabilize the process. Move to a known safe operating mode or manual control according to engineering procedures.
3. Contain deliberately. Isolate affected paths without causing uncontrolled shutdown.
4. Preserve evidence. Retain logs, device images, configurations, timestamps, and relevant communications.
5. Coordinate. Engage utility leadership, engineering, public health, emergency management, regulators, law enforcement, and specialist responders as required.
6. Recover from known-good states. Validate logic, credentials, network rules, and process behavior before reconnecting.

Public communication should separate confirmed facts from investigation. A compromised control system does not automatically mean contaminated water; equally, absence of an immediate health impact does not make the intrusion trivial.

A recent warning from US utilities

In 2026, malicious activity reached water-system OT in at least seven US states. More than 30 Minnesota systems and nine Michigan systems were reported affected; some operators switched to manual control, while officials reported no known drinking-water or public-health harm. NewTqnia's report on the incidents shows why exposed controllers and practiced fallback both matter.

Public attribution remained unresolved in the source reporting. Similarity to a known actor's technique is context, not proof. Defensive decisions should respond to the reachable weakness regardless of who eventually receives blame.

What small utilities should prioritize first

A small organization cannot deploy every control at once. The highest-value sequence is often:

1. find and remove direct internet exposure;
2. change defaults and secure remote access with individual MFA accounts;
3. separate business IT from OT with restrictive firewall rules;
4. back up controller logic and critical configurations offline;
5. document vendor and cellular connections;
6. test manual operation and emergency contacts;
7. add monitoring and build a funded replacement plan for unsupported assets.

Shared services, regional support, government programs, and managed security providers can help, but the utility remains responsible for understanding who can reach the process and what happens during failure.

The mental model

Think of a water control system as a series of pressure doors between the internet and the physical process. Inventory tells you where the doors are. Segmentation limits how many can be crossed. Identity checks control who opens them. Monitoring detects unexpected movement. Backups and manual operation keep safe water service possible if several doors fail. Resilience comes from layers, not one security product.