Thirty Water Systems, Seven States, One Warning

Why OT cybersecurity assessments must examine operational exposure, lifecycle risk, engineering authority, and recovery capability. A water-treatment operator loses visibility into a remote facility.

The controller remains powered. The pumps, valves, and instruments are still physically present. But the operator can no longer communicate with the equipment, confirm its state, or control the process from the supervisory system.

At one facility, experienced personnel may be able to move to local or manual operation while engineers investigate.

Now imagine the same problem appearing across dozens of independently operated water systems within hours.

That is no longer an isolated equipment failure. It is a coordinated operational event.

On July 28, Minnesota disclosed that a cyberattack had targeted operational technology at more than 30 community water systems on July 26 and 27. Two days later, the FBI and Environmental Protection Agency reported incidents involving water and wastewater utilities in at least seven states. Some of the activities degraded water operations. Minnesota IT Services, FBI, and EPA alert

The importance of this event is not limited to the number of utilities targeted.

It demonstrates how common equipment, similar third-party architectures, direct internet exposure, and repeatable configuration weaknesses can allow an adversary to scale across geographically separated organizations.

The attackers operated as a coordinated campaign. The defenders were largely organized as individual utilities.

What has been confirmed

The FBI and EPA reported that malicious actors remotely accessed internet-facing programmable logic controllers, specifically Rockwell Automation MicroLogix 1100 and 1400 controllers.

After gaining access, the actors changed controller IP addresses and enabled or changed passwords. This caused operators to lose monitoring and control functionality.

At least one organization reported that it had modified PLC project files after discrepancies were found in ladder logic across several locations. The agencies also reported operational consequences, including a loss of water pressure and flooding.

The impact varied depending on the controller’s function, the connected equipment, and the utility’s ability to switch to manual operation. A controller used solely for monitoring produces a different outcome than one that directly controls pumps, valves, or treatment processes.

Not every affected utility experienced the same outcome.

In Braham, Minnesota, operating controls supporting the well and treatment plant were reportedly shut down. The community temporarily relied on water stored in its tower, but officials reported no water-quality impact.

Plymouth lost communications with parts of its water infrastructure, but crews continued operating the system. South St. Paul reported that certain automated controls were affected, yet established contingency procedures allowed water and wastewater operations to continue normally. Associated Press, South St. Paul incident update

These outcomes reinforce an important OT principle:

A cyber compromise does not automatically become a public-safety crisis. The final consequence is shaped by the physical process, engineering safeguards, local storage, operator capability, independent controls, recovery procedures, and the ability to continue operating when automation becomes unavailable.

These controllers are not at the same lifecycle stage

It would be easy to describe both affected controller families simply as legacy or end-of-life. That would not be technically accurate.

The MicroLogix 1100 family is discontinued. Rockwell Automation states that it has not been available for sale since April 30, 2022, and recommends migration to a newer control platform. Rockwell Automation: MicroLogix 1100

The MicroLogix 1400 is an older platform, but Rockwell currently classifies it as Active Mature. It remains available and supported, although it is not a current-generation control platform. Rockwell Automation: MicroLogix 1400

This distinction matters.

Lifecycle status should be part of the risk decision, but product age alone does not explain the incident. A supported controller directly exposed to the internet can represent a greater immediate risk than a discontinued controller isolated behind effective architecture and access controls.

The core problem was not simply that the equipment was old.

The problem was that operational authority was reachable from an untrusted network.

An assessment must examine the environment, not only the product

My recommendation is that utilities treat this event as a reason to conduct an engineering-informed OT cybersecurity assessment, not merely a search for two controller models.

Searching the asset list for MicroLogix 1100 and 1400 controllers is necessary, but it is not sufficient.

A useful assessment must determine:

• What operational function does each controller perform?
• Whether it monitors equipment or directly controls it.
• How the controller can be reached.
• Whether direct internet or cellular exposure exists.
• Which engineering workstations can modify it?
• Who has remote access and through which pathway?
• Whether the controller is left in a remotely programmable mode.
• Whether the running logic matches an approved baseline.
• What happens to the process if communications are lost?
• Whether the system can be operated manually.
• Whether the device is supported, mature, discontinued, or unsupported.
• Whether the same architecture has been repeated at other sites.

