What Is a Bastion Host? Jump Servers and Admin Access

The purpose is consolidation. Without one, administrative access to a protected environment is a set of individual paths — a management port forwarded here, a VPN exception there, a vendor's remote-support tool somewhere else, each with its own authentication, its own logging and its own owner. Every one of those paths has to be hardened, monitored and reviewed, and in practice they are not, because there is no single place to do it. A bastion collapses that set into one path that can be hardened properly, logged completely, and turned off in a single action.

Two deployment patterns dominate, and they are the same idea at different boundaries. The first is the externally facing bastion: a hardened host in a screened segment that accepts administrative connections from outside and brokers them inward, so no management interface is directly exposed to the internet. The second is the internal jump host, which brokers access from the general corporate network into a segmented enclave — an operational-technology or industrial network, a payment environment, a directory and identity tier, a laboratory or evidence network — so that a compromised office laptop has no route into the enclave at all.

In both cases the value comes from what the firewall policy around it can now say. Inbound, only the bastion is reachable, on one protocol, from a defined set of sources. Outbound from the bastion, only management protocols to the specific systems it is meant to reach, never a general permit. And nothing behind the boundary accepts administrative connections from anywhere else. Those three rules are the control. The host is just where they meet.

The distinction between a bastion and a jump server is mostly one of position and exposure rather than technology. Bastion tends to mean the hardened host at an external boundary, sized and configured on the assumption that hostile traffic reaches it constantly. Jump server, or jump box, tends to mean the internal intermediary between one trust zone and a more sensitive one. Plenty of environments run both, with an external bastion admitting a remote administrator to a management segment and an internal jump host controlling entry from there into a specific enclave. The terms are used interchangeably often enough that it is worth stating which you mean in a design document.

A privileged access workstation is a different thing entirely, and confusing it with the other two is the most consequential terminology error in this area. A PAW is the endpoint the administrator physically uses — a dedicated, hardened device reserved for administrative work, kept away from email, general web browsing and productivity software, and managed separately from ordinary corporate laptops. Microsoft's privileged access guidance, now framed as the Enterprise Access Model after replacing the older tiered terminology, is built on the principle that a privileged session must originate from a device at least as trusted as the systems it administers.

That principle is the reason the three are complementary rather than alternatives. A jump server secures the path; a PAW secures the origin. An administrator who opens a session to a perfectly hardened bastion from the same laptop they use for email has moved the credential onto the bastion from a machine that reads attachments, and a keylogger on that machine sees everything typed into the session regardless of how the bastion is configured. Building the middle of the chain and leaving the ends is a common and expensive pattern.

A bastion that is simply a server with SSH open and everyone's account on it is not a security control; it is an inconvenience for administrators and a convenience for an attacker, because it is now one compromise away from a curated list of high-value targets. The properties that make the difference are specific. Single purpose: no general-purpose software, no browsing, no mail client, no development tools, nothing that is not required to broker sessions. Minimal attack surface: one inbound protocol, everything else disabled, and a hardened operating-system baseline built from a published benchmark such as a DISA STIG or an equivalent, rather than a default install with a few settings changed.

Identity and credentials are where most deployments are weakest. No shared administrative accounts — every session is attributable to a person. Multi-factor authentication at the bastion, and again at the target where the target supports it, so that possession of the bastion is not possession of everything behind it. And critically, no standing credentials on the host: caching passwords, storing private keys, or forwarding an authentication agent through the bastion all turn it into a place where credentials accumulate, which is precisely the property you were trying to avoid. Where the protocol supports it, use a mechanism that lets the bastion broker a session without ever holding a reusable secret.

Then make it observable. Session logging — commands, or full session recording where policy requires it — shipped off the host in real time to a log platform the bastion itself cannot alter, because logs stored only on a compromised machine are logs an attacker edits. Alert on the bastion's own events at a lower threshold than anywhere else: a first-time login from a new location, an authentication failure burst, a configuration change, a new listening port. And patch it fastest, because it is exposed by definition and its exposure is the whole design. The vaulting, brokering and recording layer is a product category of its own — privileged access management — and where a platform is used, the same properties are what to evaluate it against rather than the feature list.

