OT/ICS Security After the U.S. Water Utility Intrusions: What Operators Should Do Now

On July 30, 2026, the FBI and EPA issued a Public Service Announcement describing intrusions affecting drinking water and wastewater utilities across multiple U.S. states. CISA maintains supporting guidance for the water and wastewater sector, but the specific PSA was an FBI-EPA release. The reporting described unauthorized access to control systems, changes to device configurations, and in some cases degraded water operations that required staff to fall back to manual control while systems were restored.

The details that matter for defenders are unglamorous. The affected systems were, in substantial part, reachable from the public internet. Devices retained default or shared credentials. The same third-party integrator configurations appeared repeatedly across different utilities, meaning one weak pattern was replicated many times. None of that requires a sophisticated adversary. This article stays with what official sources establish; where attribution has been discussed publicly, it remains a matter for those agencies rather than something to assert here.

The vocabulary, in plain language

Water utilities, manufacturers and energy operators use terms that rarely appear in corporate IT conversations. They are worth stating simply, because the security decisions follow from them.

• IT — information technology: laptops, email, finance systems, the business network. Failures here cost information and productivity.
• OT — operational technology: the systems that monitor and control physical equipment. Failures here affect a physical process, and potentially safety.
• ICS — industrial control systems: the general category of hardware and software that runs an industrial process. OT and ICS are often used interchangeably; we use OT/ICS throughout.
• PLC — programmable logic controller: a small ruggedized computer that directly operates equipment such as a pump, valve or chemical dosing unit according to programmed logic.
• HMI — human-machine interface: the screen an operator uses to see process state and issue commands.
• SCADA — supervisory control and data acquisition: the layer that collects data from many PLCs and remote sites and presents supervisory control across the whole plant or network.

The critical asymmetry: an IT system can usually be taken offline to be patched. A pump station serving a town cannot. That constraint, not indifference, is why OT environments run old software and why compensating controls — segmentation, access restriction, monitoring — carry so much of the weight.

What the reporting actually described

Across the reported incidents several patterns recur, and each maps to a control that can be checked this week:

• Internet-facing control devices. PLCs and HMIs directly reachable from the public internet, in some cases discoverable through ordinary internet-wide scanning services rather than any private capability.
• Default, shared or weak credentials. Devices left with vendor defaults, or with a single password shared among staff and contractors and never rotated after personnel changes.
• Unauthorized configuration changes. Alterations to device settings, IP addressing, passwords and in some cases project files — the programs that define how the controller behaves.
• Repeated integrator configurations. The same remote-access and device-configuration pattern deployed by a third party across many utilities, so a single insecure default propagated widely.
• Degraded operations and manual fallback. Where operations were affected, staff reverted to manual control. Utilities with practiced manual procedures absorbed the disruption far better than those improvising.

Immediate protections

These are the actions worth taking in days, not quarters. Most require configuration discipline rather than budget.

1. Remove control systems from the public internet. Inventory every device with a routable address — PLCs, HMIs, remote telemetry units, engineering workstations, cellular routers — and take them off direct exposure. Where remote access is genuinely required, place it behind a VPN or an access broker with strong authentication.
2. Change every default and shared credential. Include devices installed by integrators, and rotate anything a departed employee or former contractor may know. Move to named accounts where the equipment supports it.
3. Enforce multi-factor authentication on all remote access — utility staff, integrators and vendors alike. Shared, unauthenticated remote access is the single most common route in.
4. Separate OT from IT. A flat network that lets a phished business laptop reach a PLC is the difference between an email incident and a process incident.
5. Back up controller logic and configurations offline, verify a restore actually works, and store known-good project files where ransomware on the business network cannot reach them.
6. Turn on and review logging for remote access, configuration changes and authentication failures. Unauthorized changes are only actionable if someone sees them.
7. Rehearse manual operations. If SCADA is unavailable for 48 hours, staff should know how to run the process, and should have done it recently under a drill.

Longer-term improvements

