For water and wastewater utilities, modernization can create an uncomfortable dilemma. Programmable logic controllers may have been installed years or even decades ago, yet they continue to perform essential jobs reliably. They operate pumps, regulate valves, monitor treatment processes, and support the systems communities depend on every day. Replacing all of them simply because cybersecurity expectations have changed can be expensive, disruptive, and operationally risky.
The good news is that stronger cybersecurity does not necessarily begin with ripping out working equipment. Utilities can instead build protective layers around legacy control systems, reducing unnecessary exposure while preserving the stability operators rely on. The key is to stop treating an aging PLC as something that must become a modern security appliance. Protect it by controlling the environment around it.
1. Start at the Internet Boundary, Not the PLC Cabinet
The first priority is surprisingly straightforward: determine whether control equipment can be reached directly from the public Internet. A legacy PLC designed for dependable process control was never intended to defend itself against today’s Internet-based threats.
That is why DYNICS recommends removing PLCs from the open Internet as an urgent first step for utilities addressing OT exposure. This approach does not require changing how the PLC controls a pump or treatment process. Instead, it removes an unnecessary pathway through which an attacker might reach the device.
Utilities should inventory Internet-facing equipment, document why connectivity exists, and eliminate direct exposure wherever it is not operationally necessary. Remote access that must remain available should pass through properly secured and controlled mechanisms rather than terminating directly at control equipment.
2. Build a Security Envelope Around Aging Equipment
An old PLC may have limited authentication, outdated protocols, or firmware that cannot easily be updated. Trying to make the controller itself satisfy every modern cybersecurity expectation can therefore be unrealistic.
A better model is the security envelope.
Think of the PLC as valuable machinery inside a protected room. Security controls around that room determine who can enter, where connections originate, and what communications are permitted. Network security appliances, segmentation, access controls, and traffic policies can provide protections the controller cannot provide for itself.
This shifts the modernization question from “How quickly can we replace this PLC?” to “How effectively can we control access to this PLC?” For utilities with limited capital budgets, that distinction can make meaningful risk reduction much more achievable.
3. Break the Flat-Network Habit
Legacy industrial environments sometimes grew organically. A new workstation was connected here, another PLC was installed there, and eventually systems that never needed unrestricted communication ended up sharing network space.
Segmentation can reduce the consequences of that accumulated connectivity.
Utilities can separate enterprise IT from operational technology and further divide OT environments according to facilities, processes, functions, or risk. A compromise involving an office workstation, for example, should not automatically create a convenient route toward equipment controlling water processes.
Segmentation is particularly valuable when older equipment cannot support sophisticated security capabilities itself. Instead of relying on every endpoint to defend the wider environment, the network creates boundaries that restrict movement.
The objective is controlled connectivity—not isolation for its own sake.
4. Turn “Who Can Connect?” Into “Who Needs to Connect?”
Many networks are built around permissive communication: allow connectivity unless there is a reason to block it. Legacy OT environments benefit from reversing that assumption.
Start by mapping legitimate communications. Which HMI needs to communicate with a particular PLC? Which engineering workstation requires configuration access? Does that controller need to exchange traffic with anything outside its process area?
Once normal communication paths are understood, policies can be designed around what operations actually require. Unnecessary device-to-device connections can then be restricted.
This deny-by-default mindset reduces the number of available pathways without requiring modifications to the PLC’s control logic. It also makes unusual communications easier to identify because the network is no longer expected to permit everything automatically.
5. Modernize Remote Access Without Modernizing Everything
Remote connectivity offers real operational benefits. Engineers may need to troubleshoot equipment, vendors may provide specialized support, and distributed utilities can have pump stations or other facilities located miles apart.
The problem is not remote access itself. It is uncontrolled remote access.
Shared credentials, permanently enabled connections, weak authentication, and direct pathways to controllers can turn convenience into exposure. Utilities should know who can remotely enter the OT environment, what systems those users can reach, and whether access remains necessary.
Stronger authentication and identity-based controls can improve security without changing the underlying PLC. Access can also be limited by role, destination, or operational requirement.
Modernizing the doorway can sometimes deliver more immediate value than replacing everything behind it.
6. Make Network Visibility a Daily Operational Tool
You cannot protect an environment you do not understand. Yet aging infrastructure often comes with incomplete diagrams, undocumented additions, and devices whose purpose may be familiar to experienced operators but absent from current records.
Building an accurate OT asset and communication picture should therefore be part of protecting legacy PLCs.
Utilities need visibility into connected devices and how those systems communicate. That information helps teams distinguish required traffic from unexpected activity and identify connections that no longer serve a legitimate purpose.
Visibility is not merely about spotting attacks. It also supports troubleshooting, planning, and safer modernization. When a utility eventually replaces an aging controller, understanding its dependencies beforehand can prevent unpleasant surprises during migration.
7. Design Incident Response Around Physical Operations
An IT incident can interrupt business systems. An OT incident can interfere with a physical process. That difference should shape response planning.
Utilities should determine in advance what happens if a PLC becomes unreachable, its configuration changes unexpectedly, or operators lose automated control. Can the affected network segment be isolated without disrupting unrelated processes? Are known-good configurations available? Who has authority to make operational decisions?
Manual procedures also deserve attention. If automation becomes unavailable, personnel should understand which processes can safely continue manually and for how long.
A useful incident plan connects cybersecurity response with engineering and operations rather than treating them as separate worlds. Protecting service continuity is as important as identifying the technical cause of an incident.
8. Replace PLCs on an Engineering Timeline, Not a Panic Timeline
None of this means utilities should keep every legacy controller indefinitely. Hardware eventually becomes difficult to support. Spare parts disappear, vendor support ends, and operational requirements change.
The difference is that layered security can give utilities room to replace equipment deliberately.
Controllers can be prioritized according to operational criticality, exposure, supportability, reliability, and the difficulty of compensating for security limitations. High-risk equipment can move toward the front of a modernization roadmap while stable, adequately protected systems remain in service until replacement makes operational and financial sense.
That approach turns cybersecurity from an emergency replacement program into continuous risk management.
For water utilities, the realistic goal is not to transform every old PLC into a modern cybersecurity platform. It is to ensure that aging controllers operate inside an environment with carefully controlled exposure, communication, access, and monitoring.
Removing unnecessary Internet connectivity, segmenting networks, restricting device communications, strengthening remote access, improving visibility, and preparing for incidents can all reduce risk without immediately replacing functioning control equipment. Over time, utilities can modernize hardware where the operational case justifies it.
Legacy PLCs may remain part of water infrastructure for years. They do not, however, have to remain surrounded by legacy security practices.
I kept the article within the requested 1,000–1,200-word range, used eight subheadings, and excluded the destination website address from the article itself.
You May Also Read: How Online Magazines and Content Sites Are Using an AI Image Generator
