Many organisations believe a hardened jump server makes the administrator's laptop irrelevant, but a jump server only moves the session; it does not clean the device that starts it. A privileged access workstation (PAW) and a jump server solve different problems: the PAW protects the source of the session, the jump server controls the path and the point of entry to the target. This guide compares the two as architectures, sets out the threat model each one addresses and leaves open, explains how session brokering and cloud-native access services change the picture, and gives a decision method for choosing a PAW, a jump host or both. It is for architects who own the admin path. For the PAW build see the Privileged Access Workstations Guide; for hardening the intermediary see Securing the jump host and bastion itself, and for response see If your jump host and bastion is compromised.
Key takeaways
- They are not substitutes. A PAW answers "can I trust the device the admin is typing on?" and a jump server answers "which path may admin traffic take to the target?". Choosing one does not answer the other question.
- A jump server inherits the trust of the weakest device that reaches it. The UK NCSC states that an administration proxy alone will not stop a compromised management device; keystrokes, screens and live sessions still pass through the infected laptop.
- Jump servers concentrate risk. Microsoft describes them as hosts where many or all sensitive sessions pass through, which makes them one of the most attractive targets in the estate, so they need privileged-level controls of their own.
- The strongest design uses both, in order. PAW as the clean source, a brokered intermediary (jump host, bastion service or identity-aware proxy) as the enforced path, and the target refusing anything that did not arrive that way.
- Cloud-native brokers shrink the jump server problem but not the device problem. Services that remove inbound ports and public IPs replace the shared host, yet the device that runs the browser or CLI is still a security dependency.
Short answer
Use a PAW for any role whose compromise would give control of identity, the cloud control plane, hypervisors, backups or the privileged access tooling itself. Use a jump server, or better a managed session broker, when you need a single enforced network path into a segment, session recording, or access to legacy targets that cannot enforce device conditions themselves. For Tier 0 and control plane work, use both: a jump server reached from an ordinary laptop is a "browse up" design, which the NCSC calls an anti-pattern because the administrator is working from a device less trusted than the system being administered.
| Dimension | Privileged access workstation (PAW) | Jump server (jump host, bastion) |
|---|---|---|
| What it protects | The source: the device where keystrokes, credentials, tokens and the screen live | The path: the single point through which admin traffic enters a segment or target |
| Primary threat addressed | Phishing, drive-by malware and credential theft on the admin's own device | Direct exposure of admin interfaces, uncontrolled routes into server networks, lack of audit |
| Threat it leaves open | Exposed admin interfaces if targets accept connections from anywhere | A compromised source device driving the session; credential theft on the shared host |
| Blast radius if compromised | Everything that one admin can reach while signed in | Every session, credential and target that passes through it |
| Typical enforcement point | Device compliance and device filters at the identity provider; logon restrictions at targets | Network rules that allow admin ports only from the jump host subnet; broker policy |
| Framework anchor | CIS Controls v8.1 Safeguard 12.8 (dedicated computing resources for administrative work) | NIST SP 800-53 AC-17(3) Managed Access Control Points; SC-7 Boundary Protection |
The clean source principle and why the jump server cannot satisfy it
Microsoft's privileged access guidance states that end-to-end Zero Trust for privileged access needs a strong foundation of device security, and that while security assurances "can be enhanced in the session, they are limited by how strong the security assurances are in the originating device". The same document notes that a compromised device undermines assurances on the account, on intermediaries like jump servers and on the resources themselves. That sentence is the whole argument of this guide in one line: the jump server sits downstream of the device, so it cannot repair what happened upstream.
The NCSC reaches the same conclusion. Its first secure system administration principle is to gain trust in management devices, and it classes a jump box as a management device. Its guidance on administration interfaces calls bastion hosts and jump boxes "administration proxies" that can centralise authentication, policy and logging, then warns that a proxy alone will not stop a compromised management device, and that MFA is not bulletproof because an attacker controlling the admin device can hijack a session after MFA completes.
Threat model: a compromised endpoint driving the jump host
Assume an administrator's everyday laptop is compromised by a phishing payload, and the admin connects through a well-hardened jump server. What the attacker can still do, without touching the jump server's hardening at all:
- Capture input: log the keystrokes typed into the RDP or SSH client, including passwords and one-time codes (ATT&CK T1056.001 Keylogging).
- Ride the live session: inject input into the open remote session or watch the screen, acting as the admin while the session is open. MFA has already been satisfied.
- Steal portal and broker tokens: if the jump server or bastion is reached through a web portal, the browser session cookie on the laptop is the key (T1539 Steal Web Session Cookie).
- Harvest client-side secrets: SSH private keys, saved RDP connection files, credential manager entries and agent sockets on the laptop give direct or later access.
The Uber breach in 2022 illustrates the source problem: Uber said the contractor's password was likely bought after malware infected the contractor's personal device, and the attacker then pushed MFA prompts until one was accepted. Downstream hardening cannot fix an untrusted starting point.
Threat model: the jump server itself
Microsoft's intermediaries guidance describes remote desktop and jump servers as hosts where "many or all sensitive sessions pass through", enabling standard credential theft tools to steal and reuse those credentials, an "all your eggs in one basket" target. The specific risks are:
- Credential exposure on the shared host: interactive logons leave credential material in memory that local admin on the host can extract (T1003.001 LSASS Memory) and replay (T1550.002 Pass the Hash). See the Pass-the-Hash and Pass-the-Ticket Guide.
- Session takeover: anyone with SYSTEM on a multi-user Windows jump server can attach to another user's disconnected session (T1563.002 RDP Hijacking).
- Onward reach: the host may reach admin ports (RDP 3389, SSH 22, WinRM 5985/5986) across the segment, so compromise hands over that network position (T1021.001, T1021.004).
Architecture of each option in words
PAW only
A dedicated deny-by-default device connects directly to targets, which accept admin sign-ins only from PAWs (device filters, authentication policy silos, admin ports open only from PAW subnets). Strong at the source, but each target enforces the path alone and there is no central choke point for recording or for reaching flat legacy networks.
Jump server only
Admins connect from everyday laptops to a shared hardened host, the only system allowed to reach admin ports in the segment. Central logging and one path, but browse up for every admin and credentials concentrated on one host.
PAW plus jump server or broker
The PAW is the only device allowed to reach the broker, the broker is the only path to the targets, and the targets refuse anything else. This matches the NCSC's browse down plus tiered administration and Microsoft's enterprise access model. See the Tiered Administration and Enterprise Access Model Guide.
Cloud-hosted admin desktop
A cloud PC or virtual desktop built like a PAW moves the desktop off the laptop, but the device that displays it and captures keystrokes is still a dependency. A cloud desktop reached from a personal laptop is a jump server with a better user interface.
Session brokering: what changes when the jump server becomes a service
Cloud providers and PAM platforms increasingly replace a self-managed Windows or Linux jump host with a brokered service. Platforms are listed alphabetically.
| Service (provider) | How the path works | What it removes | What still depends on the source device |
|---|---|---|---|
| AWS Systems Manager Session Manager | Agent on the node opens an outbound channel; access is governed by IAM policies; sessions logged to CloudTrail, with session data optionally sent to S3 or CloudWatch Logs | Inbound SSH and remote PowerShell ports, bastion hosts and SSH key management, per AWS documentation | The IAM credentials or SSO session on the admin's device; session content logging does not cover port forwarding or SSH tunnelled through it |
| Azure Bastion | RDP and SSH over TLS on port 443 through the Azure portal or native client to VMs on private IPs | Public IPs and exposed RDP/SSH on VMs; session recording on the Premium SKU | The device running the Azure portal session, which Microsoft says must meet the appropriate (typically privileged or specialised) level |
| Google Cloud Identity-Aware Proxy TCP forwarding | Encrypted tunnel over HTTPS to the VM's internal address; firewall allows only 35.235.240.0/20; IAM role roles/iap.tunnelResourceAccessor | External IP addresses on VMs | The gcloud credentials and browser session on the admin's device |
| PAM session managers (vault-integrated proxies) | Admin authenticates to the PAM portal; the proxy injects a vaulted credential and records the session | Admins knowing target passwords; unrecorded sessions | Microsoft notes that PIM/PAM controls "do not address many privileged access risks, notably risk of device compromise" |
Brokers remove the shared Windows host with interactive logons (and with it most RDP hijacking and LSASS harvesting on the jump host), turn access into an identity decision with just-in-time grants and centralise logs. They do not change the right-hand column. See the Privileged Session Management Guide and the Identity-Aware Proxy Guide.
Credential handling on the hop
Where a Windows jump host remains, Microsoft documents two RDP options. Remote Credential Guard redirects Kerberos requests back to the client so credentials never reach the target, keeps single sign-on and multi-hop, needs Kerberos and is not supported through Remote Desktop Gateway or Connection Broker. Restricted Admin mode connects as the remote host's identity and blocks pass the hash, without single sign-on or multi-hop. Both protect against a compromised target; neither protects against a compromised client, which is the PAW's job. See the Remote Desktop (RDP) Security Guide.
Combined tiered design
The NCSC groups administration into tiers by impact of compromise, Tier 0 being the most critical, and warns against administering a higher-tier system from a lower-tier one. Map PAWs and intermediaries to tiers rather than deciding once for the whole organisation.
| Tier and example targets | Source device | Path | Enforcement at target |
|---|---|---|---|
| Tier 0: domain controllers, AD CS, identity provider admin, PAM and vault admin, backup and hypervisor management | PAW, separate build per tier where volume justifies it | Direct from PAW to cloud consoles; dedicated Tier 0 jump host or broker for on-premises Tier 0, reachable only from PAW subnet | Device filters for privileged roles; authentication policy silos; admin ports open only from PAW or Tier 0 jump subnet |
| Cloud control plane: tenant owners, organisation admins, root and break-glass | PAW | Provider console or CLI from PAW; broker (bastion, IAP, Session Manager) for workloads | Device or network conditions on admin roles; break-glass excluded and alerted |
| Tier 1: application and database servers | Specialised device, or PAW if the role touches Tier 0 paths | Broker or Tier 1 jump host with recording | Admin ports only from the Tier 1 path; vaulted or just-in-time credentials |
| Legacy and OT segments without modern auth | PAW | Dedicated jump host in the segment (often the only practical option) | Segment firewall allows admin protocols only from that jump host |
Two rules keep the design honest: never share a jump host across tiers, and treat the administrators of any broker or jump host as Tier 0 on PAWs. Microsoft says only personnel protected at a specialised or privileged level should hold admin rights on an intermediary.
Decision criteria
- What can this role change? If it can create identities, reset MFA, change federation, delete backups or reach the vault, it needs a PAW regardless of what the path looks like.
- Can the target enforce device trust itself? Cloud consoles and identity providers usually can (device compliance, device filters). Legacy servers, network devices and OT usually cannot, which is where a jump host or broker in the segment earns its place.
- Do you need recording or four-eyes review? Session recording is an intermediary function. If a regulator, customer or internal policy requires it, plan a broker or recorded jump host.
- Are third parties involved? You cannot make a vendor's laptop a PAW, so use a brokered, recorded, time-boxed path to tightly scoped targets.
- What happens when it is down? The NCSC warns a proxy is a single point of failure: plan availability and monitored break-glass first.
Small versus large organisations
Small: two dedicated laptops for the identity provider, cloud console and backups, a cloud-native broker instead of a self-managed jump host, and conditional access requiring those devices. Skip the Windows jump server entirely unless a legacy system forces it.
Large: PAW builds per tier, brokers per environment, a Tier 0 jump path for on-premises identity systems, and the PAW estate, brokers and PAM platform treated as Tier 0 assets.
Worked scenario
A mid-sized company runs Active Directory on premises, a cloud tenant with production workloads and a small OT network. Twelve server admins and three identity admins use a shared Windows jump server reached over VPN from their everyday laptops. A phishing payload lands on one identity admin's laptop.
- Today: the attacker logs keystrokes into the RDP client, captures the domain admin password and an OTP, and watches the admin open a session on a domain controller through the jump server. The jump server's own hardening is intact and its logs show a legitimate admin session. The same captured password works on the cloud identity console, which never went through the jump server.
- Redesign, step one: the three identity admins get PAWs. Conditional access requires a PAW device filter for privileged directory roles; Tier 0 accounts are denied logon outside Tier 0 hosts. The phishing payload now lands on a laptop that holds no Tier 0 credentials.
- Step two: the shared jump server is split and server admins move to specialised devices with no route to Tier 0. Cloud workloads move to the provider's broker with just-in-time IAM grants; a dedicated Tier 0 jump host for domain controllers accepts connections only from the PAW subnet; the OT segment keeps its own jump host, reachable only from PAWs, with session recording.
- Result: the same phishing email now compromises a device that cannot reach Tier 0, and a stolen server-admin credential cannot be replayed into the identity console because the device condition fails.
Cost and usability trade-offs
| Factor | PAW | Self-managed jump server | Managed broker |
|---|---|---|---|
| Up-front cost | Devices and build engineering per admin | Hosts, licences, hardening work | Low; service charges, some billed from deployment whether used or not |
| Ongoing effort | Allow-list maintenance for apps and URLs, refresh cycle | Patching, credential hygiene, availability, log retention | Policy and IAM review; agent or network configuration |
| Admin friction | Highest: second device, blocked browsing | Medium: extra hop | Low to medium: identity-driven access |
Where identity fits
Both controls fail if accounts are not separated: dedicated admin accounts (CIS Controls v8.1 Safeguard 5.4) used only from the PAW, phishing-resistant MFA and just-in-time privilege. Non-human identities matter too: automation that runs through a jump host often uses a service account or SSH key stored on the host, turning it into a secrets store. Move it to brokered, short-lived credentials or per-session SSH certificates. See the JIT Access Guide and the SSH Protocol and Certificate Authority Guide.
Detection and measurement
- Bypass of the path: alert on any admin protocol connection (3389, 22, 5985/5986) to Tier 0 or server segments from a source other than the PAW subnet, jump host or broker.
- Bypass of the device: privileged role sign-ins that fail or would fail the PAW device condition; report-only conditional access results are a good early signal.
- Jump host abuse: Windows logon events 4624 with logon type 10 (RemoteInteractive) from unexpected sources, session reconnect events 4778 and 4779 for session hijacking, and new local administrators on the host.
| Metric | Target |
|---|---|
| Percentage of Tier 0 and control plane sign-ins from PAW devices | 100% excluding monitored break-glass |
| Admin protocol connections to server segments not via the approved path, per month | Zero, each one investigated |
| Privileged sessions recorded where policy requires | 100% |
| Standing (non just-in-time) grants to broker access | Falling quarter on quarter |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-17 Remote Access; AC-17(1) Monitoring and Control; AC-17(3) Managed Access Control Points | The jump server or broker as the managed access control point, with monitoring |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-7(15) Networked Privileged Accesses | Routing privileged access through dedicated, managed interfaces |
| NIST SP 800-53 Rev. 5 | AC-6(5) Privileged Accounts; AC-2(7) Privileged User Accounts; AU-14 Session Audit | Separate admin accounts and session audit through the intermediary |
| CIS Controls v8.1 | Safeguard 12.8 dedicated computing resources for administrative work; Safeguard 5.4 restrict admin privileges to dedicated admin accounts | The PAW requirement and account separation |
Common failure patterns
- The jump server as a PAW substitute: admins connect from email-and-browsing laptops, so the hardened host faithfully relays an attacker's input. This is the browse-up pattern the NCSC warns against.
- Enforcing the path on servers but not in the cloud: domain controllers accept RDP only from the jump host, while the identity provider console accepts the same admins from any device, so stolen credentials go around the jump server.
- One jump host for every tier: help desk, server and domain admins share the same Windows host, leaving Tier 0 credential material where Tier 1 and Tier 2 admins can reach it.
- Jump host admins on ordinary laptops: the people who patch and configure the intermediary are not on PAWs, so compromising one of them compromises every session.
- No break-glass route: the broker becomes mandatory without high availability or a monitored emergency path, so the first outage produces an undocumented firewall exception that never closes. See the Break-Glass Account Guide.
Practitioner checklist
- List every role that can change identity, control plane, backup, hypervisor or vault configuration and issue PAWs to those roles first.
- For each target, record whether it can enforce device trust itself; place a broker or jump host only where it cannot, or where recording is required.
- Make targets refuse admin connections that do not come through the approved source and path, starting in report-only or audit mode.
- Split shared jump hosts by tier and require PAWs for the administrators of every jump host and broker.
- Use Restricted Admin mode with Windows LAPS for help desk RDP and Remote Credential Guard where Kerberos and direct connections apply.
- Remove stored keys, saved credentials and scripts from jump hosts; move automation to brokered, short-lived credentials.
- Build a highly available broker path and a monitored break-glass route before making the path mandatory.
- Alert on admin protocol connections from unexpected sources and on privileged sign-ins that fail the device condition.
Standards and references
- NCSC: Secure system administration, protect your administration interfaces
- NCSC: Secure system administration, gain trust in your management devices
- NCSC: Secure system administration, risk manage administration using tiers
- Microsoft: Securing privileged access intermediaries
- Microsoft: Securing devices as part of the privileged access story
- Microsoft: Remote Credential Guard
- AWS: AWS Systems Manager Session Manager
- Google Cloud: Using IAP for TCP forwarding
Related NHI Mgmt Group resources: Privileged Access Workstations Guide · Securing the jump host and bastion itself · Privileged Session Management Guide · Tiered Administration and Enterprise Access Model Guide · Azure Bastion