That is the difference between an asset inventory and an operational risk assessment.

The inventory tells us that a controller exists. The assessment tells us whether compromising it can interrupt an essential service.

Discovery must be appropriate for OT

An assessment should not begin with indiscriminate active scanning.

Many industrial environments contain equipment that was never designed to respond safely to aggressive discovery techniques. Some devices have limited processing capacity. Others communicate through serial protocols, gateways, or proprietary networks. Some field assets lack an Ethernet interface or an operating system that a conventional IT scanner can interrogate.

Asset discovery should therefore combine several methods:

• Existing engineering and maintenance records.
• Network diagrams and control narratives.
• PLC, HMI, historian, and engineering project files.
• Passive network observation where appropriate.
• Switch, firewall, router, and cellular-modem configurations.
• Interviews with operators, engineers, integrators, and maintenance personnel.
• Carefully approved targeted queries when technically safe.
• Physical verification of critical assets and communications pathways.

The goal is not to generate the largest possible device count.

The goal is to establish an accurate relationship between the asset, its connectivity, its operational function, and the consequences of failure.

Start with external pathways

The FBI and EPA specifically recommended removing PLCs from direct public internet exposure and mediating access through controlled gateways.

That recommendation should be treated as an immediate action, but it must be implemented with operational judgment.

Remote connectivity may be required for unmanned pumping stations, geographically distributed facilities, vendor support, alarm management, or emergency troubleshooting. The objective is not to eliminate every remote connection. It is to ensure that each connection is known, justified, authenticated, attributable, monitored, and removable.

My recommended assessment begins by identifying every external pathway, including:

• Publicly exposed PLC services.
• Cellular modems and industrial routers.
• Vendor-installed remote-access appliances.
• Remote desktop and virtual private network services.
• Cloud-connected gateways.
• Engineering laptops with multiple network interfaces.
• Temporary project connections that became permanent.
• Connections installed by integrators outside the standard firewall architecture.

Every pathway should have an accountable owner and a documented operational purpose.

If no one can explain why a connection exists, who uses it, and how it can be disabled safely, it should not be treated as an accepted part of the architecture.

The third-party architecture is part of the assessment

One of the most important findings in the FBI alert was that similarities in third-party network setups may have enabled attackers to replicate their success across multiple customers.

This is a significant supply-chain and architectural concern.

Utilities depend on automation integrators, equipment manufacturers, communication providers, and specialized service companies. Smaller operators may rely on them for most controller programming and remote support.

That support is often essential. The risk appears when the same exposed design, credential practice, modem configuration, or remote-access method is reused across many customers. A trusted provider can still deploy an architecture that creates shared risk.

The assessment should therefore determine whether:

• Credentials are unique to each customer and location.
• Remote pathways are shared across multiple utilities.
• A provider can access multiple customers through a single platform.
• Customer environments use repeatable public-facing configurations.
• Remote sessions are logged and attributable.
• Access remains active after project completion.
• The provider maintains and tests incident-notification procedures.
• The provider's engineering backups are protected and current.
• Contractual responsibility matches the actual technical architecture.

The question is not only, “Do we trust the integrator?”

The stronger question is, “If one customer’s configuration becomes known, can the same method be used against the others?”

Known-good logic is a resilience requirement

Changing an IP address or password can lock an operator out. Changing controller logic raises a more difficult question: Can the utility prove that the process is still running, as approved by program engineering?

A project file stored on an engineering laptop is not, by itself, a known-good backup. It may be outdated, incomplete, or already contain an unauthorized change.

Critical PLC and HMI projects should have:

• An approved and dated baseline.
• An accountable engineering owner.
• Controlled change authorization.
• Version history.
• Integrity verification.
• Protected offline or isolated copies.
• Documented restoration procedures.
• Evidence that restoration has been tested.

