How exposed industrial controllers are turning America’s smallest utilities into targets in a much larger cyber conflict
By Jonathan Brown
On July 30, the Federal Bureau of Investigation and the Environmental Protection Agency issued a warning whose most disturbing feature was not the novelty of the technology involved but its familiarity. Since July 27, water and wastewater utilities in at least seven states had reported cyber incidents involving internet-facing programmable logic controllers, specifically Rockwell Automation/Allen-Bradley MicroLogix 1100 and 1400 PLCs. Attackers had remotely accessed the devices, changed IP addresses and passwords, and in some cases deprived operators of monitoring or control. At one organization, investigators found altered PLC project files after discrepancies appeared in ladder logic at several sites. The operational consequences described by federal authorities included loss of water pressure and flooding.
For anyone still inclined to think of cybersecurity principally as a contest over information—stolen correspondence, compromised financial records, encrypted databases—the warning offers a useful correction. A compromised email server may reveal what people have written, and a compromised accounting system may expose money, but a compromised PLC can alter what machinery actually does. The pump does not know whether the instruction to stop originated with an authorized engineer, an extortionist, an ideological hacker or an intelligence officer sitting halfway around the world. It knows only that the controller issued the instruction, and the physical process responds accordingly. That is the point at which cybersecurity ceases to be merely a problem of computers and becomes a problem of infrastructure.
Two related but analytically distinct stories are unfolding around American industrial systems. The first is an attributed campaign. The FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command and Treasury have warned that Iranian-affiliated actors are actively targeting internet-connected PLCs across U.S. critical infrastructure, including water and wastewater systems, government facilities and energy organizations. Federal investigators have documented activity involving Rockwell Automation, Schneider Electric and Siemens equipment, including theft and modification of PLC project files, manipulation of HMI and SCADA displays, interference with controller functions and, in some instances, operational disruption and financial loss.
The second story is the July wave involving MicroLogix 1100 and 1400 controllers at water utilities in at least seven states. The FBI and EPA described those intruders only as malicious cyber actors; they did not attribute that particular series of incidents to Iran. Minnesota, where operational technology at more than thirty community water systems was targeted during July 26 and 27, has likewise declined to name an actor and has cautioned that investigators have not established that every affected system was necessarily touched by the same perpetrator. Similar technology, similar victims and even similar operational effects do not establish common authorship, and the temptation to collapse every industrial intrusion into a single geopolitical narrative should be resisted.
The attribution uncertainty does not, however, diminish the architectural fact shared by both stories. Industrial computers capable of affecting physical processes are reachable from a global network populated by people who should never be permitted to communicate with them. Once that condition exists, the attacker does not always need to identify the water utility first and then devise a way into it. The order of operations can be reversed: discover the exposed controller, identify its make and model, determine what services it presents, and only afterward learn which physical system and which community sit behind it. In that sense, the Internet itself has become a reconnaissance platform for locating pieces of physical infrastructure.
A programmable logic controller is a relatively small industrial computer designed to perform control tasks reliably for years in environments where ordinary office systems would be unsuitable. It repeatedly reads inputs, evaluates programmed logic and updates outputs. Those inputs may represent tank level, pressure, flow, temperature, motor state or switch position; the outputs may operate pumps, valves, relays, motors, alarms and other equipment. In a water system, one PLC may monitor the level of an elevated storage tank and start a pump when the level drops below a prescribed threshold. Another may maintain pressure in a distribution zone. Another may control a wastewater lift station. Others may participate in filtration, chemical treatment or remote well operations.
The importance of these devices lies less in their computational power than in their relationship to the physical world. Software decisions inside the controller become physical actions outside it. A line of logic that energizes an output can start a pump. A setpoint can influence pressure. A timer can determine how long a motor runs. An interlock can prevent equipment from operating under unsafe conditions. The PLC therefore occupies an unusual position in computing: it is not merely storing a representation of reality but participating directly in the mechanisms by which that reality is managed.
The Rockwell MicroLogix family illustrates why the industrial world became networked in the first place. The MicroLogix 1400 expanded upon the networking capabilities of the 1100 and supported Ethernet communications and industrial protocols that made integration and remote monitoring more practical. Those were not frivolous conveniences. Water infrastructure is geographically distributed; wells, tanks, pumping stations and lift stations may be separated by miles, and sending an employee to every remote site merely to read a value or reset a device can be inefficient, slow and expensive. Remote visibility and control solved genuine operational problems.
The security failure occurred when remote connectivity became equivalent to public reachability. A connection designed so that a utility engineer could see a distant pump at two in the morning could, if poorly architected, also create a path through which an unknown person on another continent could reach the same controller. Rockwell’s own security guidance is explicit that industrial controllers should not be exposed directly to the public Internet, that unnecessary ports should be closed, and that operational-technology networks should employ segmentation and defense in depth. Yet federal agencies are now responding to precisely the condition the manufacturer says should not exist.
Industrial-security advisories frequently use the phrase “loss of view,” which sounds almost bureaucratic until one considers what it means operationally. A water plant depends heavily on an operator’s ability to understand what the physical process is doing, and that understanding is usually mediated through a human-machine interface, or HMI, and, in larger systems, through supervisory control and data acquisition. Tank level, flow, pressure, pump state, valve position and alarm conditions become gauges, diagrams, colors and numerical values on a screen. The display is not the process itself, but for the person supervising the process it is the principal means by which the system becomes intelligible.
If the process changes and the operator can see it, intervention may still be possible. If visibility disappears, intervention becomes slower and more uncertain. More troubling still, if the displayed information itself is falsified, the operator may respond rationally to a false representation of reality. Federal investigators say the Iranian-affiliated campaign has included manipulation of information displayed on HMI and SCADA systems, along with modification and deletion of PLC logic and interference with shutdown and alarm functions. An industrial defender therefore has to protect two different kinds of integrity: process integrity, meaning that the controller is executing the intended logic, and observational integrity, meaning that the operator’s display accurately represents what the process is doing. A system cannot reasonably be called trustworthy unless both remain intact.
The problem becomes clearer when one looks at ladder logic, one of the best-known forms of PLC programming. Ladder logic takes its visual form from traditional electrical relay diagrams: horizontal rungs sit between two vertical rails, and conditions and outputs are arranged in relationships that industrial electricians and controls engineers can interpret quickly. At its simplest, a rung may express something conceptually straightforward: if the tank level is low, the pump is available, the system is in automatic mode and no safety interlock is active, then run the pump. Real programs can be vastly more complicated, incorporating analog calculations, timers, counters, alarms, permissives, shutdown conditions, reusable instructions and elaborate sequencing.
What matters is that ladder logic embodies operational intent. It is the formal expression of what engineers and operators have decided the machinery should do. Altering that logic therefore changes the rules under which the plant behaves. The July 22 update to the federal advisory on Iranian-affiliated PLC activity contains a particularly revealing example. At one U.S. victim, investigators found that an attacker had downloaded a malicious project file into a PLC using ordinary engineering software. The replacement file retained enough of the original ladder logic for downstream functionality to continue while adding logic that overrode particular instructions responsible for maintaining safe operating parameters.
That is more subtle than simply crashing the controller. A failed PLC announces itself, and an operator is likely to investigate immediately. A controller that continues functioning while obeying altered safety assumptions may be much harder to recognize as compromised. Most of the project remains legitimate, much as most of a legal contract can remain intact after a single consequential clause has been rewritten. The danger resides not in the destruction of the document but in the small portion that changes its meaning.
This leads to one of the most important characteristics of operational-technology attacks: an intruder may not require custom malware at all. Industrial engineering environments already contain powerful software because legitimate engineers must be able to upload and download controller programs, alter parameters, inspect logic, diagnose equipment and place machinery into different operating states. Federal investigators have observed Iranian-affiliated actors using legitimate products such as Rockwell Automation Studio 5000 Logix Designer, Schneider Electric EcoStruxure Control Expert and Siemens TIA Portal from leased infrastructure to obtain PLC project files from victim systems.
In such circumstances, maliciousness does not necessarily reside in the software. It resides in the authority of the person using it. A legitimate engineer may connect to a controller and retrieve a project file; an attacker may establish the same connection and perform the same action. At the level of protocol syntax, both operations may be perfectly valid. The distinction lies in whether the person behind the transaction is entitled to exercise that authority. Industrial security therefore cannot be reduced to identifying malformed packets or suspicious executables. A sufficiently successful attacker may be dangerous precisely because he can operate through the same interfaces and tools that legitimate personnel use every day.
The Internet has also changed the economics of selecting a victim. Traditionally, an attacker interested in a particular industrial facility had to begin with that facility. He needed to know what the organization operated, what technology it used, how the equipment communicated and where the relevant systems were located. Reconnaissance preceded access. Internet exposure reverses that sequence. Federal reporting on Iranian-affiliated activity describes actors using foreign IP addresses and leased infrastructure to reach internet-facing PLCs and industrial communications services from several manufacturers. Rather than asking how to penetrate a particular water utility, an attacker can begin by searching for a class of controller and then determine what organization owns the device after it responds.
That reversal is strategically significant because it undermines obscurity. A small town may have no geopolitical importance whatsoever, but its exposed MicroLogix controller still presents itself as a MicroLogix controller. The attacker need not know that the IP address belongs to a water system when reconnaissance begins. The equipment itself can become the first clue to the victim’s identity. In effect, the vulnerability begins selecting targets for the adversary, because every identically exposed implementation becomes another candidate for the same method.
Minnesota demonstrated how quickly such a method can multiply. During July 26 and 27, malicious activity targeted operational technology at more than thirty community water systems. State authorities activated a coordinated response involving local utilities, Minnesota agencies, CISA, EPA and the FBI. Officials were careful to distinguish compromise of technology from interruption of water service: most confirmed cases involved systems used to remotely monitor or control equipment, including PLCs and HMIs, but not every community lost drinking-water service. Minnesota also declined to attribute the activity and said investigators had not established that every incident belonged to the same perpetrator.
Those qualifications matter, but they do not make the underlying episode less consequential. Someone was able to reach operational technology across more than thirty community systems during a remarkably short period. The FBI’s subsequent warning suggests one mechanism by which this scale can occur: investigators found similarities in network arrangements provided by third parties across multiple victims, and warned that repeated configurations and shared hardware can allow an attacker to apply a successful technique across many customers.
This is supply-chain risk in an underappreciated form. The supplier does not need to distribute poisoned software, and the integrator does not need to be compromised. A third party can unintentionally distribute architecture. If twenty utilities are equipped with essentially the same remote-access model, modem configuration or firewall policy, an attacker who understands one installation may immediately understand something important about the others. Standardization normally lowers operating costs and simplifies maintenance; when the standardized element is a security weakness, it can also lower the cost of attacking the entire customer base.
For small utilities, this is especially difficult because outside integrators are often indispensable. A community water system may not employ its own controls engineer, network architect and cybersecurity specialist. It hires expertise as needed. The integrator designs the panel, programs the PLC, configures the communications and may provide long-term remote maintenance. None of those arrangements is inherently unsafe, but they create common trust relationships that deserve the same scrutiny normally applied to software dependencies. The relevant question is no longer merely what equipment a vendor installed, but what path of authority its design created and who is capable of traversing it.
American water infrastructure is particularly challenging because it is so decentralized. A major metropolitan utility may employ dedicated security personnel, network engineers and sophisticated operational teams. A small community system may have only a handful of employees, supported by contractors whose primary expertise is treatment, electrical work or automation. EPA has acknowledged for years that smaller systems often lack the resources for dedicated cybersecurity staff. Yet the industrial process does not become less physical because fewer people depend on it. A small utility still has pumps, pressure zones, tanks, wastewater systems and customers who expect water to appear when they open a faucet.
This produces a fundamental asymmetry in national infrastructure defense. Part of the country’s critical infrastructure is administered by organizations with local-government resources while being exposed to adversaries that operate at Internet scale. A malicious actor can scan immense address ranges automatically, while the defender may have one person responsible for everything from chemical feed pumps to desktop support. Once an attack method becomes repeatable, the marginal cost of attacking the thirty-first small utility may be little greater than that of attacking the first.
The current events did not arrive without warning. EPA has repeatedly warned that cyber incidents affecting community water systems were increasing in frequency and severity and that attacks against operational technology could interrupt treatment, distribution and storage, damage pumps and valves, or interfere with chemical processes. Inspections have revealed elementary weaknesses such as default passwords, shared accounts, credentials retained after employees left and incomplete risk planning. These findings are important because they expose an uncomfortable truth about advanced adversaries: sophistication is valuable only when the target requires it. An intelligence service capable of developing custom malware is still perfectly capable of trying a weak password first, and an unsophisticated hacktivist can still cause trouble if a controller accepts direct connections from the public Internet.
The present Iranian campaign also has an important antecedent. Beginning in 2023, the IRGC-affiliated group commonly known as CyberAv3ngers targeted Unitronics PLCs and HMIs used by American water utilities and other critical-infrastructure organizations. Federal agencies now say that campaign compromised at least seventy-five devices and involved replacement of legitimate PLC logic with malicious code. The significance of that history is not that the July MicroLogix incidents should automatically be attributed to Iran—they have not been—but that hostile state-linked actors have already demonstrated their understanding of the strategic value of directly reachable industrial equipment.
The current Iranian-affiliated activity is broader. Federal reporting now describes targeting across Rockwell, Schneider and Siemens systems, together with theft of engineering projects, modification of logic, manipulation of operator displays and interference with alarm and shutdown behavior. This begins to look less like curiosity about a particular manufacturer and more like a generalized operational method: discover exposed industrial equipment, obtain the engineering project, understand enough of the process to identify useful points of influence, and alter behavior when doing so serves the attacker’s objective. That is a more durable capability than any single exploit because it rests on the architecture of industrial connectivity itself.
The physical consequences can also be less theatrical than popular imagination expects. One of the effects reported in the July FBI/EPA warning was loss of water pressure; another was flooding. Pressure loss does not sound dramatic until one understands that pressurized distribution systems are designed in part to keep contamination outside the pipe. When pressure falls substantially, cracks, joints or damaged infrastructure can create conditions under which untreated groundwater or other contaminants enter the system. An attacker does not have to “poison the water” directly if he can alter the physical conditions that normally keep contamination out.
This is characteristic of cyber-physical attacks. The digital action may be very small while the final consequence is produced by hydraulics, chemistry, gravity or machinery. Stop a pump, change a setpoint, disable an alarm or prevent the operator from seeing the state of equipment, and the physical system supplies the rest. The computer does not merely contain data about the plant; it participates in governing the plant. That is why the proper object of protection is ultimately not the PLC itself but the process whose behavior the PLC can influence.
One of the most revealing recommendations in the federal guidance is also one of the least glamorous: preserve the ability to operate manually. The FBI and EPA note that the practical effect of an incident can depend heavily on whether operators can shift to local or manual control. They recommend maintaining and exercising fail-safe mechanisms, manual controls, islanding capabilities, backups and standby systems. This can sound like technological regression, but it is better understood as independence. A local control mechanism or physically present operator may provide a way to sustain essential service when the networked control environment has become untrustworthy.
The value of that manual alternative lies in the fact that it fails differently. A second HMI connected to the same compromised network may not provide meaningful independence. A backup server joined to the same administrative domain may not either. A redundant controller reached through the same exposed modem can reproduce the same weakness. A local switch, independent safety system or manual operating procedure may survive precisely because the attacker cannot reach it through the digital path he has compromised. Cyber resilience sometimes requires preserving technologies or procedures that appear inefficient in normal operation because their inefficiency is also what makes them independent.
Federal recommendations concerning controller operating modes illustrate the same principle. Where supported, agencies advise utilities to place PLCs in run mode after programming so that remote changes to logic or firmware are restricted. The strategic elegance of such a control is easy to overlook. An adversary may possess sophisticated tools, rented infrastructure, valid credentials and detailed knowledge of the controller, yet a physical mode selector inside a locked cabinet can still deny one of the most consequential operations. The security control succeeds because it occupies a different domain from the attack.
There is, however, a crucial caveat. Federal agencies warn operators to validate the project before locking the controller into run mode. If malicious logic has already been loaded, preventing additional modification simply preserves the compromised state. This distinction captures the difficulty of industrial incident response. Blocking the attacker does not restore trust. After credible compromise, defenders may need to determine whether the project file is correct, whether ladder logic matches the engineering baseline, whether reusable instructions or alarm limits were changed, whether HMI displays remain accurate, whether modems and engineering workstations have also been compromised, and whether the available backups predate the intrusion.
The problem is not limited to controllers. Remote industrial systems frequently rely on cellular connections because dedicated communications to every well, tank, pump station or lift station would be prohibitively expensive. The actual edge of an OT environment may therefore be a small cellular modem mounted in a cabinet miles from the treatment plant. Federal investigators have observed Iranian-affiliated actors targeting modems over SSH, including use of Dropbear SSH on victim equipment, and have consequently urged utilities to harden cellular gateways, change default credentials, enable logging, update firmware and employ more controlled architectures such as private APNs and VPNs.
This is where asset inventory becomes much more than administrative housekeeping. The utility must know that the modem exists, who owns it, who configured it, which credentials administer it, whether it accepts inbound connections, what network sits behind it, whether its activity is logged and what operational function disappears if it is disconnected. A beautifully drawn network diagram of the central treatment plant is irrelevant if a second, undocumented route enters through a cellular gateway at a remote pumping station. Adversaries do not attack the architecture an organization believes it has; they attack the architecture that actually exists.
The first layer of remediation is therefore simple in principle even when implementation is difficult. PLCs should not be directly reachable from the public Internet. Remote access should terminate at controlled gateways or jump hosts. Communications should be restricted to expected endpoints. Strong authentication should be required, with multifactor authentication applied at the VPN or gateway layer where the controller itself cannot support it. Cellular equipment should be hardened and monitored, operational networks segmented from enterprise environments, and obsolete devices modernized or isolated behind compensating controls.
Yet “put a firewall in front of it” is not a complete industrial-security strategy. These systems can remain in service for decades. Documentation may be incomplete. The engineer who designed the original architecture may have retired. A vendor may genuinely require remote access. Firmware changes may require downtime. Replacing an obsolete controller may mean rewriting logic, recommissioning I/O, modifying electrical panels and validating the process under live conditions. A hurried security intervention can itself create operational risk. The correct instruction is therefore not simply to disconnect the controller but to remove unsafe public exposure while preserving a controlled, tested and supportable means of legitimate access.
That requires collaboration between disciplines that organizations too often separate. Cybersecurity personnel understand adversaries, identity, logging and network control; plant operators understand the physical process; controls engineers understand the PLC; vendors understand the equipment; management understands the operational constraints. A security architecture that ignores any one of those perspectives is likely to be either insecure or impractical. Industrial cybersecurity has matured to the point at which it can no longer be treated as an IT overlay applied to machinery. It is an engineering problem involving hostile conditions.
Many of the systems now under scrutiny were developed under assumptions very different from those governing modern public-facing computing. Traditional industrial networks lived inside plants and other controlled facilities. Someone capable of reaching the PLC was likely to be an engineer or technician, and the communications environment itself therefore carried an implicit element of trust. Protocols could be designed around the assumption that reachability implied authority because physical and network access were closely related.
The Internet abolished that premise. A protocol that remains perfectly acceptable on a restricted plant network can become dangerous when exposed globally because the controller may lack the authentication, logging, rate limiting and other defensive characteristics expected of a modern Internet service. In such cases, it can be misleading to describe the problem solely as a vulnerability in the PLC. The controller may be doing exactly what its designers intended: accepting an engineering connection, loading a project, changing a parameter or answering a request. The more fundamental weakness may be that the architecture allowed an untrusted person to reach the interface in the first place.
This is why attribution, although important, is ultimately secondary to architecture from the defender’s perspective. If Iran conducted a particular attack, that matters for national policy and intelligence. If a ransomware affiliate did it, that matters for law enforcement. If a hacktivist did it, motive and capability differ again. But none of those outcomes makes direct public exposure of industrial controllers acceptable. Attribution tells us who exploited the architecture; defense has to explain why the architecture made exploitation possible.
The deeper strategic problem is the enormous asymmetry between digital action and physical recovery. A water utility represents decades of investment in pumps, tanks, treatment systems, piping, laboratories, electrical equipment, trained operators and accumulated engineering knowledge. An attacker may require little more than rented infrastructure, a scanner and a usable path into a controller. Changing a password can take seconds; restoring access to a remote site may require sending a technician. Modifying logic may take minutes; determining exactly what changed may consume hours of engineering analysis. Disabling visibility can be trivial; operating safely without it may require manual staffing and repeated physical inspection.
The attacker’s action is digital, while the defender’s recovery is often physical. That asymmetry is one reason modest cyber capabilities can create disproportionate infrastructure consequences. An attacker need not destroy a plant to impose serious cost. It may be enough to make the operators uncertain whether the plant can still be trusted. A rational utility may stop an automated function not because it knows the equipment has been altered, but because it cannot establish that it has not. In critical infrastructure, uncertainty itself has operational value to the attacker.
This is also why ordinary backups are insufficient. Industrial organizations need known-good engineering baselines. A controller project file is useful after compromise only if the utility can establish that it represents the intended process. The same is true of HMI projects, network configurations, reusable instructions, firmware versions and alarm settings. A backup created after an attacker modified the logic may be a perfect copy of the wrong thing.
Industrial recovery therefore requires provenance. Who changed the program, when was it changed, why was the modification authorized, and does the file on the engineering workstation actually match what is running in the PLC? Is the latest backup older than the intrusion? Have reusable instructions changed? Are alarm limits still correct? These questions cannot be answered by malware scanning alone. They require engineering records, configuration control and people capable of understanding what the process is supposed to do. Backups preserve bytes; resilience requires preserving knowledge of what those bytes mean.
Water is presently the most visible example because operational effects are being publicly documented, but there is nothing uniquely watery about the underlying problem. PLCs operate manufacturing equipment, energy systems, building automation, conveyors, compressors, pumps and valves throughout the physical economy. Human-machine interfaces, engineering workstations, cellular gateways and remote-access mechanisms appear across these sectors as well. Any device that converts digital authority into physical behavior deserves particular scrutiny once it becomes externally reachable.
The most useful question for an infrastructure operator is therefore not why Iran, Russia, a criminal group or a hacktivist would care about a particular water plant. Perhaps none of them does. The more important question is whether any of them can reach the system tomorrow. Interest can be discovered after access. A device does not need to be strategically famous in order to become strategically useful once an adversary learns what it controls.
For most Americans, the water system is effectively invisible. One turns a handle and water appears. Behind that simple act lies an extensive physical and institutional apparatus of wells, reservoirs, treatment systems, chemicals, pumps, tanks, pipes, laboratories, regulators, maintenance crews and operators. During the past several decades another layer has been added: industrial computing, which allows those systems to be monitored and controlled across distance. That layer has made infrastructure more efficient, more observable and often more reliable. It has also created a new border between the physical plant and the outside world.
Too often, that border was designed during an era when the person on the other side of the connection was presumed to be an engineer. That assumption no longer survives contact with the modern Internet. Federal agencies say attackers have reached water-sector PLCs across multiple states and produced loss of pressure, flooding and loss of monitoring or control. Minnesota says operational technology at more than thirty community water systems was targeted during one coordinated episode. Iranian-affiliated actors have been observed stealing PLC projects, modifying logic, manipulating operator displays and interfering with alarm and shutdown functions. An earlier IRGC-affiliated campaign compromised scores of industrial devices. Manufacturers themselves continue to warn that controllers should not be exposed directly to the public Internet.
None of this requires embellishment. The facts are sufficiently unsettling as they stand. The United States spent decades connecting physical infrastructure because connectivity made that infrastructure easier and cheaper to operate. The unfinished portion of that project is now becoming painfully visible: connectivity must not silently transfer operational authority to anyone capable of discovering the endpoint.
Solving the problem will require better segmentation, stronger authentication, accurate asset inventories, hardened remote access, trustworthy engineering baselines and modernization of equipment whose useful life has outlasted the security assumptions under which it was deployed. It will require closer scrutiny of integrators and third-party architectures, better protection of cellular gateways and engineering workstations, and deliberate preservation of manual capabilities where they offer genuine independence. Most of all, it will require abandoning the comforting idea that an industrial computer is protected merely because the machinery it controls sits behind a fence.
A PLC can be mounted in a locked cabinet beside a pump in a town most Americans have never heard of. Physically, it is inside the water plant. If the network gives the public Internet a route to it, however, the controller occupies another place as well: it is standing on one of the largest hostile networks humanity has ever constructed, advertising a pathway from software into machinery.
The Internet has begun to notice.
Jonathan Brown is a cybersecurity researcher and investigative journalist at bordercybergroup.com.
Member discussion: