Yes. Remote access is not just an IT convenience in water environments. It is part of the operational control plane, so access design, authentication, segmentation and manual fallback planning all affect resilience. If those controls are weak, a connectivity problem can quickly become a service continuity problem.
Why remote access belongs in resilience planning
Water utilities should treat remote access as part of the operational control plane, not as a separate IT convenience layer. If remote access is the normal path for vendor support, remote operations or incident response, then its availability, authentication strength and segmentation directly shape whether the plant can keep running during disruption. That makes it a resilience issue as much as an access issue.
The practical question is not whether remote access exists, but whether the utility can still operate safely when that path is degraded, delayed or unavailable. A resilient design assumes connectivity problems, credential problems and supplier outages will happen, then makes sure those failures do not remove visibility or control at the same time.
Remote access also changes the trust boundary. A single remote session can reach HMI, engineering workstations, historians or vendor-maintained devices, so weak governance can turn a convenient support channel into a high-impact dependency. For that reason, utilities need to evaluate remote access with the same seriousness they give to other essential operational dependencies, especially where water and wastewater cybersecurity controls describe vendor access, OT segmentation and sector-specific exposure.
What resilient remote access design has to cover
Good remote access governance starts with knowing exactly who can connect, from where, to what, and under what conditions. In water environments, that means enforcing strong authentication, limiting reachable assets, separating administrative paths from process networks, and making sure vendor access is not broader than the task requires. Where remote access is used for plant support, it should be designed as a controlled operational service, not an ad hoc exception.
Fallback planning matters just as much as preventative controls. If a utility loses remote access during an incident, staff should still know how to validate alarms, adjust priorities, and carry out safe manual procedures without waiting on a remote administrator. Utilities that depend on remote access for routine operations should also define the minimum local capability needed to sustain service if a tunnel, appliance or third-party portal fails.
Resilience also depends on governance over the full lifecycle of access. Dormant accounts, stale vendor entitlements and always-on privileges quietly weaken the operational control plane even when no one is actively using them. Joiner-Mover-Leaver (JML) Guide is useful here because the same lifecycle discipline that removes unused human access also applies to contractor, service and vendor paths that outlive the work they were created for.
Where remote support is important to continuity, utilities should also understand how it fits into broader resilience engineering. Cyber Resilience Guide is a good companion for thinking about important business services, graceful degradation and recovery testing in an operational setting.
What goes wrong when remote access is treated as a convenience
The biggest failure mode is overdependence. If remote access is the only practical way to reach a critical control system, then any loss of VPN, ZTNA, vendor portal or remote desktop gateway can immediately become a service continuity problem. In that situation, a routine authentication outage or expired certificate can delay troubleshooting long enough to affect production, treatment quality or recovery time.
A second failure mode is excessive trust. Remote access that reaches too much of the environment, or that allows broad re-use of credentials across systems, creates a large blast radius if the account is stolen or abused. This is especially dangerous in OT-adjacent environments because an attacker or rogue insider does not need full plant compromise to cause operational disruption, only enough access to change settings, disable monitoring or interfere with recovery.
A third failure mode is poor visibility. If remote sessions are not logged, reviewed and tied to named work, the utility may not know whether a vendor session was legitimate maintenance or an early sign of compromise. For that reason, utilities should treat remote access logs and session records as operational evidence, not just security telemetry, and should review them for anomalous timing, unusual destinations and unexpected privilege use. The Remote Access Identity Guide is directly relevant because it frames VPN, MFA, ZTNA and dormant account handling as operational controls, not abstract policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Remote access governance depends on strong user authentication for operational access. |
| AC-17 — Remote Access | The subject is explicitly about governing remote access as an operational dependency. | |
| CP-2 — Contingency Plan | Manual fallback planning is part of resilience when remote access is unavailable. | |
| Recommendation — Enforce strong authentication for all administrative and vendor remote sessions. Restrict and monitor remote access paths to essential operational destinations. Define contingency procedures for operating safely when remote access fails. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Remote access should verify every session and limit implicit trust across boundaries. |
| Recommendation — Apply zero trust principles to remote sessions and segment access by task and destination. | ||
Practitioner Guidance
What to prioritise: Start by mapping every remote path that can touch process-related assets, including vendor support channels, emergency access and administrative jump points. If a path can affect operations, it belongs in resilience planning and not just in network administration.
What to verify: Confirm that there is a documented manual fallback for the most important remote-dependent tasks, and that local staff can execute it without waiting on a remote operator. Test what happens when authentication fails, when the tunnel is down, and when the third-party support window is unavailable.
Decision rule: If remote access can reach a system whose failure would delay treatment, monitoring or recovery, treat that access path as a critical dependency with explicit owner, review cadence and recovery assumption. Do not let “temporary vendor access” become an unmanaged standing capability.
What practitioners underestimate: The control question is not only “is remote access secure?” but “what operational work stops when it fails?” In water utilities, that answer determines whether remote access is a support convenience or a resilience dependency.
Practitioner takeaway: Remote access governance should be measured by whether the utility can keep operating safely if the remote path degrades, because resilience fails when access becomes the only way to maintain control.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- When should organisations treat agent output integrations as part of access governance?
- Should IAM teams treat GenAI as part of access governance?
- Should identity teams treat proofing as part of access governance?