← Back to Resources

Article · August 13, 2026 · 9 min read

What the 2026 PLC Attacks Mean for Wastewater Operations

In late July, attackers reached internet-facing PLCs at water utilities in at least seven states and changed their configuration. The operational lesson is not about attribution. It is about what plant equipment was reachable, and what maintenance looks like after you close that door.

Srikant Naidu, Founder, EQUA AI

Working on a live operating problem? Book Your 20-Minute Assessment

an exposed control cabinet moving from an open network path to the protected side of a double dotted boundary
PLC exposure · The network boundary is the subject

A programmable logic controller does not need to be destroyed to disrupt a water system. It only needs to stop telling the truth.

In late July, attackers remotely reached internet-facing PLCs at United States water and wastewater utilities and changed their configuration. Utilities in at least seven states reported incidents. Some lost monitoring, some lost control, and reported operational effects included loss of pressure and flooding.

The important question for an operator is not who did it. It is why equipment that performs physical work was reachable from the open internet at all, what that says about how these plants are built, and what has to change before the next one.

What actually happened

On 30 July 2026 the FBI and the Environmental Protection Agency issued a joint public service announcement, alert I-073026-PSA. The facts in it are narrow and worth stating precisely, because the coverage that followed was not always careful.

Since 27 July 2026, water and wastewater utilities in at least seven states reported incidents to the FBI. The targeted devices were internet-exposed Rockwell Automation and Allen-Bradley PLCs, specifically the MicroLogix 1100 and 1400 series. The FBI notes it has only observed the behaviour on those controllers, and that operators should treat other brands with the same caution.

The technique was not exotic. After reaching the devices, the actors changed IP addresses and set passwords. The result was a loss of view, and in some cases loss of function, over connected equipment. At least one organisation found modified PLC project files after noticing ladder logic discrepancies across several of its sites.

Two details in the advisory deserve more attention than they have received.

The first is about how far the damage went. The FBI states that the extent of impact depended on what the PLC was configured to do (monitor or control), which device it was, what function it supported, and the utility’s capability to switch to manual operations. That last item is not a security control. It is an operations and maintenance capability, and it turned out to be one of the variables that separated an inconvenience from an incident.

The second is about how the utilities were similar. The advisory observes that across several victims, similarities in network setup provided by third parties may give an attacker the opportunity to multiply successes where the same vulnerable network and hardware arrangement exists across customers. In plain terms: a systems integrator’s standard build can be a shared attack surface across dozens of small utilities that have never met each other.

Why a controller is not a mailbox

Most cybersecurity intuition is built on information systems. A compromised email account is an information problem: something was read, something was sent, something was stolen. The response is investigative and largely retrospective.

A compromised controller is a different category. A PLC is a small computer whose outputs are wired to contactors, drives, and valve actuators. Its job is to convert logic into physical motion. When its configuration changes, the change is not a data breach. It is a change to what the plant does, or, more often and more insidiously, a change to what the plant appears to be doing.

That is why loss of view matters as much as loss of control. An operator who cannot see a wet well level has lost the ability to make the next decision correctly, whether or not anyone touched a pump. And an operator who is looking at a value that is no longer trustworthy is worse off than one who knows the screen is dark.

Ladder logic modification is the most serious item on the list for exactly this reason. A changed IP address announces itself. Modified logic does not. It sits inside the device that everyone downstream believes, and it is only found if somebody compares the running program against a known-good copy, which is a maintenance activity, performed by a person, on a schedule, using a record that has to exist beforehand.

What the agencies asked utilities to do

The FBI and EPA recommendations are practical and, notably, mostly not about buying anything. Summarised, and paraphrased rather than quoted:

Take the controller off the public internet. Remove inbound port exposure so the control system is never directly reachable from external networks, and broker every connection through a secure gateway or jump host so access is mediated, monitored and controlled.

Secure the cellular path too. Remote field connectivity through cellular modems needs strong authentication and current firmware, with logging enabled and reviewed, and an isolated connectivity architecture rather than a modem sitting openly on a carrier network.

Use strong, unique device passwords, and restrict which devices may talk to the controller at all, using firewall rules or access control lists so only expected control-system traffic is permitted.

Keep key switches in run position. Physical and software key switches block unauthorised changes to logic, configuration and firmware. Move to program or remote only while deliberately updating, and switch back immediately. Validate the project file before returning to run, because changing modes locks in whatever is currently loaded.

Practise manual operation. The ability to revert to manual control and keep the process running is what determines the size of the incident. Fail-safe mechanisms, islanding, standby systems and the recovery plan all have to be exercised, not documented.

Review the project files running on your PLCs for unauthorised changes, using vendor integrity-checking tools and a visual comparison against known-good logic. Verify that any backup you restore is clean.

Read that list as an operations manager rather than as a security manager and something becomes obvious. Four of the six are maintenance work. Somebody has to hold the known-good logic, know which revision is current, know which sites share a build, exercise the manual procedure, and be able to prove when each of those things was last done.

The part nobody is discussing: what happens to maintenance afterwards

