OT Jump Servers and Secure Remote Access Bastions

01Key takeaways

1. 01

   A jump server is a hardened intermediate host that brokers all human access into a protected OT zone, so nobody connects directly to control assets.

2. 02

   Its security value comes from being the single, instrumented chokepoint where MFA, authorization, session recording and inspection are enforced.

3. 03

   A correctly deployed jump server accepts no direct inbound connections to OT assets; the control network only ever talks to the broker.

4. 04

   A jump server reduces reachability for interactive human sessions, but it is not a path for bulk telemetry, file export or one-way data publication.

5. 05

   A poorly hardened or always-reachable jump server becomes a high-value foothold, so it must be patched, monitored and disconnected by default where possible.

02What is an OT jump server?

A jump server is a system that users must connect to first before they can reach anything inside a protected network. They authenticate to the jump server, and from there they open a session to the target asset. The target asset never accepts a direct connection from the user's own machine.

In OT, the targets are control-system assets: programmable logic controllers, human-machine interfaces, engineering workstations, historians and the management interfaces of network gear. These systems were rarely designed for direct exposure, so a jump server gives them a single supervised front door instead of many unmonitored ones.

Jump server / jump host

An intermediate system users connect to first, then hop onward to a target inside a more protected zone.

Bastion host

A hardened, exposed-by-design host placed at a boundary, stripped to a minimal function and heavily monitored.

Privileged access workstation (PAW)

A locked-down endpoint dedicated to administrative work, often used as the only device permitted to reach a jump server.

03Why the jump server matters in OT

Most serious OT intrusions involve a human-style access path: stolen credentials, an exposed remote-desktop or VPN service, or a compromised vendor connection that leads, hop by hop, toward control systems. A jump server is the control that decides what that path looks like.

Without a broker, interactive access tends to sprawl. A maintenance laptop dials in here, a vendor tunnels in there, an engineer enables remote desktop on a workstation "just for today". Each of those is a separate, often unmonitored, route into the control zone. The jump server consolidates them so there is one place to authenticate strongly, one place to authorize the specific target, and one place to record what happened.

The jump server is where you decide that interactive access into OT is a supervised event, not an open standing capability.

04The threat the bastion is built to contain

The relevant threats are well documented. MITRE ATT&CK for ICS describes adversaries using Remote Services and valid accounts to move from IT into OT, and exploiting external remote services exposed at the perimeter. A jump server is meant to make those techniques harder by removing direct reachability and forcing every interactive session through one inspected point.

• Credential theft followed by direct login to an exposed HMI or engineering workstation.
• Exploitation of an internet-facing remote-access service such as RDP, VNC or a VPN concentrator.
• Lateral movement from a compromised IT host straight into the control network over a flat path.
• Vendor or contractor connections that bypass internal controls and reach assets directly.
• An attacker pivoting through a weakly hardened jump host that itself becomes the foothold.

The last item is the uncomfortable one. A jump server concentrates access, which also concentrates value. If it is poorly built, it does not reduce risk so much as relocate it. That is why the design details below matter more than the label.

05How a jump server architecture works

The core pattern is a forced hop. Users reach the jump server, which lives in a controlled segment between the less-trusted network and the OT zone. The OT-side firewall permits inbound interactive protocols only from the jump server's address, and denies them from everywhere else. The user's own laptop has no route to the target at all.

Stronger designs separate the access broker from the session host. A broker handles authentication, authorization and policy, then launches a session on a clean, ephemeral jump host that is reset or rebuilt after use. This avoids the classic problem of a long-lived shared server slowly accumulating cached credentials, leftover tooling and trust relationships in both directions.

Inbound rule

OT assets accept management and interactive protocols only from the jump host, never from general user or IT networks.

Protocol break

The session terminates on the jump server; the onward connection is a fresh session it originates, not a tunnel passed straight through.

Ephemeral session host

A jump host that is provisioned per session and torn down afterward, so nothing persists for an attacker to harvest.

06Controls a jump server must enforce

A box that simply relays connections is not a security control. The jump server earns its place only when it enforces a specific set of behaviors on every session that crosses it.