Following a suspected compromise, engineers should compare the running project with the approved baseline. That comparison should include ladder logic, reusable code, input and output mappings, communication settings, alarm functions, permissives, and interlocks.

A backup must also be validated before restoration. Restoring a compromised or incorrect project can reintroduce the problem or create a new operational hazard.

Manual operation must be assessed, not assumed

The FBI and EPA advised utilities to maintain and practice the ability to operate OT systems manually.

Manual operation should not be treated as an informal fallback dependent on whoever happens to be on shift.

A credible assessment should determine:

• Which functions can be operated manually?
• Which functions require local presence?
• Which independent process indications remain available?
• How long can manual operations be sustained?
• Whether staffing is sufficient for extended operation.
• How operators will coordinate across remote facilities.
• Which automatic safeguards remain active?
• What conditions require a controlled shutdown?
• How the organization returns to automation safely.

The Minnesota examples show why this matters. Where automated control or communication was affected, local personnel and contingency procedures helped maintain essential services.

Manual operation did not eliminate the cyber incident. It prevented the incident from resulting in more serious physical consequences.

Expert commentary reinforces the need for operational context

OT threat researcher Joe Slowik focused on the significance of disruption and changes affecting safety or protection parameters across multiple sites. His warning extends beyond Minnesota because similar technologies and architectures exist elsewhere.

Chris Day of Tenable described reports of systems being taken temporarily offline as an escalation from earlier activity. Cynthia Kaiser, a former senior FBI cyber official, assessed the events as consistent with previously reported Iranian-affiliated targeting. Claroty researcher Yhonatan Harari also considered Iranian involvement highly likely, while noting uncertainty about the responsible group. WIRED, Reuters

These assessments deserve attention, but attribution should not become the primary decision-making criterion for asset owners.

The public FBI and EPA alert does not formally attribute every incident to Iran or to a specific group. Regardless of who was responsible, the architectural weaknesses and operational consequences require action.

My recommended assessment outcome

The final deliverable should not be another long list of vulnerabilities.

It should provide a prioritized operational roadmap with four levels of action:

• Immediate containment: Remove direct exposure, secure remote access, change credentials, verify controller modes, preserve evidence, and validate running logic.
• Near-term risk reduction: Segment remote sites, secure cellular connectivity, establish configuration baselines, improve logging, and test manual operations.
• Program development: Strengthen asset governance, third-party access, incident response, backup validation, lifecycle management, and recurring exposure reviews.
• Capital planning: Replace unsupported equipment, redesign repeated weak architectures, modernize communications, and fund sustainable regional or shared security capabilities.

Every recommendation should identify an owner, an operational dependency, a target date, a required investment, and a temporary compensating control.

That is how an assessment connects the control room with the boardroom.

Attackers can scale. Defense must scale as well.

Minnesota responded through a whole-of-state model involving local utilities, state agencies, federal organizations, Tribal partners, and private-sector specialists.

That model should not be reserved for the next major incident.

Smaller utilities cannot each build a large OT security organization. They can, however, participate in shared capabilities for exposure assessment, threat interpretation, incident response, configuration assurance, training, and joint exercises.

Shared defense does not mean transferring control of the physical process to an external security organization.

Local operators and engineers must retain authority over operational decisions. External specialists should strengthen their visibility, preparation, and response capability.

The boardroom question is no longer whether the organization owns a cybersecurity product.

It is whether leaders know what is connected, what is exposed, what is critical, what is obsolete, who can make changes, whether approved logic can be restored, and whether operations can continue when automation is unavailable.

The MicroLogix 1100 is discontinued. The MicroLogix 1400 remains Active Mature. Both appeared in the FBI warning.

Their lifecycle status matters, but the larger lesson is architectural.

A controller should never be trusted simply because it remains supported, and it should not automatically be considered an immediate operational danger simply because it is old.

Risk depends on function, exposure, attack path, engineering dependencies, physical consequence, and recovery capability.

That is why the right response begins with an OT cybersecurity assessment grounded in operations, not with a scanner, a product replacement campaign, or another vulnerability list.