Skip to main content
Commerce Security Authority
Category: Network Security

Jump Server

Also known as: Jump Host, Jump Box
Simply put

A jump server is a secure, tightly controlled computer that acts as a gateway between a less trusted network and a more trusted one, letting authorized users 'jump' from one to the other to reach and manage systems in a protected zone. Instead of connecting directly to sensitive systems, users route their access through this single, monitored entry point. This concentrates access into one place that can be hardened and watched more closely.

Formal definition

A jump server (also called a jump host or jump box) is a hardened intermediary system used to access and manage devices that reside in a separate security zone. It funnels administrative traffic through firewalls over a supervised secure channel, typically using protocols such as SSH or RDP, so that connections between networks of differing security contexts pass through a single controlled and auditable chokepoint. Because it bridges trust boundaries, a jump server is a high-value target and is generally hardened, access-restricted, and monitored; note that 'jump server' describes an access-control architecture role and is not a term defined by PCI DSS itself. Where such systems provide entry into an environment containing cardholder data, their configuration, access controls, and logging should be assessed against the applicable requirements of the current published PCI DSS version rather than assumed against a fixed requirement number.

Why it matters

A jump server matters because it concentrates administrative access into a single, controllable chokepoint rather than allowing many direct connections into a sensitive network. When systems that hold or process cardholder data can only be reached by first passing through one hardened, monitored gateway, an organization gains a defensible place to enforce access controls, capture logs, and watch for anomalous activity. This design supports the segmentation and least-privilege principles that reduce the attack surface exposed to a less trusted network.

The same property that makes a jump server useful also makes it a high-value target: because it bridges trust boundaries, an attacker who compromises it may gain a path toward the protected zone. For that reason the jump server itself must be hardened, tightly access-restricted, and closely monitored, and its own credentials and sessions treated as sensitive. A poorly maintained jump box can become the weak link it was meant to eliminate.

Note that 'jump server' describes an access-control architecture role and is not a term defined by PCI DSS itself. Where a jump server provides entry into an environment containing cardholder data, its configuration, access controls, and logging should be assessed against the applicable requirements of the current published PCI DSS version rather than assumed against a fixed requirement number. A jump server is intended to help reduce and control access, not to guarantee protection on its own.

Who it's relevant to

Security Engineers
Security engineers design and harden jump servers as the controlled chokepoint between less trusted and more trusted networks. They are responsible for restricting access, configuring secure channels over protocols such as SSH or RDP, and ensuring the system is monitored, since a compromised jump server can expose the protected zone it is meant to guard.
Compliance Officers and Assessors
Because a jump server may serve as the entry point into an environment containing cardholder data, its configuration, access controls, and logging should be evaluated against the applicable requirements of the current published PCI DSS version. Compliance teams should confirm the relevant requirement wording against the current standard rather than assuming a fixed requirement number, and should remember that 'jump server' is an architecture role, not a PCI DSS-defined term.
IT and DevOps Administrators
Administrators who manage systems inside a protected security zone route their access through the jump server rather than connecting directly. They rely on it for supervised, auditable sessions to servers, databases, and other devices, and must treat its credentials and access as privileged and sensitive.
Payment Processors and Merchant Risk Teams
Organizations operating environments that store or process cardholder data can use a jump server to concentrate and monitor administrative access as part of their segmentation strategy. It is intended to help reduce the attack surface exposed to less trusted networks, but its assurance depends on ongoing hardening, monitoring, and validation rather than the presence of the control alone.

Inside Jump Server

Bastion host role
A jump server (also called a bastion host) is a hardened, tightly controlled intermediary system that administrators connect to first before reaching systems in a more sensitive network segment. In PCI DSS contexts it is commonly used to broker administrative access into the cardholder data environment (CDE) rather than allowing direct connections from less-trusted networks.
Access brokering and network segmentation
The jump server sits at a controlled boundary between an administrative or corporate network and a more sensitive segment. It concentrates administrative traffic through a single, monitored chokepoint, which supports segmentation objectives but does not by itself establish or validate segmentation. Segmentation effectiveness must be confirmed through configuration and testing, not assumed from the presence of a jump server.
Multi-factor authentication (MFA) at the access point
Access to a jump server that fronts sensitive systems is typically protected with multi-factor authentication. MFA here addresses the risk of compromised administrator credentials at the point of access; it is one control among several and does not address other risks such as session hijacking after authentication or vulnerabilities on the target systems.
Logging, monitoring, and session recording
Jump servers are often configured to log authentication events and administrative activity, and in some implementations to record sessions. These logs support monitoring and forensic review. Logging is intended to aid detection and investigation and does not prevent unauthorized actions in real time unless paired with active alerting or enforcement.
Hardening and restricted function
A jump server should be dedicated to its access-brokering function, with unnecessary services, software, and accounts removed, and access restricted to authorized administrators. Reducing the system's function limits its attack surface but requires ongoing patching and configuration management to remain effective.
Relationship to PCI DSS scope
A jump server used to administer the CDE is generally in scope for PCI DSS because it can affect the security of the CDE. Its precise treatment and the applicable requirements depend on the current published version of PCI DSS and on how the environment is architected and validated; readers should confirm against the current standard rather than assuming a fixed requirement number.

