A jump server (also called a jump host or bastion host) is a hardened intermediary machine that users must connect to first before they can reach systems inside a protected network zone. It exists to funnel all access through a single, monitored point instead of letting users connect directly to sensitive machines. It is a useful control, but on its own a jump server concentrates access without necessarily binding each session to a verified identity, scoping it to one task, or recording what the user did.
What is a jump server?
A jump server sits between two networks of different trust levels, for example between a corporate network and a segmented server subnet or an industrial network. A user logs into the jump server, and from there opens a further connection to the target system. Because every path runs through that one host, administrators can monitor and harden a single machine rather than exposing every internal system. It is a decades-old pattern for administering systems across a security boundary.
Jump server vs bastion host
The terms are used almost interchangeably. A bastion host traditionally means a hardened, internet-facing machine deliberately exposed as the single entry point into a private network, hardened precisely because it is exposed. A jump server (or jump host) emphasizes the hop: the intermediary you land on to reach systems in another zone. In practice most teams use "jump server," "jump host," and "bastion host" to describe the same role, an intermediary that concentrates and controls access across a boundary.
How is a jump server used in OT?
In operational technology, a jump server is a common way to give engineers and vendors a route into the control network without wiring them directly to PLCs and SCADA. The remote user reaches the jump server in a DMZ, then jumps inward. It is often paired with a VPN for the outer connection and network segmentation to define the zones.
What are the limitations of a jump server?
A jump server is a location, not a policy. By itself it does not answer the questions that matter for privileged access:
- Identity per session. A shared jump-server login tells you a session happened, not who was behind it.
- Least privilege. Once a user is on the jump server, what stops them reaching more than the one system they came for? That takes additional configuration the jump server does not enforce on its own.
- Recording. A plain jump server does not record what commands were issued to the target, which is what an audit or incident review needs.
- It is a target. A compromised jump server becomes a launch point into everything behind it, which is exactly why attackers seek them out.
What is a modern alternative to a jump server?
A mediating access broker, sometimes called an industrial proxy, keeps the one-controlled-path benefit of a jump server while closing its gaps. Rather than logging a user onto a shared box and trusting them to behave, the broker authenticates each user, grants access to a single target system for a single task, and records the whole session, all without the user ever landing on the network. For OT specifically, it does this in front of controllers that cannot authenticate or record on their own.
Trout's Access Gate is that broker: it replaces or fronts a jump server with identity-bound, least-privilege, recorded access to OT systems, agentless on the equipment and built for resilience. See secure OT remote and vendor access and what is an industrial proxy.
