Practical Cybersecurity for Small Water Utilities: 5 Steps to Reduce Operational Risk

Recent cyberattacks against U.S. water and wastewater systems delivered an important reminder: disrupting operational technology (OT) does not always require sophisticated malware or a previously unknown vulnerability. In the July 2026 activity, internet-facing programmable logic controllers (PLCs), weak or reused credentials, undocumented remote access pathways, and recurring third-party configurations created opportunities for attackers to interfere with physical operations.

SpiderLabs’ technical review of the July attacks examines the affected technologies, observed activity, and broader threat landscape. The next question is practical: what can small utilities realistically do about it?

At many small water and wastewater facilities, there is often no dedicated security team to understaff. A licensed operator may be responsible for sampling, maintenance, compliance, and after-hours callouts, perhaps with limited support from municipal IT. OT security becomes one more duty assigned to the people already responsible for keeping the plant running.

That reality should shape the security strategy. A small utility may not be able to build a 24/7 monitoring function, but it can still remove many of the conditions that make intrusion possible. The immediate priority should be to build a hard outer shell around critical operations: reduce exposure, restrict access, preserve recoverability, and make responsibility explicit.

The following guidance is designed for utilities that need to make measurable progress with limited staff and funding.

1. Assign one accountable owner

The first control is not a product. It is ownership.

Someone should be named as the accountable owner for each core security task, even if cybersecurity is only one part of that person’s role. At a minimum, the utility should document who is responsible for:

• Maintaining the inventory of OT assets and remote connections

• Approving new internet-facing services or vendor access

• Reviewing advisories from CISA, the EPA, WaterISAC, AWWA, state agencies, and equipment vendors

• Confirming that identified risks are assigned and addressed

• Coordinating incident response and the transition to manual operations

This does not create new headcount, but it closes a common operational gap. An advisory sent to an unmonitored mailbox has no defensive value. Neither does an assessment whose findings have no owner, deadline, or follow-up process.

For a small utility, accountability can be simple: a one-page responsibility matrix, a shared action log, and a recurring monthly review. The goal is to make sure every important task has a name and a date attached to it.

2. Find and reduce external exposure

The most common and consequential finding in these environments is often not a software vulnerability. It is an asset no one knew was reachable from the internet or access no one knew a vendor retained.

Utilities should inventory every internet-reachable component associated with operations, including:

• PLCs and remote terminal units

• Human-machine interfaces (HMIs)

• Operator Interface terminals (OITs)

• Cellular gateways and modems

• Virtual private network appliances and remote desktop services

• CCTV and physical access systems

• Engineering workstations and vendor support gateways

The inventory should include the asset owner, physical location, public IP address or hostname, purpose, authentication method, approved users, and business justification for external access. If an exposed service cannot be tied to an owner and a documented operational need, it should be disabled or isolated until it can be reviewed.

This exercise must include remote and unattended sites. It is common for integrators to install cellular gateways or modems during a project without those devices entering the utility’s central inventory. A gateway on a public address with a vendor-standard password can bypass the utility’s perimeter firewall entirely.

Physical access matters as well. An unlocked building, cabinet, or network switch can provide a direct path into a flat controls network. Locked facilities and cabinets, restricted switch ports, device filtering, and segmentation between remote sites and the core control environment can prevent a local compromise from becoming a systemwide one.

3. Control every credential and remote pathway

Once the utility understands what is connected, it should document how people reach it.

Default credentials, shared accounts, reused vendor passwords, and permanently enabled remote sessions should be eliminated wherever the technology allows. Remote access should be available only when required, restricted to named users and approved source systems, and protected with multifactor authentication when supported. Privileged activity should also be logged where feasible.

Integrator and vendor relationships deserve particular attention. Utilities should ask each integrator and equipment vendor to provide a written record of:

• Every remote connection they expose within the environment

• Every privileged, service, shared, or emergency account the vendor controls

• The authentication and logging controls applied to those connections

• Any credentials reused across client environments

• The process for revoking access when personnel or contracts change

• Any independently installed modems, gateways, or management tools

Third-party configurations can be replicated across many customers. That creates efficiency for the integrator, but it can also turn one weak practice into a shared exposure across multiple utilities. Vendor access should therefore be treated as part of the utility’s attack surface, not as an exception to it.