Common questions

Answers to the questions practitioners most commonly ask about Jump Server.

Does a jump server by itself bring a system into or out of PCI DSS scope?
No. The label 'jump server' does not determine scope. A jump server that provides administrative access into the cardholder data environment (CDE) is typically in scope as a connected-to or security-impacting system, and any system it can reach must be assessed on the basis of actual connectivity and access, not on the component's name. Scope depends on implementation and how the component is configured, segmented, and validated, which should be confirmed against the current published PCI DSS.
Is a jump server an authentication control that removes the need for multi-factor authentication?
No. A jump server is an access-control and administrative-access chokepoint, not a substitute for authentication controls. Multi-factor authentication is generally expected for administrative and remote access into the CDE, and routing that access through a jump server does not eliminate that expectation. The jump server helps concentrate and monitor access, but it is intended to complement, not replace, authentication requirements defined in the current PCI DSS.
How should administrative access into the CDE be routed through a jump server?
Access is typically directed so that administrators authenticate to the jump server first, and only the jump server is permitted to initiate connections into the CDE. This is intended to reduce the number of paths into the environment. Firewall or network rules should restrict inbound access to the jump server and outbound access from it to defined destinations and ports. Confirm the specific access and authentication requirements against the current published PCI DSS rather than assuming a fixed requirement number.
What logging and monitoring should be applied to a jump server?
Because a jump server concentrates administrative access, session activity, authentication events, and administrative actions should generally be logged and monitored, with logs protected from alteration and retained per policy. Where feasible, session recording or command logging may help support review and investigation. Detailed monitoring may increase log volume and generate false positives, so tuning and review processes should be planned. Align logging and retention practices with the current published PCI DSS.
How should a jump server be hardened and maintained?
A jump server should be treated as a security-impacting system: apply configuration hardening, remove unnecessary services and accounts, restrict which users can reach it, keep it patched, and limit its function to administrative access. Because it is a high-value target for account takeover and lateral movement, access should follow least privilege and be reviewed periodically. Hardening standards and change-control practices should be validated against the current published PCI DSS.
Can one jump server serve both in-scope and out-of-scope environments?
Combining access to in-scope and out-of-scope systems on a single jump server can undermine segmentation and may pull additional systems into scope, since the component provides a path into the CDE. Whether such a design is acceptable depends on how connectivity, access controls, and segmentation are implemented and validated. Segmentation effectiveness is determined by testing, not by intent, and should be confirmed against the current published PCI DSS.

Common misconceptions

Deploying a jump server automatically establishes network segmentation that reduces PCI DSS scope.
A jump server is an access-brokering control, not a segmentation guarantee. Segmentation must be implemented through network controls and verified through testing. A jump server that can reach the CDE is typically in scope itself, and improper configuration can extend rather than reduce scope.
Because administrators connect through a jump server, the systems behind it no longer need their own security controls.
A jump server helps concentrate and monitor access, but target systems still require their own hardening, patching, access control, and monitoring. The jump server addresses the access path; it does not remediate vulnerabilities on the systems it fronts.
A jump server protected by multi-factor authentication prevents unauthorized access to the sensitive environment.
MFA on the jump server is intended to reduce the risk from compromised credentials at the point of access, but it does not eliminate all risk. Session compromise, misconfiguration, insider misuse, or unpatched vulnerabilities can still allow unauthorized activity, so MFA should be one layer within a broader control set.

Best practices

Dedicate the jump server to its access-brokering function, remove unnecessary services, software, and accounts, and apply and maintain hardened configurations with a defined patching cadence.
Require multi-factor authentication for administrative access to the jump server, and restrict access to only the authorized personnel who need it.
Route administrative access to sensitive systems, such as the CDE, exclusively through the jump server and block direct connections from less-trusted networks, then verify these restrictions through testing.
Enable detailed logging of authentication and administrative activity, forward logs to a protected, centralized location, and configure alerting so that suspicious activity can be detected rather than only reviewed after the fact.
Treat the jump server as in scope for PCI DSS when it can affect the CDE, and confirm the applicable controls and requirements against the current published version of the standard rather than a remembered requirement number.
Review access rights, configurations, and logs on a regular schedule, and confirm that segmentation and access-path assumptions still hold after any network or architecture change.