VPNs and jump hosts still assume that network placement is a useful proxy for trust, so they preserve broad access paths even when policy should be identity-driven. In mixed estates, that creates exceptions, weak audit trails, and a persistent gap between policy design and real enforcement.
Why VPNs and jump hosts break zero trust assumptions
VPNs and jump hosts are not automatically insecure, but they often preserve an older trust model: connect to the network first, then rely on that placement as a proxy for legitimacy. zero trust works differently. It expects identity, device state, policy, and session context to be evaluated continuously, so any mechanism that opens a broad internal pathway tends to weaken the model it is meant to replace.
That mismatch matters because zero trust is not just about stronger authentication at the edge. It is about narrowing what a successful login can reach, and about enforcing policy at the point of access rather than assuming that internal routing equals trust. A NIST SP 800-207 Zero Trust Architecture framing makes that shift explicit, and NHIMG’s Zero Trust Identity Guide shows how identity-centric policy replaces network placement as the control point.
Why mixed estates make the problem worse
In real environments, VPNs and jump hosts often survive because some applications, vendors, or administration workflows still depend on them. That creates a mixed estate in which a zero trust policy may exist on paper, while older access paths still provide broad reach in practice. The result is usually exception sprawl, uneven enforcement, and a control gap between what security teams believe is allowed and what a user or admin can actually reach.
Jump hosts also concentrate risk. They become shared conduits for privileged activity, which means compromise, weak segmentation, or sloppy session handling can expose far more than the immediate target. NHIMG’s SSH Key and SSH Certificate Management Guide is relevant here because many jump-host designs depend on SSH access, bastion patterns, and key governance, all of which need tight lifecycle control if the hop is to remain defensible.
VPNs create a different but related issue: once the tunnel is up, the network often treats the user as broadly present inside the environment. That broad connectivity makes it harder to express least privilege by application, by workload, or by administrative function. NHIMG’s Remote Access Identity Guide is useful because it treats VPNs as one remote-access pattern among several, not as a default trust boundary.
How to think about the transition away from them
The practical question is not whether every VPN or jump host must disappear immediately. The question is whether each one still adds value that cannot be achieved with narrower, identity-driven access controls. In some cases, the right answer is to keep a tightly bounded exception for legacy administration while moving most user and service access to more granular controls.
When you assess that exception, focus on whether access is still path-based rather than policy-based. If the answer is yes, the environment is still carrying zero trust debt. NHIMG’s Ultimate Guide to NHIs, Standards helps here because it places zero trust alongside identity governance and related controls, which is exactly the direction a mature replacement strategy needs.
The most durable replacement pattern is to move from broad connectivity to authenticated, authorized access to specific resources, with strong logging and short-lived access decisions. For workloads and service-to-service paths, that often means using workload identity rather than network reach alone. NHIMG’s Guide to SPIFFE and SPIRE is a good reference point for that model because it replaces implicit network trust with verifiable workload identity and per-request authentication.
Risk and Threat Considerations
VPNs and jump hosts expand the blast radius of a single compromise because they can turn one authenticated foothold into broad internal reach. They also make abuse harder to distinguish from legitimate administrative activity, especially when the same pathways are reused by many users or teams.
Failure mechanism: A stolen credential, hijacked session, or abused admin channel can inherit the network trust granted by the VPN or bastion and then pivot into systems that were never meant to be broadly reachable.
Impact: The organisation gets weaker containment, poorer attribution, and a larger incident scope, because an attacker or insider can move through a supposedly internal path that the zero trust programme should have narrowed or eliminated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | VPN and jump-host access should be narrowed to only required systems and actions. |
| IA-2 — Identification and Authentication (Organizational Users) | Zero trust depends on strong user authentication before any remote access is granted. | |
| Recommendation — Limit remote and administrative access to the minimum resources and privileges needed. Require strong authentication before granting remote network or admin access. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity Management, Authentication, and Access Control | This question centers on replacing network-based trust with identity-driven access decisions. |
| Recommendation — Enforce identity-based access decisions at the point of request, not by network location. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Remote access paths and privileged hops need tight control and periodic removal of unnecessary access. |
| Recommendation — Review and remove unnecessary VPN and jump-host access paths regularly. | ||
| OWASP ASVS | V8 — Authorization | Broad tunnels and bastions often undermine fine-grained authorization to specific resources. |
| Recommendation — Verify that each protected resource requires explicit authorization beyond network reach. | ||
Practitioner Guidance
What to verify: Check whether the VPN or jump host is granting network reach that exceeds the user’s or admin’s actual job function. If the answer is yes, treat that access path as a control exception, not as a neutral convenience.
Decision rule: If the path is required only for legacy compatibility, bound it tightly, make it temporary, and log it like a privileged exception. If it is being used as the default way to reach critical systems, it is probably masking a policy design problem that should be fixed at the access layer.
Common mistake: Replacing one perimeter with another. A modern zero trust programme should reduce standing reach, not simply move the boundary from the firewall to the VPN concentrator or bastion host.
Practitioner takeaway: The key test is whether access can be expressed as least privilege to a specific resource, session, or action. If VPNs and jump hosts are still carrying broad trust, the programme is preserving the old network model instead of enforcing zero trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org