4. Protect the process and prepare to recover it

Legacy industrial protocols were often designed for availability and deterministic control, not authentication. If an unauthorized person can reach the correct port on some older controllers, changing a treatment set point may be a normal protocol function rather than an exploit. There may be no patch that changes this behavior.

The practical mitigation is to prevent untrusted systems and users from reaching the device in the first place. Utilities should use network segmentation, firewall rules, access control lists, jump hosts, and device-level filtering where supported to limit who can communicate with critical controllers. Connections should follow an allowlist model: Only explicitly approved systems, protocols, and users should be permitted.

Because prevention is never perfect, utilities also need a recoverable baseline. They should:

• Maintain verified offline copies of PLC logic, HMI configurations, network device configurations, and other critical files

• Record known-good set points and controller parameters

• Compare saved logic and configurations with the running environment on a defined schedule and after suspected incidents or vendor maintenance

• Test restoration procedures instead of assuming backups will work

• Document the order in which systems should be recovered

Utilities should also rehearse the transition to manual operation. During the July incidents, manual procedures helped some facilities maintain service after automated visibility or control was disrupted. Operators should know which processes can be run manually, for how long, with what staffing, and under what safety constraints. The exercise should also identify dependencies that could make manual operation difficult, such as unavailable parts, inaccessible documentation, or a shortage of qualified operators.

Manual operation is not a substitute for cybersecurity. It is a resilience measure that can reduce the physical consequences of a cyber incident.

5. Convert every assessment and advisory into tracked work

The America’s Water Infrastructure Act requires community water systems serving more than 3,300 people to prepare or revise risk and resilience assessments and emergency response plans and certify completion to the EPA. Smaller systems fall outside that requirement, although federal guidance and technical assistance remain available to them.

Completing an assessment, however, is not the same as reducing the risk it identifies. Guidance from AWWA, WaterISAC, CISA, the EPA, and state agencies becomes operational only when the utility translates it into a change.

Every material finding or recommendation should produce one of four outcomes:

• A configuration change with an owner and completion date

• An updated operating or incident response procedure

• A compensating control when the preferred fix is not currently feasible

• A funded replacement or remediation plan with a target date

If the utility accepts a risk, that decision should also be documented, approved, and reviewed periodically. This creates a practical bridge between compliance documentation and day-to-day operations.

A 90-day starting plan

Utilities do not need to solve every OT security problem at once. A focused 90-day effort can reduce several of the most immediate risks.

Days 1–30: Establish ownership and visibility

• Name an accountable security coordinator and a backup

• Confirm who receives and reviews sector advisories

• Build an initial inventory of internet-facing OT assets and remote access pathways

• Request a complete access and account inventory from integrators and vendors

• Identify default, shared, and reused credentials

Days 31–60: Reduce preventable exposure

• Remove or isolate unnecessary internet-facing systems

• Change default and vendor-reused credentials

• Disable stale accounts and unneeded remote connections

• Restrict vendor access by user, source, destination, and time

• Lock remote facilities, cabinets, and accessible network equipment
• Prioritize segmentation around PLCs, HMIs, and engineering workstations

Days 61–90: Strengthen recovery and accountability

• Create and verify offline backups of logic and critical configurations

• Establish a cadence for comparing backups with running systems

• Conduct a tabletop exercise that includes loss of HMI access and manual operation

• Turn unresolved assessment findings into an owner-and-deadline remediation plan

• Identify items that require outside technical support or future capital funding

• Design security controls for the utility that actually exist and are attainably executable

Small utilities should not be measured only against security models built for large organizations with enterprise IT teams and around-the-clock monitoring. Recommendations that assume capabilities a utility does not have are likely to remain recommendations.

That does not mean accepting insecurity. It means sequencing the work correctly. Start by building the shell: know what is connected, close unnecessary pathways, constrain the access that remains, protect the process through network controls, and prepare operators to recover safely. Monitoring can add important visibility as resources mature, but it should not be expected to compensate for unmanaged exposure and weak access controls.

The July attacks showed that relatively simple weaknesses can create real operational consequences. They also showed that operators and manual procedures remain important resilience controls. The most effective framework for a small utility respects both realities and focuses first on changes the organization can sustain.