A jump host, also called a bastion host or jump box, is a single hardened server that sits between an outside user and the control network, so that every remote session has to pass through it before it can reach a PLC, HMI, or SCADA server. It exists to create one guarded doorway into the control system instead of many unguarded ones. This page explains what a jump host is, why funneling all access through one intermediary makes an OT environment easier to defend, and how it differs from the broader idea of secure remote access.
Jump Host / Bastion Host in one line: A jump host is a dedicated, tightly locked-down machine that acts as the only permitted stepping stone between an external network and the OT network - a user connects to the jump host first, and only from there can they open a session to a control-system device. It concentrates remote access into one monitored, hardened chokepoint so that direct connections from the outside world to sensitive controllers are blocked entirely, making access easier to control, log, and revoke.
Control systems frequently need to be reached from outside: a vendor supporting a controller, an integrator adjusting logic, an engineer troubleshooting from home. The dangerous way to allow this is to expose the devices themselves - opening a path from the internet or the corporate network straight to an HMI or PLC. That creates many exposed targets, each a potential entry point, and each one hard to watch. If every device is individually reachable, the attack surface is enormous and no one can say with confidence who reached what.
A jump host collapses that sprawl into a single point. Instead of many doors into the control network, there is exactly one: users must land on the bastion first, and the network is configured so that nothing on the outside can talk directly to a controller. The control devices only accept connections that originate from the jump host's address, and the jump host is the only machine allowed to straddle the boundary. Everything else is denied by the firewall between the zones.
That single doorway is what makes the arrangement defensible. Because all remote access converges on one machine, that machine can be watched closely, patched carefully, and instrumented so every session that passes through it is recorded. If access needs to be shut off in an emergency, there is one lever to pull. The whole value of the pattern comes from refusing to let anyone bypass the intermediary.
A jump host earns the name bastion by being stripped down and heavily fortified. It runs only the minimum software needed to broker connections - typically just a remote-access service - with every unnecessary application, service, and port removed, because anything present is something that could be exploited. It is kept fully patched, since it is deliberately the most exposed machine and cannot afford known holes. Its purpose is narrow on purpose: it brokers sessions and does nothing else.
Strong authentication is central to a real bastion. Because it guards the entire control network, logging into it should require more than a password - a second authentication factor is standard, so a stolen credential alone does not open the door. Accounts are individual rather than shared, and access is scoped so each person can only reach the systems their role requires. The host logs and often records sessions, giving a complete audit trail of who connected, when, and what they touched.
A jump host is not the same as the overall secure-remote-access strategy - it is the concrete piece of infrastructure that strategy is usually built around. Secure remote access is the whole set of policies, encryption, authentication, and approvals that govern how outsiders reach OT. The bastion is the physical or virtual box where much of that policy is enforced in one place. You can have remote-access rules without a jump host, but the jump host is what turns those rules into a single, inspectable checkpoint.
For remote oil and gas operations, the jump host is often how support actually happens. A control system integrator or a vendor supporting a SCADA package rarely needs to be on site; they need a session into a specific server or controller. Routing that session through a bastion means the operator keeps control of the front door: access is granted for a task, logged in full, and cut off when the work is done, all without ever exposing the controller directly to the vendor's network.
This matters more as monitoring moves toward the cloud. A cloud SCADA platform like Merobix delivers dashboards and data over the internet by design, but the deeper engineering access - reaching a PLC to change logic or a local server to reconfigure it - is a different and far more sensitive path. A jump host keeps that engineering path separate and guarded, so the convenience of remote visibility does not accidentally become a convenient way for an attacker to reach the controllers.
The operational payoff is a clean audit story and a fast kill switch. When every remote engineering session runs through one bastion, an operator can answer who was in the system and when, and can revoke all outside access by disabling one host. On unmanned or lightly staffed sites, where the alternative is trusting that no exposed device was left open, that concentration of control is exactly what makes remote support workable without leaving the process defenseless.
A VPN extends a trusted network to a remote user, so once connected they can reach many devices as if they were on the local network. A jump host does the opposite: it forces the user onto one specific hardened machine, and only from there can they reach individual devices, with each hop controlled and logged. The two are often combined, with the VPN getting a user to the boundary and the jump host controlling what they can do once there.
A bastion is a fortified projection of a castle wall built to withstand attack while protecting what is behind it. A bastion host is named for the same idea: it is the deliberately exposed, heavily hardened machine that faces the less trusted network so the control systems behind it never have to. It is expected to be attacked, which is exactly why it is stripped down and locked tight.
No, it enforces them in one place. The jump host is the infrastructure; the secure remote access policy is the set of rules about who may connect, how they authenticate, what they may reach, and how it is approved and logged. The bastion is where much of that policy becomes concrete, but it works only when the surrounding rules, firewall settings, and authentication are configured to route everything through it.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.