An externally reachable bastion belongs in a screened segment, not on the internal network. The firewall policy should permit the internet, or a defined source range, to reach the bastion on one port; permit the bastion to reach specific management addresses on specific management ports; and permit nothing else in either direction. In particular the bastion should have no path into general user space and no reason to initiate outbound internet connections beyond patching, which itself is better served through a controlled repository than a direct route out.

The stronger arrangement is to keep management traffic off the operational network entirely. NSA and CISA guidance on out-of-band network management recommends separating management from operational data flow, treats a physically separate management infrastructure as the most secure option, and recommends that network devices accept management connections only from that network and only from dedicated management hosts. In that model the bastion is the entry point to the management network, and the devices behind it are unreachable from the production network by construction rather than by policy. Console servers and remote console switches sit in the same design, providing access to a device whose network interface is the thing that has failed.

For federal civilian agencies there is a directive that bears on this directly. CISA's Binding Operational Directive 23-02, issued in June 2023, requires networked management interfaces exposed to the public internet to be removed from it, or placed behind a policy enforcement point separate from the interface itself, within fourteen days of discovery — and names the second option as the preferred course of action. A bastion in a screened segment satisfies the removal half. The directive's preference for a separate policy enforcement point is a pointer toward the brokered, identity-based model described below, and it is worth reading the directive rather than inferring it.

Concentrating access concentrates risk. An attacker who compromises the bastion inherits three things at once: a list of the systems worth attacking, a legitimate network path to them, and credentials or sessions in flight. That is a better position than compromising any individual server, which is why the hardening is not optional and why the monitoring has to be genuinely different from what a general server receives. Treat a successful login to the bastion as a security-relevant event in its own right rather than as routine noise.

It concentrates availability risk too, and this is under-planned. If the bastion is the only administrative path and it fails — hardware, a bad patch, a certificate expiry, a firewall change, or the incident itself — nobody can administer anything at the moment administration is most needed. The mitigations are ordinary and need to exist before they are needed: at least two brokers in different failure domains, a documented and rehearsed break-glass procedure with credentials held in escrow and their use alarmed, and out-of-band console access that does not depend on the same network path.

The most effective reduction is to stop granting standing access. If administrative accounts exist permanently, with permanent firewall rules and permanent group membership, then compromising the bastion yields permanent access. Just-in-time access inverts that: entitlement is requested and approved for a defined window, the account or rule exists only during it, and it expires automatically. It reduces the value of compromising the broker, it produces an approval record for every privileged session, and it converts a standing list of who could log in into a much shorter record of who actually did.

The argument that bastion hosts are obsolete rests on a real change. A zero-trust network access broker or identity-aware proxy inverts the connection model: the internal connector dials outward to the broker, so nothing is listening on the public internet at all, and there is no host to scan or exploit. Access is granted per application rather than per network, authorization is evaluated per session against identity and device posture, and it can be re-evaluated while a session is running. NIST SP 800-207 describes this policy-enforcement-point pattern as the core of a zero-trust architecture, and for an estate of modern applications and cloud consoles it is a genuinely better design than an exposed host that hands out network reachability.

The honest limit is that the model assumes a target which speaks identity. Plenty do not. A serial console on a router, an industrial controller with a fixed protocol and no concept of a user, an out-of-band management processor, a laboratory instrument, an appliance whose management interface predates modern authentication — for these, something has to sit adjacent to them and speak their protocol, and that something is a jump host whatever it is called. There is also a resilience argument: a broker that depends on an external identity service and internet reachability is exactly the wrong dependency for the scenario where the network is broken, which is why out-of-band management paths persist alongside it.

The practical position most organizations land in is both, deliberately divided. A zero-trust broker for applications, cloud consoles and anything with a modern identity integration; a hardened jump host, ideally reached through that broker rather than directly from the internet, for the infrastructure and enclaves that cannot participate. The question worth answering in a design review is not which technology, but which targets are behind which broker, who may reach each one, and whether anyone has written that down — because the failure mode in this area is almost never the chosen architecture. It is the third path somebody added for a vendor two years ago and nobody removed.