How should water utilities reduce internet exposure on PLCs and remote access links?

Start by mapping every PLC, HMI, remote terminal unit, VPN, cellular modem, and partner connection that can reach OT assets. If a controller does not need direct internet access, remove it. When remote access is necessary, route it through a secure gateway or VPN, use unique credentials, enforce phishing resistant MFA, and limit each device to the smallest set of approved connections.

Reduce Internet Reachability Before You Harden Remote Access

The highest-value step is inventory, then elimination. Utilities should identify every path that can reach OT assets, then remove direct internet exposure wherever a controller does not truly need it. The practical objective is to shrink the number of exposed entry points, reduce trust in always-on remote reachability, and make every remaining path intentional, documented, and tightly bounded.

That usually means treating PLCs, HMIs, remote terminal units, VPNs, cellular modems, and partner links as one access surface, not separate problems. When the same asset is reachable through multiple routes, the weakest route becomes the one attackers test first, so network reduction is as important as device hardening.

Utilities trying to understand the broader identity and access implications of exposed remote paths can use Ultimate Guide to NHIs as a reference point for lifecycle, visibility, rotation, and access governance, and Ultimate Guide to NHIs, Key Challenges and Risks for the operational failure patterns that often accompany overexposed access paths.

How to Structure Necessary Remote Access Without Exposing Controllers

When remote access is unavoidable, place it behind a secure gateway or VPN and restrict it to the smallest set of approved connections. That design keeps the controller off the public internet while still allowing legitimate support, monitoring, or partner workflows to function.

The remote path should also be specific to the device and the use case. Shared credentials, broad network routes, and “one tunnel for everything” architectures create unnecessary blast radius. A better model is device-specific access with unique credentials, phishing-resistant MFA, and tightly scoped source and destination rules that prevent a remote session from becoming a general-purpose foothold.

For a practical control model, NCSC UK Advice and Guidance is a useful external reference for operational remote-access hardening, while NIST SP 800-207 Zero Trust Architecture supports the principle of continuously constraining access rather than trusting network location alone.

Practical Failure Modes in OT Remote Connectivity

Most exposure problems are not caused by a single bad device, they come from accumulated exceptions. A PLC reachable through an old modem, a maintenance VPN left broadly open, or a partner connection that was never narrowed after commissioning can all create long-lived paths into OT. Once those paths exist, they are hard to see, easy to forget, and difficult to justify later.

The control failure to watch for is over-permissioned remote access that outlives the original business need. In OT environments, “temporary” access often becomes permanent because equipment is hard to change, vendors are slow to revise support patterns, and operators rely on exceptions to keep uptime stable. That makes access review and connection pruning part of the security control, not a periodic paperwork exercise.

Utilities should also consider the visibility gap that comes from unmanaged remote links. The more access paths that bypass a central gateway, the harder it becomes to prove who connected, from where, to which asset, and for how long. That is why an inventory of reachable controllers is the starting point, not a nice-to-have.

Risk and Threat Considerations

Internet-facing PLCs and loosely controlled remote access links expand the attack surface in ways that matter operationally and physically. The risk is not just unauthorized login, but the possibility that an exposed path becomes a direct route to process disruption, unsafe configuration change, or broader movement across OT support systems.

Failure mechanism: Attackers look for exposed management services, weakly protected VPNs, modem-connected devices, and partner paths that provide a low-friction entry point. Once inside, they can abuse overbroad access, reuse credentials, or pivot through trusted remote tooling to reach controllers that should never have been directly reachable.

Impact: A single exposed link can turn a routine support channel into a high-value intrusion path. The likely consequences are unauthorized operational change, service interruption, and much larger recovery effort because remote-access misuse is often indistinguishable from legitimate maintenance until after damage has occurred.

Standards & Framework Alignment

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

NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	Policy Enforcement Point — Policy Enforcement Point	Directly supports forcing remote access through controlled gateways instead of direct reachability.
	Least Privilege Access — Least Privilege Access	Matches the need to limit each device to the smallest set of approved connections.
Recommendation — Place OT remote sessions behind policy-enforcing gateways and restrict every connection by device and session context. Limit remote paths to the minimum destinations and actions required for each controller or support workflow.
CIS Controls v8	6 — Access Control Management	Applies to reducing exposed access paths and managing who can reach OT assets.
	8 — Audit Log Management	Supports monitoring remote logins and privileged access to exposed OT connectivity.
Recommendation — Inventory and remove unnecessary remote access paths, then review remaining access regularly. Log all remote access to OT assets and alert on out-of-policy connections or repeated failures.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Covers authentication and access control for remote connectivity into OT environments.
	GV.5 — Risk Management Strategy	Supports the decision to remove direct internet exposure where the business does not need it.
Recommendation — Require strong authentication and tightly scoped authorization for every approved remote access path. Adopt a strategy that removes unnecessary external exposure from OT assets and remote links.

Practitioner Guidance

What to prioritise: Start with the assets that can directly influence OT behaviour, not with general office-network cleanup. If a PLC, RTU, or supporting remote path can still be reached from the internet or through a partner tunnel, treat that as a higher-priority exposure than an internally isolated system.

What to verify: Confirm that every approved remote connection is named, owned, time-bounded, and constrained to the exact asset set it needs. If the access path cannot be explained in one sentence by the business owner and the operations team, it is probably broader than necessary.

Practitioner takeaway: The safest remote-access design for OT is not “secure enough internet access,” it is the smallest possible number of intentional pathways, each with strong authentication, tight scope, and a clear operational owner.