The most unsettling thing about a cyberattack on a water system is not that it looks like science fiction. It is that, in many cases, it looks painfully ordinary. There is no cinematic countdown clock, no glowing map of an enemy command center, no exotic malware with a name that sounds like a weapon. Instead, the story often begins with a small municipal utility, a remote operator trying to check a pump station after hours, a programmable logic controller left reachable from the public internet, and a password that should have been changed years ago. Somewhere between the convenience of remote access and the hard realities of underfunded infrastructure, the machinery that keeps clean water flowing has become visible to the same internet that delivers email, streaming video, and automated scanning by threat actors.
That is the uncomfortable message behind the latest warnings from the U.S. Cybersecurity and Infrastructure Security Agency, which said in late July 2026 that it was observing a significant increase in cyber threat actors targeting programmable logic controllers in the water and wastewater sector. The warning was not abstract. Reuters reported that more than 30 Minnesota community water systems were targeted on July 26 and 27, while the FBI said water and wastewater utilities in at least seven states had reported incidents, with some activity degrading water operations. In some cases, attackers reportedly changed passwords, locked out operators, disconnected devices from networks, and forced facilities into boil-water notices or sustained manual operation.
For the public, the phrase “PLC attack” may sound remote and technical, like something buried deep inside an engineering department. But a programmable logic controller is not an obscure accessory. It is one of the small, rugged computers that quietly sits between software and the physical world. In a water facility, a PLC may start and stop pumps, open valves, pace chemical dosing, read tank levels, gather compliance data, or trigger alarms when pressure or flow behaves unexpectedly. CISA’s earlier advisory on Unitronics PLC exploitation described precisely these functions, warning that unauthorized access to such devices threatens the ability of water and wastewater facilities to provide clean drinking water and manage wastewater safely.
The practical lesson is brutally simple: industrial controllers should not be placed directly on the internet. Yet that sentence conceals a complicated history of engineering culture, municipal economics, vendor defaults, emergency maintenance, and the long collision between operational technology and ordinary IT. Water utilities did not connect control systems to the network because they wanted to invite geopolitical actors, ransomware crews, or bored scanners into their pump houses. They did it because remote visibility saved money, because skilled operators were scarce, because small towns had to manage infrastructure spread over wide geography, and because a system that once lived behind locked doors gradually acquired cellular modems, web dashboards, remote desktop tools, vendor tunnels, and cloud-connected telemetry. The problem is not connectivity itself. The problem is connectivity without segmentation, authentication, monitoring, lifecycle management, and a sober recognition that the internet is hostile terrain.
The Hidden Computers Beneath Everyday Water
A modern water system is less like a pipe network and more like a distributed cyber-physical organism. Wells, reservoirs, lift stations, treatment basins, chemical feed systems, filters, disinfection units, storage tanks, and distribution pumps are all tied together by signals. Some signals report what is happening: a tank level, a chlorine residual, a pressure reading, a pump motor temperature. Others command something to happen: close this valve, run that pump, dose this chemical, sound that alarm. Between those measurements and actions sit PLCs, human-machine interfaces, supervisory control and data acquisition systems, remote telemetry units, historian databases, operator workstations, and increasingly, gateways that bridge operational technology networks with corporate IT and remote support.
The architecture was not born insecure so much as it was born in a different threat model. Early industrial control systems assumed physical separation. The people who could touch them were plant operators, instrumentation technicians, electrical engineers, or vendors standing inside the facility. Protocols such as Modbus, EtherNet/IP, DNP3, Profinet, and vendor-specific engineering channels were designed to be predictable, fast, and durable, not to withstand the constant pressure of global internet scanning. In a plant environment, a command to start a pump was expected to be issued by something trusted because the network itself was trusted. Authentication, encryption, and granular authorization were often secondary concerns or absent entirely, not because engineers were careless, but because the systems were optimized for uptime, determinism, and safety under physical operating constraints.
That old assumption has been eroding for decades. Remote operations became attractive as utilities tried to cover more assets with fewer people. Cellular routers made it easy to connect remote lift stations. Vendor support contracts encouraged remote diagnostics. Municipal IT teams, often already stretched thin, merged or bridged networks for convenience. Pandemic-era remote work accelerated some of these patterns across industries. The result is a layered environment where the control system may still be treated culturally as a plant asset, but technically it may now be discoverable, reachable, or indirectly accessible from far beyond the fence line.
Attackers understand this gap. They do not always need a zero-day exploit or a sophisticated implant. Sometimes they need only a search engine for exposed services, a vendor default credential, an unchanged factory password, an open engineering port, or a weak remote access service. CISA’s 2023 alert about Unitronics PLCs in water systems said the affected device was likely accessed through weaknesses including poor password security and exposure to the internet, and it specifically urged utilities to change the default Unitronics password, require multifactor authentication for remote access, disconnect PLCs from the open internet, place a firewall or VPN in front of remote access, and back up logic and configurations for rapid recovery.
This is why the current wave of warnings matters. The danger is not merely that a hacker can “get into a computer.” It is that the computer may be part of a feedback loop that turns cyber commands into physical consequences. A compromised business email account can leak invoices. A compromised PLC can change how a pump behaves, lock an operator out of a treatment process, interrupt telemetry, falsify a screen, or force a plant back to manual mode. Water systems are designed with safeguards, alarms, procedures, redundancy, and human operators, so compromise does not automatically equal catastrophe. But it can create confusion, operational stress, service disruption, public anxiety, and, in the worst case, unsafe conditions if layered protections fail.
From Air Gaps to Attack Surfaces
For years, industrial cybersecurity discussions were haunted by a comforting phrase: the air gap. The idea was that operational technology networks were separated from the internet by physical distance or network isolation. In some highly controlled environments, meaningful separation still exists. But in much of the real world, the air gap has become less a fact than a memory, a phrase repeated long after the architecture changed. A plant may have no intentional inbound internet connection to a PLC, yet a firewall rule, remote access appliance, vendor modem, misconfigured router, unmanaged switch, or forgotten cellular gateway can quietly create one. The most dangerous connection is often the one no one remembers approving.
The shift was driven by rational pressures. Water and wastewater utilities are not banks or hyperscale cloud companies. Many serve small communities with limited budgets, aging infrastructure, and small staffs responsible for everything from compliance reporting to emergency repairs after storms. A remote operator who can check an alarm from home may prevent an overflow. A vendor who can troubleshoot a controller remotely may save an expensive trip. A superintendent responsible for several pump stations may need visibility without driving for hours. In that setting, remote connectivity is not laziness; it is operational survival.
But security debt accumulates quietly. A VPN deployed years ago may no longer receive updates. A firewall rule added temporarily may become permanent. A contractor account may remain active after a project ends. A default password may survive because changing it risks breaking a vendor integration. A PLC may be kept in service long past its expected lifecycle because replacement funding is difficult to secure. When these choices are invisible to leadership and undocumented for operators, they turn into an attack surface that no single person fully understands.
The internet has also changed. Exposed industrial systems are no longer hidden by obscurity. Automated scanners constantly sweep public address space. Specialized search engines index banners, screenshots, open ports, and device fingerprints. Threat actors can identify exposed HMIs, SCADA servers, routers, VPN appliances, and PLC communication services at scale. Research on publicly accessible operational technology has repeatedly found large numbers of exposed systems using industrial protocols, outdated firmware, and identifying information useful to attackers. One recent academic analysis reported nearly 70,000 exposed OT devices globally and highlighted protocols such as Modbus TCP, EtherNet/IP, and Siemens S7 among the visible industrial landscape.
The uncomfortable truth is that exposure often matters more than exploit complexity. Industrial environments are full of specialized equipment, but the initial compromise may be mundane. A controller with a default credential does not require brilliant cryptanalysis. A remote access portal without multifactor authentication does not require a nation-state. An engineering workstation reachable through reused credentials may fall to the same password-spraying and phishing methods that plague ordinary enterprise IT. Once inside, however, the attacker is no longer playing in an ordinary enterprise. They may be standing at the edge of a physical process.
Why PLCs Are So Powerful—and So Fragile
A PLC is built for reliability, not glamour. It is a hardened industrial computer designed to run for years in electrical cabinets, pump houses, treatment plants, manufacturing lines, and energy facilities. It reads inputs from sensors and switches, runs control logic, and writes outputs to actuators, relays, drives, and valves. In many systems, it operates in scan cycles, repeatedly reading the state of the process, executing its program, and updating outputs. That rhythm is what makes automated infrastructure feel stable. A pump starts when a tank level drops. A valve closes when pressure rises. A chemical feeder adjusts when flow changes.
The same simplicity that makes PLCs dependable can make them difficult to secure. Many controllers were designed for environments where physical access implied authorization. Some legacy devices have limited processing power, limited memory, limited support for modern cryptography, and long patch cycles. Even newer controllers often need to preserve compatibility with decades of plant equipment and engineering workflows. Unlike laptops or servers, PLCs are not casually rebooted, patched, or replaced. A failed update can interrupt treatment, violate permits, damage equipment, or force operators into emergency procedures. In operational technology, “just patch it” is rarely a complete strategy.
The engineering software used to program PLCs adds another layer of risk. Logic files may represent years of site-specific knowledge: pump sequencing, chemical dosing constraints, alarm thresholds, interlocks, failover behavior, and manual override conditions. If an attacker can upload, download, alter, or erase that logic, the effect may be more damaging than simply crashing a computer. Even a small change in timing, setpoints, or alarm behavior can create confusion. Operators may see a process behaving oddly without immediately knowing whether the cause is mechanical failure, sensor drift, network outage, software bug, or malicious tampering.
This is why backups of PLC logic and configuration are so important. CISA’s Unitronics guidance emphasized backing up logic and configurations so utilities can restore devices quickly after compromise or ransomware-like lockout. That advice may sound routine, but in the field it can be transformative. A utility that has current offline backups, documented reset procedures, known-good firmware, spare hardware, and trained staff can treat a compromised PLC as a recoverable incident. A utility without those assets may spend precious hours reconstructing logic, calling vendors, searching old laptops, or trying to remember which version of a program actually runs the plant.
PLCs also sit at an awkward boundary between safety and security. Water systems usually contain physical safeguards and operational procedures that reduce the chance of immediate harm. Operators can switch to manual modes, isolate equipment, sample water, issue public notices, and coordinate with regulators. But those safeguards assume that people can see what is happening and retain enough control to respond. When attackers interfere with HMIs, passwords, communication links, or alarm paths, they do not need to destroy infrastructure to create risk. They need only reduce operator confidence at the moment when clear visibility matters most.
The Water Sector’s Uneven Cybersecurity Reality
The American water and wastewater sector is extraordinarily fragmented. It includes large metropolitan utilities with dedicated cybersecurity teams and sophisticated control centers, but it also includes thousands of small systems serving rural towns, subdivisions, tribal communities, schools, and industrial users. Many small utilities operate with thin staffing, tight rates, aging equipment, and a heavy regulatory load. Their mission is public health and environmental protection, not cybersecurity operations. Yet the internet does not grade on a curve. A tiny utility with one part-time operator can be scanned by the same adversaries that scan federal agencies and Fortune 500 companies.
This asymmetry is part of what makes water-sector cybersecurity so difficult. The systems are critical enough to attract attention but often too resource-constrained to defend like major financial institutions. A small utility may depend on a local integrator for control system changes, a regional vendor for telemetry, and municipal IT for email and network support. No one may own the full cyber-physical risk picture. When federal agencies issue guidance about network segmentation, multifactor authentication, asset inventories, backups, logging, and incident response, the recommendations are technically sound. The hard part is translating them into budgets, work orders, procurement language, maintenance windows, and operator habits.
CISA, EPA, and FBI have tried to push the sector toward practical defensive basics. Their joint “Top Cyber Actions for Securing Water Systems” guidance emphasizes reducing exposure to the public-facing internet, changing default passwords, conducting cybersecurity assessments, backing up systems, reducing vulnerability exposure, and preparing for incident response. Those are not glamorous measures, but they map directly to the weaknesses repeatedly exploited in real incidents.
The challenge is that “basic” does not mean easy. Network segmentation, for example, sounds straightforward until a utility discovers that its billing system, SCADA historian, remote alarm dialer, engineering workstation, vendor VPN, and operator laptops all evolved organically over years. Separating IT and OT networks may require new firewalls, redesigned routing, new remote access procedures, updated drawings, integrator support, and downtime planning. Multifactor authentication may be simple for cloud email but harder for legacy engineering tools or PLCs that do not support it directly. Replacing default passwords may require coordination across devices, vendors, HMIs, and scripts that silently depend on old credentials.
There is also a cultural divide. IT security teams often prioritize confidentiality, patching, identity management, and rapid change. OT teams prioritize safety, availability, process stability, and cautious change control. Neither side is wrong. The water sector needs both instincts. A security team that treats a treatment plant like an office network can create operational risk. An operations team that treats cybersecurity as an external nuisance can leave the process exposed. The mature approach is not to force one culture to dominate the other, but to build shared engineering discipline around the real consequences of cyber decisions.
Why Internet Exposure Is Different From Remote Access
One of the most important distinctions in industrial cybersecurity is the difference between remote access and direct internet exposure. Remote access can be legitimate, controlled, logged, and necessary. Direct exposure means the device or service itself is reachable from the public internet, often discoverable by scanners and accessible without layered controls. A PLC behind a well-managed VPN, with multifactor authentication, strict user permissions, logging, network segmentation, and vendor access windows, is a very different risk from a PLC listening on a public IP address with a factory password.
CISA’s 2023 guidance made this distinction explicit when it urged organizations to disconnect PLCs from the open internet and, where remote access is necessary, place a firewall or VPN in front of the controller to control network access. It also noted that a VPN or gateway can enable multifactor authentication even when the PLC itself cannot support MFA. That point matters because many industrial devices were never designed to be internet-facing identity platforms. Security often has to be wrapped around them through architecture rather than bolted directly into them.
Good architecture assumes compromise is possible and limits the blast radius. A remote user should not land directly inside the most sensitive control zone. A vendor should not have standing, always-on access to every controller. An operator account should not share credentials with a contractor. A historian server should not become a bridge from business IT to pump controls. A compromised HMI should not automatically imply the attacker can reprogram every PLC. These boundaries are the cyber equivalent of valves, check gates, and containment basins: they do not prevent every failure, but they keep one failure from becoming a system-wide emergency.
In practice, segmentation usually means designing zones and conduits. Corporate IT, business applications, internet-facing services, remote access systems, SCADA servers, engineering workstations, PLC networks, safety systems, and field telemetry should not all sit in one flat network. Firewalls, access control lists, jump hosts, demilitarized zones, monitoring sensors, and strict routing rules create separation. The goal is not isolation for its own sake. The goal is to make it difficult for an attacker who compromises one layer to move silently into the physical process.
Segmentation also helps defenders understand normal behavior. Industrial networks are often more predictable than enterprise networks. A PLC may talk to a specific HMI, historian, or engineering workstation using known protocols. A pump station may report telemetry at regular intervals. An engineering software upload at 3 a.m. from an unfamiliar IP address should stand out. But defenders can only see those patterns if traffic is monitored and networks are structured enough for anomalies to be meaningful. Flat, undocumented networks turn every investigation into archaeology.
The New Geopolitics of Small Utilities
What makes the current concern sharper is the blending of local infrastructure with geopolitical conflict. Water utilities have long faced cyber incidents, from ransomware to insider misuse to opportunistic intrusion. But federal advisories in recent years have repeatedly connected some PLC targeting to Iranian-affiliated activity, including the CyberAv3ngers persona and exploitation of internet-exposed Unitronics Vision Series PLCs. CISA’s earlier advisory said actors compromised internet-facing devices using default or no passwords, and Reuters reported that federal partners updated a 2026 advisory on Iranian-affiliated actors to include a wider scope of targeted devices and current techniques.
For a small town, this is a bewildering escalation. A municipal water plant does not think of itself as a battlefield. Its operators think in terms of chlorine residuals, lift station alarms, permit limits, pump maintenance, rain events, and customer complaints. Yet because water is symbolically and practically essential, even limited disruption can produce public fear. Attackers do not need to poison water to gain attention. Locking operators out, shutting down controls, changing passwords, interrupting telemetry, or forcing manual operations can be enough to generate headlines and demonstrate reach.
Attribution remains difficult and should be treated carefully. Not every incident that resembles a previous campaign is necessarily conducted by the same actor. Criminal groups, hacktivists, state-linked operators, and copycats can reuse techniques, scan the same devices, exploit the same passwords, and target the same exposed infrastructure. Public reporting has indicated suspected Iranian-linked activity in some recent cases, but the technical priority for utilities is broader: defend against the method, not only the named adversary. The internet-exposed PLC is the weak point whether the person touching it is a nation-state operator, a ransomware affiliate, or an opportunistic intruder.
The geopolitical framing also risks obscuring the underlying engineering problem. It is tempting to imagine that only elite adversaries threaten water systems. In reality, the most damaging condition may be the large population of exposed, poorly configured, poorly monitored OT assets. Once devices are visible and weakly authenticated, they become available to many classes of attackers. The strategic lesson is that critical infrastructure resilience cannot depend on guessing who will be interested next week. It has to assume that exposed systems will eventually be found.
Manual Operations Are a Safety Net, Not a Strategy
One reassuring detail in many water-sector incidents is that operators can often fall back to manual operations. CISA’s 2023 alert noted that an affected municipality took the system offline and switched to manual operations, with no known risk to drinking water or water supply. Reuters similarly reported that some recent attacks forced manual operations and resets, while state and local officials said water safety was not threatened in certain cases.
Manual operation is one of the great strengths of industrial systems. Skilled operators understand their plants in ways no dashboard can fully capture. They know which pump sounds wrong, which valve sticks in cold weather, which sensor drifts after cleaning, which alarm is urgent, and which process variable must be watched during a storm. When automation fails, human expertise can keep water moving. That is why incident response planning for OT must include not only cyber forensics but also operational continuity: staffing plans, paper procedures, sampling schedules, spare parts, radios, manual control points, and coordination with public health authorities.
But manual operation is also costly and fragile. It may require staff to be physically present around the clock. It may reduce efficiency, delay response, increase the chance of human error, and strain small teams. Some remote sites may not be designed for convenient manual control. Some processes depend on timely telemetry from locations miles apart. In wastewater systems, storms can create fast-moving hydraulic conditions where automation helps operators respond before overflows occur. In drinking water systems, chemical dosing, pressure control, and storage management require careful attention. Manual mode is a safety net, not a permanent cybersecurity architecture.
The best incident response posture is therefore a blend of cyber and operational readiness. Utilities should know how to isolate affected control networks, preserve evidence, reset credentials, restore PLC logic, validate process state, and communicate with regulators and the public. They should also know how long they can run manually, which functions are most critical, which spare parts exist, which vendors can respond, and which systems must be prioritized for restoration. Cybersecurity in water is not only about preventing intrusion. It is about preserving the ability to operate safely when intrusion occurs.
This is where exercises matter. Tabletop exercises can reveal uncomfortable gaps before an incident does. Who has authority to disconnect remote access? Who knows the VPN configuration? Where are PLC backups stored? Are they offline and current? Which vendor has the latest project file? Can operators identify unauthorized logic changes? How will the utility tell residents what happened without causing unnecessary panic? These questions are not theoretical. They are the difference between a controlled response and a scramble.
The Engineering of Better Defenses
The defenses against internet-exposed PLC attacks are not mysterious, but they require discipline. The first and most urgent step is exposure reduction. Utilities need an accurate inventory of public-facing assets and externally reachable services. That means looking beyond the obvious firewall and asking whether any PLC, HMI, remote telemetry unit, router, modem, VPN appliance, remote desktop service, cloud gateway, or vendor access path is reachable from the internet. External attack surface scanning, CISA services, vendor reviews, and independent assessments can help reveal what internal diagrams miss.
The next step is identity hardening. Factory default passwords must be changed. Shared accounts should be eliminated wherever possible. Remote access should require multifactor authentication. Vendor access should be time-bound, approved, logged, and limited to necessary systems. Passwords should not be reused across controllers, HMIs, engineering workstations, and VPNs. These measures sound basic because they are basic, but CISA’s repeated emphasis on default passwords reflects a painful reality: many successful intrusions do not begin with technical brilliance but with avoidable credential weakness.
Architecture comes next. PLCs should not be directly reachable from the public internet. Remote access should terminate in controlled zones, ideally through VPNs or secure gateways with MFA, logging, and least-privilege rules. Firewalls should restrict which systems can communicate with controllers and on which ports. Engineering workstations should be protected, patched carefully, backed up, and used only for authorized control system work. Business IT compromise should not automatically provide a path into OT. Where feasible, unidirectional gateways, jump servers, industrial demilitarized zones, and protocol-aware monitoring can reduce risk further.
Monitoring is often the missing piece. Many utilities can detect a failed pump faster than a suspicious login. OT monitoring does not have to mean drowning operators in alerts. It means establishing visibility into remote access sessions, engineering changes, controller communications, unusual protocol activity, firmware changes, configuration downloads, and unauthorized devices. Because industrial traffic tends to be structured, even simple baselines can be valuable. A new public IP connecting to an engineering port, an unexpected programming session, or a controller reboot outside a maintenance window should trigger investigation.
Resilience closes the loop. Current offline backups of PLC logic, HMI projects, historian configuration, firewall rules, and remote access settings should be maintained and periodically tested. Spare controllers and known-good firmware should be available for critical systems where budgets permit. Operators should be trained to factory reset and reload devices in coordination with vendors. Incident response plans should include cyber contacts, law enforcement reporting paths, regulatory notification requirements, public communication templates, and manual operation procedures. The goal is not to promise that no attacker will ever get in. The goal is to ensure that intrusion does not become prolonged loss of control.
The Vendor and Policy Problem
Utilities cannot solve this alone. Vendors, system integrators, state agencies, insurers, regulators, and federal programs all shape the security posture of water infrastructure. Vendors decide whether devices ship with unique credentials, whether secure remote access is easy to deploy, whether logs are useful, whether firmware updates are practical, and whether legacy products receive support. Integrators decide how networks are built, documented, and handed over. Procurement rules decide whether cybersecurity features are optional extras or baseline requirements. Regulators and funding bodies decide whether small systems receive the resources needed to modernize safely.
The industrial market has improved, but unevenly. Newer PLCs, HMIs, and SCADA platforms increasingly support stronger authentication, encrypted communications, role-based access, signed firmware, secure boot, and better logging. But water systems often contain long-lived assets. A controller installed years ago may still perform its process function perfectly, even if its cybersecurity model belongs to another era. Replacing it may require not just buying hardware but rewriting logic, retesting controls, training staff, scheduling downtime, updating drawings, and coordinating permits. That is why cybersecurity modernization must be treated as infrastructure investment, not merely IT spending.
Policy can help by aligning incentives. Grants and low-interest loans for water infrastructure should include cybersecurity architecture, not just pipes and pumps. State-level support teams can provide shared expertise for small utilities that cannot hire dedicated OT security staff. Sector-wide incident reporting can help identify patterns without punishing victims for transparency. Procurement standards can require secure-by-design features. Training programs can help operators and IT personnel understand each other’s constraints. None of this eliminates local responsibility, but it recognizes that critical infrastructure defense is a public-good problem.
There is also a need for humility in federal guidance. A small utility may read a long checklist and see not a roadmap but an impossible burden. Effective guidance must distinguish between urgent must-do actions and longer-term maturity goals. Disconnect direct internet exposure. Change defaults. Require MFA for remote access. Back up controller logic. Segment the network. Know how to operate manually. Monitor remote access and engineering changes. These are the core actions that map most directly to the attacks now being observed. Advanced analytics and zero-trust architectures are valuable, but they cannot substitute for removing a PLC from the open internet.
Why the Future Will Be More Connected, Not Less
The obvious reaction to PLC attacks is to demand that water systems disconnect everything. In some cases, disconnection is exactly what should happen: no PLC should sit naked on the internet, listening for whoever finds it. But the broader future of water infrastructure will almost certainly be more connected, not less. Utilities face climate stress, drought, flooding, aging assets, workforce shortages, regulatory demands, and pressure to operate more efficiently. Smart sensors, predictive maintenance, digital twins, remote monitoring, automated reporting, and cloud analytics can all help. The question is not whether water systems will use networks. The question is whether they will use them safely.
Secure connectivity requires designing for hostility from the beginning. That means assuming devices will be scanned, credentials will be attacked, vendors will need access, operators will work remotely, and incidents will occur. It means building security into reference architectures, not improvising it after deployment. It means vendors shipping products that do not depend on default credentials, integrators documenting every access path, utilities reviewing exposure regularly, and regulators treating cyber resilience as part of water quality and service reliability.
Artificial intelligence and automation may eventually help defenders by spotting abnormal process behavior, correlating network activity with physical sensor data, and detecting subtle changes in control logic. But AI will not rescue an exposed PLC with a factory password. The foundations remain architectural and operational. Know what is connected. Remove direct exposure. Authenticate strongly. Segment ruthlessly. Monitor what matters. Back up what cannot be quickly rebuilt. Practice manual operation. Build relationships before the incident. These principles are older than the latest threat campaign, and they will remain relevant after the current headlines fade.
The deeper shift is psychological. Water operators, municipal leaders, vendors, and citizens must understand that cybersecurity is now part of the physical reliability of water. It is not a separate digital hygiene issue. A password can affect pressure. A firewall rule can affect a pump. A forgotten modem can affect public confidence. A backup file can determine how quickly a plant returns to normal. The boundary between cyberspace and infrastructure has dissolved, not in theory but in the ordinary cabinets and control rooms that run everyday life.
The attacks on internet-connected water PLCs should therefore be read not only as a warning about one sector, one country, or one adversary. They are a preview of the infrastructure era ahead. The systems that make modern life invisible when they work—water, power, transport, manufacturing, communications—are becoming more software-defined, more remotely managed, and more exposed to the logic of networks. Their defenders will need to think like engineers and adversaries at the same time. They will need to preserve the virtues of industrial systems—reliability, safety, caution, recoverability—while adding the security assumptions of a world where every reachable device is eventually touched by someone who should not be there.
The water still comes out of the tap as if by magic. Behind that simple act is a chain of pumps, valves, sensors, controllers, operators, regulations, and trust. The recent warnings from CISA show how fragile that trust can become when industrial control systems are treated like ordinary internet devices. The fix begins with a principle that should now be non-negotiable: PLCs that control water and wastewater processes do not belong directly on the public internet. Remote access must be mediated, authenticated, segmented, monitored, and recoverable. In critical infrastructure, convenience is not the enemy. Unprotected convenience is.
Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.
This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.
Get the weekly RF & IT briefing
Radio guides, RF calculators, AI, Windows, Linux and satellite communication explainers. One useful email per week. No spam.