• Asset inventory as a living record. Model, firmware version, network location, owner and remote-access path for every OT asset. Nearly every other control depends on this existing and being current.
• Architecture and segmentation program. Zones and conduits along the lines of ISA/IEC 62443, with enforced boundaries between business, supervisory and control layers rather than diagram-only separation.
• Third-party and integrator governance. Contractual security requirements, per-vendor named accounts, time-bounded access, and configuration review on handover. The repeated-configuration pattern in the reporting is a supply-chain problem as much as a technical one.
• Change control for controller logic. Version control for project files, documented approval for logic changes, and periodic comparison of running logic against the approved baseline.
• OT-aware monitoring. Passive network monitoring that understands industrial protocols and alerts on unexpected commands, new devices or configuration writes.
• An incident response plan written for OT. Different decision-makers, different safety constraints and different recovery order than an IT plan. Exercise it with operations staff, not just IT.
• Vulnerability management adapted to uptime constraints. Firmware updates scheduled against maintenance windows, with compensating controls documented for what cannot be patched.
• Program governance. Named ownership, a control framework mapped to NIST CSF or ISA/IEC 62443, and reporting that reaches leadership on a cadence.

Questions executives should ask operations and engineering teams

None of these require technical vocabulary to ask, and each surfaces a specific weakness if the answer is vague.

• Which of our control system devices can be reached from the internet right now, and who confirmed that this week?
• How does a contractor connect to our systems remotely, and is multi-factor authentication required?
• Have we changed the default passwords on every device an integrator installed?
• If someone changed the logic inside a PLC tonight, how and when would we find out?
• Can we restore a controller from a known-good backup, and when did we last prove it?
• If SCADA were unavailable for two days, can staff run the process manually — and when did they last practice?
• Can a compromised laptop on the business network reach the control network?
• Who do we call in the first hour, and does our incident plan cover operational safety, not just data?
• Which vendors hold standing access, and when was that access last reviewed?
• What would we tell customers and regulators, and who is authorized to say it?

How ControlSolid helps

Our OT/ICS work is assessment and advisory led. Typical engagements include:

• Exposure and readiness review — what is internet-facing, what authentication protects it, and what to fix first.
• Architecture and segmentation review — boundaries between business, supervisory and control layers, and whether they are enforced.
• Remote and third-party access review — how staff, integrators and vendors connect, and how that access is governed.
• Control-gap assessment — current state against NIST CSF, ISA/IEC 62443 or sector expectations, with a prioritized plan.
• Incident-readiness review — OT-specific response, manual operations and tested recovery.
• Program governance support — ownership, cadence and leadership reporting.

A note on testing: active testing against production OT and ICS environments requires written authorization, operational coordination, safety controls and a separately agreed scope. It is never bundled into a standard assessment, and it is not the right starting point for most operators.

Frequently asked questions

What is the difference between IT and OT?

IT systems handle information — email, databases, business applications. OT (operational technology) systems monitor and control physical processes such as pumps, valves, chemical dosing and pressure. An IT outage disrupts information; an OT outage disrupts a physical process, which is why safety and availability outrank confidentiality in OT environments.

Why are internet-exposed PLCs such a problem?

Programmable logic controllers were designed for trusted local networks. Many speak protocols with no authentication or encryption, and some ship with default or shared credentials. When one is reachable from the public internet, an attacker with no special access can often read or change its configuration directly.

Do small utilities really need to worry about this?

Reported activity has not been limited to large systems. Small utilities are often more exposed because remote access is used to avoid site visits and because integrator-configured equipment may retain default settings. Attack tooling scans the whole internet, so size does not confer obscurity.

Can ControlSolid test our production control systems?

Active testing against live OT and ICS environments is never performed casually. It requires written authorization, operational coordination, safety controls and a separately agreed scope. Most engagements begin with exposure review, architecture and segmentation review, remote access review and control-gap assessment — work that carries no operational risk.

Related resources

• Cybersecurity readiness & gap assessment — control review across NIST CSF, CIS and sector expectations.
• CMMC & NIST 800-171 readiness — for operators and suppliers handling federal contract information.
• vCISO advisory and customer assurance — ongoing program ownership and leadership reporting.

Authoritative sources

• FBI/EPA Public Service Announcement — malicious cyber actors targeting water and wastewater sector internet-facing PLCs: fbi.gov — water and wastewater sector PLCs alert
• CISA water and wastewater sector guidance and advisories: cisa.gov/water
• EPA water system cybersecurity resources: epa.gov — cybersecurity for the water sector