Closing the door is correct. It is also not free, and the cost lands on the people who keep the plant running.

Remote access to those controllers was not put there by accident, and mostly not by carelessness. It was put there because a small utility with two operators and a service contract needed somebody to be able to look at a lift station at two in the morning without driving forty minutes to it. When the direct path is removed and replaced with a brokered, monitored, authenticated one, that is the right trade. But the first-order effect on maintenance is real: the fastest way anyone had to answer a question about a remote asset just got slower and more procedural.

So the utilities that come out of this well will be the ones that reduce their need to reach into the control system in the first place. That means having the answer before you need the device: the asset’s history, the last three work orders, the trend that preceded the last trip, the manual revision that matches the installed configuration, the part that actually fits, and the note the night shift left somewhere else. Almost none of that lives on the PLC. Almost all of it is what people were reaching for when they logged in.

There is a second-order effect too. Every one of the mitigations above generates recurring work: key-switch position checks, project-file comparisons, backup validation, credential rotation, manual-operation drills. That work has to be scheduled, assigned, evidenced, and produced on demand for a regulator or an insurer. It is maintenance work, and it will land on teams that are already the constraint. Black and Veatch’s 2026 Water Report, drawn from a survey of more than 600 United States water sector stakeholders, found that more than half of respondents, 55 percent, now outsource engineering and technical staff.

Adding intelligence without adding exposure

This is the question the incident actually poses for anyone selling software into water. It is not “does your product stop attacks”. It is “does connecting your product widen the surface I have just spent a quarter narrowing”.

The answer has to be architectural rather than reassuring, and it comes down to a distinction that is easy to state and easy to blur: reading operational evidence and being authorised to change plant behaviour are different privileges. A system can be granted the first without ever being granted the second, and the second can be absent by design rather than restricted by configuration.

FIG. 1

Add maintenance intelligence without adding control-system exposure

Figure 1. Add maintenance intelligence without adding control-system exposure. Three stacked zones. The top zone is plant control, drawn as a boundary and containing PLCs, SCADA control, the historian, and process equipment. A single downward one-way connector labelled read only, no write path leads to the second zone, maintenance intelligence, containing AIMMS, maintenance context, and repair guidance. A second downward connector labelled customer permission and approval leads to the third zone, permitted enterprise action, containing CMMS, inventory, suppliers, approvals, and procurement. Below all three, a struck-through dashed line marks the return path that does not exist: no path from enterprise action back to plant control.

The direction of every arrow is the argument. Evidence flows down out of the control zone and never flows back into it. AIMMS holds no write path to a PLC, DCS or SCADA system, and no ability to issue setpoints, restarts, interlocks or actuator commands, at any autonomy setting.

That shape matters more than it looks. In most integrations the read path and the write path are the same connection with different permissions attached, which means the boundary is a setting, and a setting is something that can be changed by whoever holds the console. A boundary that is structural cannot be reconfigured into a hazard by an administrator having a bad week.

What to do in the next month

Six things, in rough order of value, none of which require a purchase.

  1. Find out what is actually exposed. Not what the drawings say. Scan for it, including cellular-connected field sites, and include equipment installed by contractors and not recorded anywhere central.
  2. Get a known-good copy of every PLC program, dated, stored somewhere the plant network cannot reach, and compare the running logic against it. If you cannot say when this was last done for a given site, that is your answer.
  3. Ask your integrator what else shares this build. The FBI called out the third-party network pattern specifically. If the same arrangement is installed at eleven other utilities, your exposure is not just yours.
  4. Exercise manual operation on the assets that matter, and record how long it took and what was missing. This is the variable the FBI identified as separating outcomes.
  5. Write down who holds each of the recurring tasks the mitigations create, and where the evidence that they happened will live. Unowned recurring work does not happen.
  6. Decide what you would need in front of you at 2 a.m. if the screen were dark and the device untrustworthy. That list is your maintenance information problem, and it exists whether or not anyone attacks you.

Where AIMMS fits

EQUA AIMMS does not prevent cyberattacks and does not claim to. It sits on the other side of the boundary drawn above: it reads permitted maintenance evidence, helps a team understand a fault, and moves the digital work around the repair, in inventory, sourcing, approvals and records, under the customer’s own authority rules.

The reason it is relevant to this incident is narrower and more useful than a security claim. Reducing the number of reasons a person needs to reach into the control system is a security outcome achieved through maintenance, not through a control. A team that can answer its own questions from asset history, work records and documentation is a team that logs in to a controller less often, keeps a shorter list of standing access, and has the evidence trail for the recurring assurance work the advisory just created.

The alarm still belongs to SCADA. The physical work still belongs to qualified people. What has changed is that the path between them now needs to be deliberate.

Sources

Turn this idea into a facility-specific decision.

Bring one recurring failure or stuck workflow. The path is deliberately focused:

  1. 01

    Intake

    Complete a short qualification intake.

  2. 02

    Working session

    Map the delay and control boundary in 20 minutes.

  3. 03

    First-scope decision

    Decide whether a credible facility-specific first scope exists.

Book Your 20-Minute Assessment