The short answer: A jump server is an intermediary host you connect to first, then “jump” from to reach private systems across a network boundary. It’s a convenient admin pattern, but every jump grants broad access on the far side, and the jump box itself becomes a high-value target and a lateral-movement launchpad. OpenVPN Access Server replaces the pattern with a self-hosted Zero Trust application broker: users authenticate against your identity provider and get access only to the specific resources they’re authorized for — no intermediary host to pivot through, just a hardened OpenVPN endpoint that silently drops unauthenticated traffic in place of an SSH/RDP jump box anyone can probe. If maintaining jump boxes has become an operational and security tax, it’s time to replace them.
What is a jump server?
A jump server (also called a jump host or jump box) is an intermediary machine that administrators and engineers connect to in order to reach systems in another network segment or security zone. You log in to the jump server first — typically over SSH or RDP — and from there “jump” onward to the databases, production hosts, or internal tools that you can’t (and shouldn’t) reach directly.
The defining idea is the pivot: the jump box is a controlled staging point between where you are and where the sensitive systems live. It centralizes the crossing of a network boundary into one auditable place.
Jump server vs. bastion host: what’s the difference?
The two terms overlap heavily and are often used interchangeably, but the emphasis differs:
- A bastion host is defined by its position — a hardened host at the internet-facing edge whose job is to shrink your external attack surface.
- A jump server is defined by its function — pivoting between security zones, which includes internal-to-internal hops, not just external entry.
In short: every bastion is effectively a jump server, but not every jump server sits on the internet edge. Many organizations run internal jump boxes purely to cross segmentation boundaries — that’s the pivoting pattern this article focuses on. If your primary concern is specifically a hardened, internet-exposed edge host rather than internal pivoting, the position-vs-function distinction above is the one to start from.
What is OpenVPN Access Server?
OpenVPN Access Server is a self-hosted secure access platform built on the open-source OpenVPN protocol. Instead of routing admins through an intermediary host, it acts as a Zero Trust application broker: users authenticate against your identity provider, and Access Server grants encrypted, least-privilege access directly to the specific applications and network segments each user is entitled to.
You operate the data plane, the control plane, and the configuration yourself — on your own infrastructure, in your own jurisdiction. Licensing is based on concurrent connected devices rather than per seat.
Why and when is a jump server used?
Teams stand up jump servers for a recurring set of reasons:
- Crossing segmentation boundaries. You’ve divided your network into zones and need a controlled way for admins to reach a more sensitive zone from a less sensitive one.
- Reaching private cloud resources. Engineers need SSH/RDP into instances in a private subnet on AWS, Azure, or GCP without every instance having a public IP.
- Consolidated administrative access. Rather than each engineer connecting directly to dozens of hosts, everyone routes through one jump box that can be logged and monitored.
- Contractor and third-party access. You give an external party a foothold on the jump server rather than opening broad direct access.
- Session recording and audit. Centralizing hops through one host makes it easier to record who did what.
For a small, stable environment with a team that’s comfortable maintaining the box, this pattern is workable.
The problems with the jump server pattern
The convenience of “one box to jump from” comes with structural costs that compound as environments grow:
- The pivot is a lateral-movement gift. A jump server exists to bridge zones. That’s exactly what an attacker wants — compromise the jump box (or its credentials) and you inherit its reach across the boundary it was built to cross.
- Broad access on the far side. Once you’ve jumped, you typically have network-level access to the destination zone, not access scoped to a single application. This is the opposite of least privilege.
- Credential and key sprawl. SSH keys, RDP credentials, and host entries accumulate across users and jump boxes, and cleanly rotating or revoking them is a chronic headache.
- Standing infrastructure to maintain. Every jump box has to be patched, hardened, monitored, and made highly available — and it’s a single point of failure for all the access that flows through it.
- Awkward identity integration. Enforcing MFA, applying group-based policy, and deprovisioning cleanly through your identity provider is rarely native to a jump server.
When does it make sense to replace a jump server with Access Server?
Watch for these signals — if two or more apply, replacement usually pays off quickly:
- You’re pursuing or being audited against a Zero Trust standard. Pivoting through a jump box and roaming a zone is fundamentally at odds with least-privilege access.
- Your engineering team or contractor base is scaling. Key management and lateral-movement risk on jump boxes get worse with every new user and host.
- You maintain multiple jump servers, or can’t afford downtime on the ones you have. Each jump box is standing infrastructure, standing risk, and a single point of failure. A clustered access broker replaces the sprawl and removes the downtime risk.
- You’re subject to DORA, NIS2, or the EU Cyber Resilience Act, or SOC 2. Application-level, identity-driven access is far easier to evidence than “jumped in, then had the run of the zone.”
- Data sovereignty is a requirement. If you’re in the UK or EU and need to guarantee your access layer stays in-jurisdiction, a self-hosted broker keeps the data plane, control plane, and configuration entirely under your control.
- The operational cost of keeping jump boxes hardened and available has stopped being worth it.
The benefits of Access Server as a Zero Trust application broker
Here’s what changes when you retire the jump box.
No pivot point, and a hardened attack surface. Retiring the jump box removes the intermediary that attackers rely on to pivot across zones. Access Server is still a VPN server — so, like any remote-access service, it listens for inbound connections — but it exposes only the OpenVPN protocol rather than an SSH/RDP jump box that answers anyone who connects. That protocol is guarded by an HMAC-based “firewall” on its TLS control channel (tls-auth, and tls-crypt / tls-crypt-v2 in current versions): every control-channel packet must carry a valid HMAC signature from a pre-shared key, and any packet without one is dropped before the TLS handshake even begins. The result is a service that silently ignores port scans and unauthenticated probes — effectively invisible to scanners — while mitigating DoS, UDP port flooding, and attacks against the TLS stack. tls-crypt additionally encrypts the control channel, including the pre-TLS key exchange, hiding the handshake from passive observers. Access Server turns this on by default.
Access to the application, not the network. This is what makes Access Server a Zero Trust application broker, and it’s the cleanest break from the jump-server pattern. Rather than granting a route to a subnet, Access Server grants access to a single named application via network-level access control scoped by domain name rather than by tracking IPs. When a user requests a permitted app, it hands back a synthetic stand-in address from an internal pool (100.64.0.0/10 by default) instead of the resource’s real IP, then does the address translation itself and forwards only that one connection — acting as the intermediary exactly as a commercial identity-aware proxy would ( see exactly how this works ). The consequences: the client never learns the real IP or the private subnet the application lives on; it’s never placed on the same segment as the server, so there’s no residual path to sibling systems and lateral movement becomes structurally impossible rather than merely limited; and because access is defined per application rather than by IP, policy survives IP churn behind load balancers, CDNs, and autoscaling. Compare that to jumping into a zone and then roaming it — the exact behavior this eliminates.
Native identity and MFA integration. Access ties directly to your identity provider — Entra ID and other SAML/OIDC providers — with MFA enforced and group policy applied automatically. Deprovisioning in your IdP instantly revokes access, ending SSH-key sprawl.
High availability — no single point of failure. A jump box is a single point of failure for all the access that flows through it: if it’s down, so is everyone’s path across the boundary. Access Server can instead run as an active-active, high-availability cluster. Multiple nodes share one configuration through a central database and all accept connections at once, appearing to users as a single server (clients reach the cluster via DNS round-robin). If a node fails, another takes the load and users just reconnect — no outage. Clustering also scales horizontally and lets you place nodes closer to your teams, with every node drawing from a single subscription’s shared pool of connections. (On a LAN, a UCARP/VRRP failover pair offers a simpler active/standby option.)
Concurrent-connection licensing. Access Server is licensed by concurrent connected devices, not per seat. For example: if you have 100 devices across 50 users but only 25 are ever connected at peak, you need a 25-connection subscription — not a 50- or 100-seat license. You pay for real simultaneous usage, not headcount.
Complete self-hosted sovereignty. You run the whole stack yourself. Unlike US-operated cloud-broker ZTNA platforms, no third party sits in the connection path and no foreign jurisdiction can compel access to your traffic or metadata — a distinction that matters directly under the CLOUD Act, which generic “data residency” or “encryption” claims do not resolve. For UK and EU organizations working through DORA, NIS2, and the CRA, that self-hosted control is a real compliance advantage.
Built on the open-source OpenVPN protocol. The auditable, battle-tested core is an increasingly important factor in open-source-friendly procurement — not a proprietary black box.
What migration looks like
Retiring jump servers is best done incrementally:
- Map every zone boundary your jump boxes currently bridge, the resources on the far side, and who needs them.
- Deploy Access Server on your own infrastructure and connect it to your identity provider.
- Define least-privilege policies per user or group, mapped to specific applications and segments rather than whole zones.
- Run in parallel, migrating teams onto Access Server while the jump boxes remain as a fallback.
Decommission the jump servers once traffic has moved — removing both the standing infrastructure and the pivot risk. (See how one enterprise NOC team phased this exact migration on AWS.)
FAQ
Is a jump server the same as a bastion host?
They overlap heavily. A bastion host emphasizes a hardened internet-facing edge; a jump server emphasizes pivoting between security zones, including internal ones. In everyday use the terms are often interchangeable.
Is a jump server the same as a VPN?
No. A jump server is a host you connect to and then hop from, granting network-level reach on the far side. A Zero Trust access broker like Access Server authenticates you and grants access only to specific applications — least privilege rather than a flat tunnel.
Isn’t Access Server also exposed to the internet?
Yes — it’s a VPN server, so it listens for inbound connections like any remote-access service. The difference is the exposed surface. Rather than an SSH/RDP jump box that responds to anyone, Access Server exposes only the OpenVPN protocol, whose HMAC-protected control channel (tls-auth / tls-crypt) drops any unauthenticated packet before the TLS handshake begins — so port scans and brute-force attempts get no response, and DoS and TLS-stack attacks are cut off early.
Can Access Server reach private cloud instances without a jump box?
Yes — it brokers encrypted, authenticated access to resources in private subnets without those instances needing a public IP or a standing jump box.
How does Access Server give access to an application without exposing the network?
As a Zero Trust application broker, it grants access to a named application rather than to a subnet. When a user requests a permitted app, Access Server answers with a synthetic stand-in IP from an internal pool instead of the resource’s real address, then translates and forwards that single connection itself. The client never receives a route to the private subnet — it reaches only the authorized app and has no path to anything else on that segment. (Full technical breakdown here.)
Why is a jump server a lateral-movement risk?
Because its entire purpose is to bridge network boundaries. If the jump box or its credentials are compromised, an attacker inherits that same cross-boundary reach — turning your control point into their pivot point.
Is Access Server a single point of failure like a jump server?
It doesn’t have to be. Access Server supports active-active clustering (and LAN failover), so multiple nodes share one configuration and handle connections together. If a node fails, another carries the load and users reconnect automatically, keeping access available.
Does replacing jump servers help with compliance?
Generally, yes. Application-level, identity-driven access with enforced MFA is easier to evidence against DORA, NIS2, the EU CRA, and SOC 2 than broad zone access via a jump host.
What does “Zero Trust application broker” mean?
It’s a service that sits between users and applications, verifies identity on every request, and grants access to one named application at a time instead of a route into a network. Access Server plays this role in place of a jump server: no standing network-level access, no implicit trust just because a connection came from inside the perimeter.
Does replacing a jump server with Access Server count as adopting Zero Trust Network Access (ZTNA)?
Yes. Identity-based authentication, per-application access rather than per-network access, and no implicit trust from network location are the core tenets of Zero Trust Network Access — and they’re exactly what Access Server enforces in place of the jump-server pattern.
Ready to retire your jump boxes?
If maintaining jump servers has become an operational tax and a lateral-movement liability, Access Server gives you a self-hosted, Zero Trust way to reach everything they bridge — without the intermediary host, the pivot risk, or per-seat pricing.
Start your Access Server trial, deploy on your own infrastructure, and connect your identity provider in an afternoon. Estimate your savings: use the cost estimator to compare concurrent-connection licensing against your current setup.