Utilities should route remote access through jump boxes, segmented administrative paths, and gateways that can enforce authentication, logging, and approval. Direct connections to legacy systems create broad trust where the equipment cannot defend itself. If the system cannot support modern controls, the access path has to carry the security burden instead.
Why direct remote access is the wrong trust model for legacy control systems
Utilities harden remote access by assuming the legacy system itself is not the place to enforce security. Older OT equipment often lacks strong authentication, session control, or fine-grained logging, so a direct connection turns the remote path into a standing trust bridge. The practical problem is not only unauthorised access, but also the loss of visibility and containment once that bridge exists. That is why a controlled access layer matters more than trying to retrofit the device itself.
For utilities, this becomes a reliability issue as much as a security issue. A single remote channel that reaches too far can expose engineering workstations, field devices, and supervisory systems to the same failure domain. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control discipline behind restricted access, logging, and accountability, but the engineering reality is simpler: if the asset cannot protect itself, the path to it must do the protecting. In practice, many utilities discover weak remote access only after vendors, integrators, or operators have already been given long-lived broad access that was never designed to be temporary.
How jump hosts, segmentation, and gated workflows reduce exposure
The most effective hardening pattern is to break remote access into controlled stages rather than allowing an external user to touch a legacy control system directly. A jump box or bastion host gives operators a managed entry point, while network segmentation confines that entry point to the smallest set of systems needed for the task. From there, a gateway or remote access broker can enforce authentication, session recording, approval, and time-bound access. That changes the security question from “Can this user reach the PLC or HMI?” to “Can this user complete a bounded, observable session through the approved path?”
This model matters because legacy control systems often support only partial security controls. Some can log events but not enforce identity assurance. Some can permit a connection but not distinguish between routine maintenance and high-risk changes. A hardened access path compensates for those gaps by adding controls outside the device boundary. It also preserves operational continuity, because access can be granted without replatforming the plant. The gateway should be treated as an enforcement point, not as a convenience layer, and the approval step should reflect the sensitivity of the task, not just the identity of the requester.
Operationally, utilities should design the path so that each remote session has a clear owner, a narrow destination set, and a documented reason for use. That usually means separate remote paths for vendors, internal engineers, and emergency break-glass use. It also means disabling direct inbound reachability wherever possible, because once a legacy controller is directly addressable, every compensating control becomes harder to verify. OWASP Non-Human Identity Top 10 is relevant where service accounts, gateways, and automated access brokers are part of the design, since those components also need ownership, scope, and lifecycle discipline. The guidance breaks down when remote access is left unmanaged across vendors, emergency accounts, and ad hoc network exceptions.
Where the standard model breaks down in plants and substations
Tighter remote access controls often increase operational friction, so utilities must balance containment against restoration speed and maintenance windows.
Legacy environments rarely fit a single remote access pattern. Vendor maintenance may require a different approval chain from internal troubleshooting, and substation or plant outages can force access decisions that normal change workflows do not cover. Guidance-vs-consensus is important here: there is broad agreement that direct access is unsafe, but there is not one universally accepted gateway design for every OT estate. Some utilities use one hardened bastion for all remote work, while others split paths by function or business unit because the risk of overbroad trust is lower when paths are segregated.
The edge cases are usually governance failures, not technical impossibilities. Break-glass accounts may be necessary, but if they are not monitored and periodically tested, they become an uncontrolled backdoor. Remote vendor support may be unavoidable, but if vendor access is persistent rather than session-based, the organisation loses the ability to prove who was connected, when, and for what purpose. The practical rule is to minimise standing access, enforce approval where the task is sensitive, and make every exception visible enough to audit after the fact. Once exceptions outnumber the standard path, the access model is no longer hardened in any meaningful sense.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Remote access hardening is fundamentally about limiting and verifying access paths. |
| Recommendation: Remote access should be restricted, authenticated, and scoped to the minimum necessary path. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 | Remote brokers and service accounts need explicit ownership and lifecycle control. |
| Recommendation: Access components and credentials require clear ownership, scope, and offboarding discipline. | ||
| NIST SP 800-63 | IAL | Utilities must know how strongly a remote operator is authenticated before allowing control access. |
| Recommendation: Remote access decisions should reflect the required strength of identity assurance. | ||
Risk and Threat Considerations
Direct remote access to legacy control systems creates a high-trust pathway that can be abused by an attacker, contractor, or misconfigured support process to reach equipment that cannot enforce modern access controls. The material risk is not just initial entry but the collapse of containment across the control path.
Failure mechanism: The weakness materialises when broad or persistent remote connectivity, shared accounts, or poorly segmented administrative paths allow a session broker, jump host, or vendor account to become a de facto control plane. Attackers and insiders can then use valid access to move from remote entry into OT functions that lack strong native verification or session restriction.
Impact: If that path is compromised or misgoverned, operators can lose visibility into who changed what, when, and from where, while critical control functions become reachable through a trust bridge that is hard to revoke quickly. The result can be unauthorised configuration changes, delayed detection, and expanded blast radius during an incident.
Practitioner Guidance
Teams often focus on whether remote access exists, when the real issue is whether each session is bounded, attributable, and revocable. A legacy OT estate is never hardened by a login screen alone; it is hardened by a controlled path with narrow scope and operationally testable exceptions.
- Define separate remote access paths for vendors, internal engineers, and emergency use, and prohibit direct inbound access to controllers and HMIs except under a documented break-glass process.
- Require every remote session to terminate on a managed jump host or broker that enforces MFA, session recording, and destination allowlisting before any OT connection is opened.
- Tie approvals to the task risk, not just the requester, so high-impact maintenance, configuration changes, and vendor support all follow different authorisation rules.
- Review and expire vendor, contractor, and maintenance accounts on a fixed schedule, with ownership assigned to a plant or system manager rather than to IT by default.
- Test the revocation path as part of drills, so the organisation knows it can actually cut off remote access fast during an incident or maintenance dispute.
Related resources from NHI Mgmt Group
- How should utilities automate access governance across cloud, hybrid, and legacy systems?
- How should security teams close MFA coverage gaps across legacy and remote access systems?
- Why do legacy access control systems create risk when organisations move to mobile access?
- Why do legacy remote access protocols create outsized risk when they rely on external login utilities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
