How should security teams harden exposed PLCs in water and wastewater environments before attackers find them?

Security teams should remove internet exposure wherever possible, change default passwords immediately, and require MFA for any remote access into the OT network. If remote access is unavoidable, place a firewall or VPN in front of the PLC and restrict access to known sources. Keep firmware and HMI software current, and back up logic and configurations so recovery is fast after compromise.

Why Exposed PLCs Become an Easy Entry Point

Programmable logic controllers in water and wastewater plants are rarely attacked because they are sophisticated targets; they are attacked because they are reachable, predictable, and often left with weak remote access habits. Once a PLC is visible from the internet, attackers do not need to invent a new exploit path if default credentials, old firmware, or poorly segmented remote access already provide one. The practical risk is not only compromise of the controller itself, but disruption to treatment processes, loss of operator confidence, and time-consuming recovery in an environment where availability matters more than flashy intrusion.

For industrial environments, the right reference point is the operational control problem, not a generic IT perimeter debate. CISA’s cyber threat advisories are useful here because they show how adversaries repeatedly exploit exposed services, weak authentication, and unmanaged remote access in real environments, while industrial defenders still have to preserve safe operations. In practice, many teams discover the exposure only after a scan, an alert, or a partner report has already confirmed the PLC was reachable from outside the plant.

What Hardening Looks Like Before an Attacker Finds It

Hardening exposed PLCs is less about one silver-bullet control and more about removing easy paths in the order an attacker would use them. First, eliminate direct internet reachability wherever the process allows it. If the PLC must remain remotely serviceable, make the remote path explicit and narrow: put a firewall or VPN in front of the control network, allow only known administrative sources, and avoid broad inbound access that mixes vendors, staff, and temporary troubleshooting channels.

Credential hygiene is just as important in OT as it is in enterprise environments, but it has to be applied with care. Default passwords are a common failure point because they are easy to overlook during commissioning and easy for attackers to test at scale. Replacing them is necessary, but teams should also verify that remote access is protected by MFA and that shared accounts are not used as a shortcut for convenience. Where MFA is impractical for a specific maintenance path, that exception should be treated as a higher-risk condition, not a normal operating model.

Patch and configuration discipline matter because PLC compromise often starts with the surrounding stack rather than the controller logic alone. Firmware, engineering workstation software, HMI components, and remote-access tooling all expand the attack surface. Backing up logic and configurations is equally important because recovery in OT is often slower than containment. The most resilient plants can restore known-good control state without guessing whether a field change was legitimate or malicious.

Reduce exposure first, then harden the remaining access paths.
Treat vendor and contractor connectivity as a controlled exception, not a standing entitlement.
Keep a current inventory of externally reachable assets so exposed controllers are not forgotten after commissioning.

The guidance breaks down when organisations rely on ad hoc remote access, because those exceptions tend to bypass the very controls that make hardening effective.

Common Water Sector Edge Cases That Change the Answer

Tighter access control often increases operational friction, so utilities have to balance maintenance speed against the risk created by always-on reachability. That tradeoff is especially sharp in distributed water and wastewater sites where small teams, legacy equipment, and on-call support can tempt operators into keeping a PLC exposed “just for now.”

One edge case is third-party support. Some vendors still expect direct access for diagnostics, but direct access is exactly what expands the attack surface. Another is legacy firmware or unsupported HMI software, where patching may be constrained by certification, uptime, or hardware compatibility. In those situations, compensating controls such as segmentation, jump hosts, strict source allowlists, and logging become more important than pretending the device is fully maintainable in the same way as modern IT assets.

There is also a common consensus gap around remote management convenience. Some teams assume that a VPN alone is enough. It is not, unless the VPN terminates into a tightly controlled environment and not into a flat network where one compromise can reach multiple PLCs. For this topic, the practical standard is to narrow exposure as much as possible, document every exception, and make recovery possible when the control layer is disturbed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Exposed PLC hardening depends on reducing reachable access paths and removing default access.
Recommendation — Revoke unnecessary remote access paths and enforce least-privilege rules for every remaining PLC connection.
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	The question centers on limiting and authenticating access to OT assets before compromise.
Recommendation — Apply access-control safeguards to restrict who can reach PLCs and under what authenticated conditions.
MITRE ATT&CK	T0803 — Block Command Message	Attacks on PLCs often involve manipulating control communications after initial access.
Recommendation — Hunt for unauthorized control-message activity and block abnormal OT command patterns quickly.

Practitioner Guidance

What to prioritise: Start with external exposure inventory, then remove direct reachability from any PLC that does not absolutely need it. The fastest risk reduction usually comes from eliminating forgotten paths rather than tuning individual controller settings.

What to verify: Confirm that every remaining remote path is tied to a named purpose, a known source, and an accountable owner. If you cannot explain why a PLC is reachable from outside the plant, assume the exposure is accidental until proven otherwise.

Common mistake: Teams often harden the PLC itself but leave the engineering workstation, HMI, or vendor access path weak. That creates a false sense of safety because attackers commonly enter through the easiest adjacent system, not the controller panel.

Practitioner takeaway: For water and wastewater OT, the best hardening decision is usually to remove unnecessary exposure entirely; every exception you keep should be treated as a deliberate risk acceptance with compensating controls and a recovery plan.