A water-system operator loses visibility into a remote pumping station.
The controller may still be running. The process may still be moving water. But the operator can no longer confirm the equipment state from the normal screen, and the credentials used to access the device no longer work.
The immediate questions are operational. Is pressure stable? Are pumps responding correctly? Can personnel reach the site? Is the controller logic still trustworthy? Can the utility continue manually, and for how long?
The wider question belongs in the boardroom. How did an external party reach the controller, and could the same pathway exist at every other site?
On July 30, the FBI and EPA provided a significant update on cyber activity targeting water and wastewater utilities. Since July 27, organizations in at least seven states have reported incidents involving internet-facing programmable logic controllers. Some activity degraded water operations.
The actors changed the controller's IP addresses and passwords, resulting in a loss of monitoring and control. Reported consequences included pressure loss and flooding. At least one organization identified modified PLC project files and ladder-logic discrepancies across several sites.
The agencies did not publicly attribute the campaign. That uncertainty should be respected.
But another confirmed detail deserves immediate leadership attention: similarities in network configurations provided by third parties may have enabled the attackers to repeat successful methods across multiple customers.
This turns an asset-level vulnerability into an architectural accountability problem.
Standardization can scale exposure
Industrial organizations depend on repeatable designs.
Utilities use common controller configurations, remote telemetry packages, cellular modems, engineering templates, firewall rules, and support arrangements. Standardization reduces engineering cost, accelerates deployment, and allows a limited workforce to support many locations.
Those benefits are real. The risk arises when the same design embeds an unmanaged external pathway, a reused credential practice, a permissive firewall rule, or a remotely changeable controller mode.
An attacker does not need to discover a unique method for every facility. Once a repeatable weakness is understood, the method can be applied across similar deployments.
The affected organizations may be operationally independent, but their technology and support arrangements can create a shared risk pattern. This is why the problem cannot be solved by looking at the controller alone.
Asset age is only one part of the equation
The FBI and EPA identified MicroLogix 1100 and 1400 controllers in the observed activity and recommended planning for end-of-life replacement.
Lifecycle management is important. Unsupported equipment poses long-term risks because updates, replacement components, and vendor support may be limited or unavailable.
But replacing hardware does not automatically correct an exposed architecture. A newer controller placed behind the same public-facing modem, a weak credential process, an unmanaged vendor connection, or a permissive access rule may reproduce the same operational risk.
CISA’s July 30 advisories reinforce this point. Newly disclosed vulnerabilities affect current-generation controllers, SCADA applications, terminal-loading systems, network platforms, and industrial communications libraries.
Legacy risk must be managed, but “replace the old PLC” is not a complete resilience strategy. The assessment must establish what the device controls, how it can be reached, who can change it, what independent protection remains available, and how the process will continue if the normal interface becomes unavailable.
Visibility is not the same as control
Many organizations have purchased discovery, inventory, or network-monitoring tools. These capabilities are valuable, but the presence of a tool does not prove that external exposure is understood.
A passive sensor may identify communications visible at a monitored point. It may not see a cellular modem connected at a remote enclosure, a temporary vendor appliance, a maintenance laptop, or an internet path that bypasses the expected network boundary.
External scanning can identify some public exposure. It cannot explain the operational function behind every address or determine whether disconnecting it will interrupt service.
The objective is not simply to generate a list of assets. It is to establish an accountable map of every pathway capable of reaching an operational function.
For each pathway, the operator should know:
- Why does it exist?
- Which assets can it reach?
- Who owns and approves it?
- How identity and privileges are controlled.
- Whether the activity is logged and reviewed.
- How can it be disabled?
- What operational capability is lost when it is removed?
That information must be validated jointly by operations, engineering, IT, cybersecurity, integrators, and service providers.
Controller integrity must become a routine discipline
The latest federal announcement goes beyond password changes. At least one affected organization reported modified project files and ladder-logic discrepancies.
That creates a more difficult recovery question. Restoring communications does not prove that the controller is running the approved logic. Reconnecting an HMI does not prove that the operator’s display accurately represents the process.
Critical controller projects should have verified known-good baselines. Changes should be attributable, approved, and periodically compared with the running configuration. Reusable logic, I/O configuration, communications settings, and operating mode should be included.
Backups also require validation. An available project file may be outdated, incomplete, or already contain an unauthorized change.
Recovery testing should therefore prove that the organization can identify the correct baseline, restore it using available engineering resources, validate the physical process, and return the system to service under controlled authority.
Manual operation is a resilience capability, not a slogan
The FBI and EPA emphasized the ability to operate manually.
Manual operation does not mean disabling control and protection systems or asking personnel to improvise unsafe actions. It means entering a planned degraded operating condition in which trained personnel use approved procedures, local instrumentation, communications, and field controls while independent safety and mechanical protection layers remain available.
The feasibility differs by process.
A small pumping station may permit sustained local operation. A complex treatment plant may require more personnel, tighter operating limits, or a controlled shutdown. Some processes cannot be operated safely for long without the normal view.
That boundary must be established before an incident.
Exercises should test loss of view, suspected project modification, inaccessible remote sites, unreliable communications, unavailable contractors, and extended restoration periods. They should identify the minimum staffing, instrumentation, procedures, and decision authority required to protect people, service, equipment, and the environment.
The boardroom owns repeatable risk
Executives do not need to approve firewall rules or review ladder logic.
They do need assurance that standard designs do not distribute the same uncontrolled exposure across the enterprise.
Leadership should require evidence that external pathways are inventoried, controller projects are baselined, vendor access is attributable, lifecycle risks are funded, and manual operation and recovery have been exercised.
Service-provider contracts should clearly assign responsibility for secure configuration, credential ownership, logging, vulnerability notification, project backups, incident support, and removal of temporary access.
The most important metric is not how many devices were discovered.
It is the number of critical operational pathways that have been verified as necessary, controlled, monitored, recoverable, and accountable to a named owner.
Resilience must scale as efficiently as the threat
The multi-state water activity demonstrates that attackers can reuse a successful method across many small operators. Defenders must be able to scale as well.
That may require shared regional expertise, common secure design requirements, coordinated incident support, configuration-integrity services, and exercises involving utilities, integrators, government partners, and specialist responders.
Local operators must retain operational authority. Shared defense should strengthen its ability to exercise it.
The central lesson is straightforward.
A controller should never be reachable merely because remote access was convenient during installation. A repeated design should never be trusted merely because it has been deployed many times. A backup should never be considered recoverable until it has been validated.
When a single remote pathway can become seven states of operational risk, architecture is no longer merely an engineering decision. It is an executive responsibility.