The definition
A jump server — also called a jump host, jump box, or bastion host — is a dedicated system that sits between an untrusted network and a protected one. Administrators authenticate to the jump server, and only from there can they open sessions to the servers, databases, and network devices behind it.
The critical property is not the jump server itself. It is what happens to everything else: protected systems are configured to refuse administrative connections from anywhere except the jump server's address. Without that refusal, a jump server is merely a convenience, and administrators will route around it the first time it is inconvenient.
Why concentrate access deliberately
Concentrating administrative access into one host sounds like building a single point of failure, and in availability terms it is one you must design around. In security terms it is the opposite: it converts an unbounded problem into a bounded one.
Consider what hardening 400 servers to a defensible standard requires — consistent MFA, consistent logging, consistent key management, consistent patch cadence, on 400 machines with different owners and different maintenance windows. Now consider doing it on one machine that every administrative session must cross. The second is achievable. The first, in most organisations, quietly never finishes.
What the traffic actually looks like
In a correctly built deployment there are exactly two hops, and the second one is not reachable from where the first one started:
- Operator to gateway. The administrator authenticates to the jump server from their workstation, over the public internet or the corporate network. This connection carries strong authentication — MFA, and ideally a certificate or hardware token.
- Gateway to target. The jump server opens a second, separate connection to the target system, using a credential the operator may never see. The target accepts this connection because it originates from the gateway's private address, and refuses everything else.
The operator's workstation has no route to the target at all. That is the point. If the workstation is compromised tomorrow, the attacker inherits the operator's session, not the network.
What a jump server buys you
| Property | What it means in practice |
|---|---|
| A single attack surface | One host to harden, patch, and monitor properly instead of hundreds inconsistently |
| A single audit point | Every administrative action crosses one place, so one log answers "who touched this?" |
| Enforced authentication | MFA applies to all privileged access because there is no path that avoids the gateway |
| Blast-radius reduction | A compromised workstation has no network route to protected systems |
| Meaningful absence of evidence | If there is no session record, the access did not happen — a claim you cannot make with scattered logging |
Where a plain jump server falls short
A jump server built from an SSH daemon and good intentions solves the routing problem and very little else. The gaps that show up in assessment, over and over:
- Operators still know the passwords. If administrators type credentials on the jump host, those credentials can be reused, written down, and taken to the next employer.
- Shell history is not a recording. It is editable by the person you are auditing, captures no output, and is trivially bypassed with
ssh targetas a single command. - Access does not expire. A contractor granted access in March is still in the group in November, because nothing removed them.
- The gateway is a stepping stone. A jump server that is not hardened to a documented baseline is simply a convenient staging post for an attacker who reaches it.
These are the problems privileged access management addresses, and they are the reason the industry moved from jump boxes to brokered gateways. The bastion host guide covers the architecture in more depth.
When you need one
You need a jump server when any of the following is true, and most organisations meet several:
- Administrative access to production comes from outside the protected network — remote staff, contractors, or vendors.
- You cannot currently answer "who connected to this system last Tuesday?" without assembling logs from several places.
- You are measured against a framework that requires attributable, reviewable privileged access — CJIS, NIST SP 800-53, SOC 2, ISO 27001.
- You have systems that cannot be patched or hardened themselves, and need the protection applied at the boundary instead.
If none of those apply, you may genuinely not need one yet. If several do, the question is not whether to build the chokepoint but how much control to put at it.