• Phishing-resistant multi-factor authentication at the broker, ideally backed by a privileged access workstation as the only permitted source device.
• Per-target authorization so a user is granted one specific asset and protocol, not blanket entry to the zone.
• Full session recording, including keystroke or screen capture and a tamper-evident audit log of who reached what and when.
• No clipboard, drive or arbitrary file passthrough unless explicitly approved and scanned.
• Idle and maximum session timeouts that close access automatically rather than relying on users to log out.
• Hardening to a minimal role: no email, no web browsing, no general-purpose software on the host itself.

Notice how much of this overlaps with privileged access management. In practice a mature OT jump server is usually fronted by a PAM platform that brokers credentials so the user never sees the target's password, injecting it into the session instead.

07Standards and compliance mapping

Jump servers are not an exotic idea; they are written into mainstream OT guidance. NIST SP 800-82 Rev. 3 recommends architectures where remote access traverses an intermediate host with strong authentication and monitoring rather than direct connections into the control network. The relevant NIST SP 800-53 control families cover access control (AC), identification and authentication (IA), and audit and accountability (AU), which map cleanly onto a broker that authenticates, authorizes and records.

ISA/IEC 62443 frames the same idea through zones and conduits: interactive access is a conduit crossing into a higher security level, and it should be the narrowest, most controlled conduit you operate. NERC CIP requirements for interactive remote access in the electricity sector explicitly expect an intermediate system, encryption and multi-factor authentication, which is a jump server by another name.

NIST SP 800-82 / 800-53

Intermediate remote-access hosts with strong authentication, plus the AC, IA and AU control families.

ISA/IEC 62443

Interactive access modeled as a tightly controlled conduit between zones of differing security levels.

NERC CIP

Interactive remote access via an intermediate system, with encryption and multi-factor authentication.

08Common pitfalls that turn a bastion into a liability

Most jump-server failures are not exotic. They come from treating the host as infrastructure to set up once rather than a privileged asset to defend continuously.

• The jump server is reachable directly from the internet, so it is just a relabeled exposed service.
• OT firewall rules permit the target protocols from broad ranges, not only the jump host, leaving a bypass route.
• The host runs general-purpose software, browses the web or reads email, dissolving its hardened status.
• Shared local accounts and cached credentials accumulate, so one compromise yields keys to many assets.
• Session recording exists but is never reviewed, and logs are stored where an intruder could alter them.
• Patching lags because the jump server is too critical to touch, leaving a privileged host unpatched.

A jump server that is online all the time, lightly patched and rarely reviewed is not a chokepoint. It is a single high-value target with a route into everything behind it.

09Where one-way transfer and exposure reduction fit

A jump server solves a specific problem: brokering interactive human sessions. It is the wrong tool for moving data. Bulk telemetry, log forwarding, historian replication, file export and backup movement should not ride through an interactive broker, because doing so reintroduces the bidirectional reachability the jump server was meant to limit.

For those publication-only flows, a one-way path is a cleaner fit. A controlled connectivity and one-way transfer approach can carry data outward from the OT zone without offering any inbound route, while the jump server handles the rare, supervised case where a human genuinely needs to reach in. The two controls are complementary: one removes the return path for data, the other supervises the return path for people.

Exposure reduction is the connective idea. Even the best jump server is safest when it does not sit online continuously. If interactive access is only enabled during approved, time-boxed windows, and otherwise the path is physically or logically disconnected, the attack surface shrinks dramatically. The narrowest path is the one that does not exist between sessions.

10A practical rollout roadmap

Deploying a jump server is mostly about discipline, not technology. The sequence below tends to produce a control that holds up rather than one that quietly erodes.

• Inventory every existing interactive path into the OT zone, including vendor tunnels and ad hoc remote-desktop enablements.
• Stand up the broker and session host in a dedicated segment, then move OT firewall rules to permit interactive protocols only from it.
• Enforce phishing-resistant MFA, per-target authorization and credential injection so users never hold target passwords.
• Turn on session recording and route tamper-evident logs to monitored, write-protected storage.
• Decommission the old direct paths and confirm, by testing, that targets reject connections from anywhere but the jump host.
• Add a default-disconnected or time-boxed posture so the path is enabled only for approved windows.

Pair this with the governance covered in our vendor remote access article and the data-path separation above, and the jump server becomes one well-understood control inside a defense-in-depth design rather than a single point you are quietly betting everything on.

FAQFrequently asked questions

SRCSources of record