They often assume any added access layer is enough, even when it is hard to use and poorly maintained. When legitimate users find the control painful, they route around it, so the organisation ends up with weaker security and less auditability than it expected.
Why This Matters for Security Teams
VPNs and jump hosts are often treated as a universal answer for privileged web access because they add a visible gate. The problem is that a gate is not the same as strong control. If the workflow is slow, brittle, or hard to audit, users and operators look for shortcuts, and those shortcuts usually bypass the security intent entirely. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
For privileged web access, the real issue is not only who can reach the application, but how access is brokered, logged, and revoked. Static perimeter controls do little when sessions are long-lived, shared, or detached from the actual identity and purpose of the request. OWASP’s OWASP Non-Human Identity Top 10 frames this as an identity and secret hygiene problem, not just a network-routing problem. In practice, many security teams discover the gap only after users have already adopted unofficial remote paths that are harder to monitor than the controls they were meant to replace.
How It Works in Practice
VPNs and jump hosts can still have a place, but they work best as one layer in a broader access model rather than as the main control. For privileged web access, teams should ask whether the user or workload is being granted network reach, application reach, or task-specific authority. The more the answer depends on standing network access, the weaker the posture becomes.
A better pattern is to combine strong authentication with policy decisions that happen at request time. That means short-lived access, explicit approvals for sensitive actions, and detailed logging tied to the actual session. When the target is an administrative console, the access path should ideally be separated from the ability to perform privileged actions, so a connected user does not automatically become a broadly trusted operator.
- Use step-up authentication for sensitive web sessions rather than assuming the VPN boundary is enough.
- Prefer per-session or just-in-time access over long-lived group membership.
- Record which identity, device, and approval context were used for each privileged action.
- Revoke access automatically when the task ends or the approval expires.
This is especially important where privileged web tools are shared across administrators, contractors, or service accounts. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often identity failures become incident pathways, and the lesson translates directly to human admin access: broad reach plus weak session control invites misuse. These controls tend to break down in environments with legacy admin portals and cross-functional operational teams because the access model was never designed for fine-grained, auditable privilege.
Common Variations and Edge Cases
Tighter access controls often increase operational friction, so organisations have to balance convenience against auditability and privilege containment. That tradeoff matters most where administrators are on-call, distributed across time zones, or working in incident-response conditions where speed is essential. In those cases, the best practice is evolving, and there is no universal standard for exactly how much friction is acceptable.
One common mistake is assuming a jump host automatically makes access safer even when the host itself becomes a high-value target, is poorly patched, or is shared across teams. Another is relying on VPN segmentation while leaving the administrative application itself over-permissioned. The control boundary then shifts from identity to connectivity, which is often the wrong boundary for privileged web work.
For environments with contractors, third parties, or automation, teams should distinguish between interactive admin access and machine-driven access. A service account reaching a web API through a VPN is not the same as a person using a jump host, and both need different controls. Current guidance suggests treating both as privileged pathways that require purpose-based authorization, not just generic network admission.
In practice, VPNs and jump hosts fail most often when organisations mistake “reachable from a trusted network” for “safe to perform privileged actions.”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Focuses on excessive access and weak identity boundaries behind privileged access paths. |
| NIST CSF 2.0 | PR.AC-4 | Directly maps to managing privileged access and limiting standing trust. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust requires explicit, session-level authorization instead of implicit VPN trust. |
Replace network trust with least-privilege, task-scoped identity and short-lived access for each admin session.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
