They should do it whenever a controller can be reached from outside a tightly controlled OT zone. A jump host or secure gateway is the right pattern when remote maintenance, vendor support, or cross-site engineering is required, because it lets teams mediate, log, and authorise access without exposing the PLC directly.
Why jump hosts and secure gateways belong in PLC access design
Jump hosts and secure gateways are the right pattern when PLC access has to cross a trust boundary, especially from enterprise IT, vendor networks, or another site. They insert a controlled mediation point between the requester and the controller, so operators can enforce authentication, logging, session supervision, and policy checks without turning the PLC into a directly reachable asset.
The practical question is not whether remote access is possible, but whether the access path can be constrained enough to keep the controller inside a tightly managed OT zone. A direct route may be tolerable only in very limited, local, and strongly segmented cases. Once remote maintenance or third-party support enters the picture, mediated access becomes the safer default because it preserves visibility and reduces the blast radius of a compromised account or misused tool.
That pattern also fits OT realities where availability matters as much as confidentiality. A well-designed gateway lets teams support engineering workflows while still keeping the PLC isolated from general-purpose networks, unmanaged endpoints, and broad routing exposure. For OT remote access and segmentation considerations, see the OT and ICS Identity and Access Guide.
What changes when the PLC is not directly reachable
The main benefit of routing access through an intermediary is that the PLC no longer has to trust every upstream endpoint. The jump host can become the only permitted ingress path, while the gateway enforces who can connect, when they can connect, and what segment or protocol they may reach. That is especially useful in cross-site engineering, where the same support function may need to access multiple plants without flattening the network.
This model is also easier to align with privilege boundaries. A user can be given access to the jump host or secure gateway without being granted broad network reach into the OT zone itself. In practice, that means fewer exposed services, fewer unmanaged authentication paths, and better control over vendor support sessions. The SSH and bastion-host pattern is a useful analogue for the control objective, as described in the SSH Key and SSH Certificate Management Guide.
Where access has to be time-bound or approved, the intermediary can also support stronger operational discipline than a permanent direct path. Teams can require a ticket, a maintenance window, or a named session owner before traffic is allowed through. That does not remove the engineering need, but it changes the control point from the PLC to the access path in front of it.
When mediated access is the better default
Organisations should favour jump hosts and secure gateways whenever access is remote, shared across teams, or provided to external support parties. Those conditions create the most risk from unmanaged endpoints, credential reuse, overbroad routing, and weak accountability. If the access path cannot be fully contained inside a trusted OT enclave, the intermediary should be treated as mandatory rather than optional.
They are also the better choice when the organisation needs auditability. A direct connection can tell you that traffic occurred, but it often cannot explain who approved it, which session used it, or what was changed. A mediated architecture lets the team centralise session logging, approval checks, and termination conditions around one controlled point. For access-control and audit expectations in enterprise security programs, the CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls are directly relevant.
When the intermediary is used correctly, the PLC sees only an allowed control plane, not a general-purpose access surface. That distinction matters most in plants with vendor support arrangements, multi-site engineering teams, or legacy controllers that cannot enforce modern identity controls themselves.
Risk and Threat Considerations
Direct PLC exposure increases the chance that a stolen credential, misrouted connection, or poorly segmented network path can reach an operational controller. In OT environments, that can turn a routine maintenance path into an attacker’s pivot point, especially when vendors, remote tools, or shared accounts are involved.
Failure mechanism: A direct route bypasses the control point where authentication, logging, approval, and session limitation would normally be enforced, which makes abuse harder to detect and easier to repeat.
Impact: The result can be unauthorised PLC changes, loss of operational visibility, lateral movement into adjacent OT systems, or disruption of production processes.
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 CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | Jump hosts and secure gateways govern remote access into OT controllers. |
| AU-2 — Event Logging | Mediated access is chosen to log and review PLC sessions. | |
| Recommendation — Route all remote PLC access through controlled intermediary access points. Log intermediary sessions that reach PLC assets. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about restricting and mediating access paths to PLCs. |
| Recommendation — Restrict PLC administration to approved mediated access paths. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Gateway-mediated access depends on stronger authentication for remote sessions. |
| A.8.2 — Privileged access rights | PLC administration via jump hosts is a privileged access pattern. | |
| Recommendation — Require strong authentication at the jump host or secure gateway. Limit PLC administrative rights to named, controlled sessions. | ||
Practitioner Guidance
What to prioritise: Put every non-local PLC administration path behind a single mediated entry point, then decide whether the control objective is just connectivity or full session governance. If the answer includes vendor support or cross-site engineering, treat session logging and approval as part of the design, not an add-on.
What to verify: Confirm that the jump host or secure gateway is the only routable path into the PLC segment, that direct firewall exceptions are not quietly reintroducing exposure, and that maintenance access is time-bounded. Also verify that the intermediary itself is hardened, monitored, and managed as a high-trust asset.
Common mistake: Teams often secure the PLC protocol but forget the access path. That leaves an apparently protected controller reachable through an overprivileged admin network, a shared vendor VPN, or a workstation that was never meant to touch OT at all.
Practitioner takeaway: If access must cross a trust boundary, the real control is not the PLC connection itself, it is the mediation point in front of it. The more remote, shared, or external the access need becomes, the more important it is to make that mediation mandatory and observable.
Related resources from NHI Mgmt Group
- Why do AI gateways matter when organisations route models, tools, and agents through one control layer?
- What breaks when organisations have to route every access request through multiple approvers?
- When should organisations prioritise jump hosts and segmentation together rather than relying on remote access controls alone?
- How should security teams secure RDP access without relying on jump hosts?