How should security teams replace VPN trust with zero trust access controls?

Why This Matters for Security Teams

VPNs were built to extend network reach, not to prove who or what is requesting access. That model breaks down when users, service accounts, APIs, and autonomous workloads all share the same transport path but need different controls. zero trust shifts the question from “is this on the network?” to “should this specific identity get this specific action right now?” Current guidance in NIST SP 800-207 Zero Trust Architecture and OWASP Non-Human Identity Top 10 both reinforce that access decisions must be contextual, continuous, and narrow.

For security teams, the practical risk is that VPN trust often leaves standing pathways behind the perimeter. Once a device connects, broad reach can persist longer than intended, especially when credentials are reused across tools or sessions. NHIMG research shows why this matters: 97% of NHIs carry excessive privileges, and 90% of IT leaders say proper NHI management is essential for a successful zero-trust implementation, as covered in Ultimate Guide to NHIs. In practice, many security teams discover this trust gap only after lateral movement or credential exposure has already turned a “secure remote access” design into an internal attack path.

How It Works in Practice

Replacing VPN trust starts by moving enforcement from the network edge to the workload, application, and action level. Instead of granting a session broad internal reach, teams should issue access based on identity, device posture, resource sensitivity, and the exact task being attempted. That means combining NIST SP 800-207 Zero Trust Architecture with identity proof, policy evaluation, and session-specific limits. For workload and service-to-service access, many teams are looking to Guide to SPIFFE and SPIRE because workload identity is stronger than network location as an access primitive.

• Require strong identity for every request, not just at login.
• Use RBAC for coarse entitlement, then add context-aware policy for the final decision.
• Issue JIT credentials with short TTLs and revoke them automatically when the task ends.
• Prefer ephemeral secrets, mTLS, or OIDC-backed workload tokens over long-lived shared secrets.
• Log each decision with the policy inputs used, including identity, posture, and resource sensitivity.

For NHI-heavy environments, the access layer should also reflect the reality that secrets sprawl faster than policy. NHIMG notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is why access controls and secret handling must be designed together, not as separate workstreams. The most useful operating model is to pair zero trust with lifecycle discipline from Ultimate Guide to NHIs — Standards and risk context from Ultimate Guide to NHIs — Key Challenges and Risks. These controls tend to break down when legacy applications cannot accept short-lived tokens or when administrators still need persistent break-glass paths for maintenance.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, so organisations must balance reduced trust with release speed, incident response, and application compatibility. Best practice is evolving, and there is no universal standard for every environment yet. Some systems can adopt intent-based authorisation quickly, while others still depend on static ACLs, legacy VPN gateways, or long-running batch jobs that were never designed for short-lived credentials.

The main edge case is operational continuity. High-availability administration, third-party support, and air-gapped segments may still require carefully constrained exceptions, but those exceptions should be time-bound, logged, and approved through PAM rather than left as standing VPN access. For regulated data flows, PCI DSS v4.0 can help teams justify stronger session governance where access to sensitive systems must be tightly limited and reviewed. When the environment includes autonomous software, the risk profile changes again: an agent can chain tools, call APIs repeatedly, and create unexpected privilege paths, so static roles become too blunt for real-time control. Current guidance suggests treating those workloads as dynamic identities with per-task permissions, not as users in disguise. The hardest cases are hybrid estates where VPN, cloud access, and service accounts all coexist, because policy gaps appear exactly where traffic is still treated as a network problem instead of an identity problem.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• How should security teams implement zero trust for privileged access?
• Why do non-human identities complicate zero trust architecture?