Should organisations replace VPNs before fixing privileged access governance?

Why This Matters for Security Teams

VPN replacement is often framed as a network modernization project, but the real risk sits in who can do what once they are connected. If privileged access is still granted broadly, logged inconsistently, or left active after role changes, a new access path only moves the problem. The operational question is whether access is brokered, time-bound, and removed with the same discipline across human users and NHIs.

That is why NHI governance and privileged access governance need to be aligned before any perimeter redesign. NHIs frequently outlive the accounts that created them, and they are rarely covered by the same review cadence as human administrators. NHI Management Group’s Ultimate Guide to NHIs emphasizes lifecycle control because standing access, not connectivity alone, is where most exposure accumulates. The same pattern shows up in the OWASP Non-Human Identity Top 10, where over-privilege and weak lifecycle handling remain recurring failure modes.

For context, Astrix Security & CSA report that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, ahead of inadequate monitoring and over-privileged accounts at 37% each. In practice, many security teams discover that “VPN risk” was only the visible symptom after access sprawl has already taken root.

How It Works in Practice

Start by mapping privileged access as a control plane, not a network product. That means identifying where elevation is requested, how approval is granted, which secrets or tokens are used, how sessions are recorded, and what triggers revocation. The useful sequence is usually: classify privileged workflows, reduce standing privilege, introduce just-in-time elevation, and only then decide whether ZTNA replaces some VPN use cases.

For NHIs, the same logic applies with even less tolerance for static access. Service accounts, API keys, and automation tokens should be treated as credentials with explicit owners, scoped permissions, and expiry. The Ultimate Guide to NHIs and Top 10 NHI Issues both reinforce that unmanaged lifecycle and over-scoped access are what turn routine admin paths into persistent blast radius.

• Use PAM to broker privileged sessions instead of embedding long-lived admin credentials in endpoints or pipelines.
• Apply JIT access where possible so elevation exists only for the task window, then expires automatically.
• Log both human and NHI access events with the same minimum fields: actor, target, reason, time, and revocation.
• Review offboarding and token revocation together so personnel changes do not leave orphaned access behind.
• Use ZTNA where it reduces network exposure, but do not confuse transport change with privilege control.

The practical standard is to evaluate access at the moment of use, then remove it as soon as the task is complete. These controls tend to break down in environments with legacy directory sprawl, hard-coded service credentials, or automation that was never designed to support short-lived tokens.

Common Variations and Edge Cases

Tighter privilege controls often increase operational friction, so organisations must balance faster access for responders and developers against lower standing risk. Current guidance suggests that this tradeoff is usually worth making, but it is not universal and it depends on how mature the access stack already is.

Some environments can replace large parts of VPN dependency quickly, especially cloud-first estates with modern SSO, device posture checks, and strong session brokerage. Others cannot, particularly where industrial systems, contractor access, or third-party admin workflows still depend on legacy network reachability. In those cases, VPN retirement should be phased while privileged access governance is improved in parallel. The NIST Cybersecurity Framework 2.0 supports this sequencing by anchoring protection and access decisions to asset and risk management rather than to a single transport layer.

There is also no universal standard for how much network access is “enough” once ZTNA is introduced. Best practice is evolving toward least privilege, continuous verification, and per-request authorisation, but the implementation details vary by identity system, PAM stack, and NHI inventory quality. Organisations that delay privileged access cleanup until after a VPN migration usually end up modernising the tunnel while preserving the same old access sprawl.

Related resources from NHI Mgmt Group

• How do organisations know if privileged access controls are working?
• What do security teams get wrong about privileged access governance?
• What is the difference between role-based access and API key governance for NHI security?
• Should organisations prioritise external exposure or internal credential governance first?