Why do over-provisioned VPNs and persistent privileges keep defeating zero trust?

Why This Matters for Security Teams

Over-provisioned VPN access and persistent privileges undermine zero trust because they keep trust alive after the first authentication event. NIST’s NIST SP 800-207 Zero Trust Architecture treats trust as something that must be continuously evaluated, not inherited from network location or a one-time login. When VPNs hand out broad network reach, the control plane becomes flatter than the risk model.

This is especially dangerous for non-human identities, where service accounts, API keys, and automation tokens often outlive the task they were created for. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x, and that 97% of NHIs carry excessive privileges. That combination turns a single compromised credential into a high-speed path for lateral movement, privilege escalation, and data access. In practice, many security teams discover the failure only after a VPN foothold or stale credential has already been used to move beyond the initial blast radius.

How It Works in Practice

Zero trust works best when access is narrow, short-lived, and evaluated at request time. A persistent VPN session does the opposite: it creates an always-on network channel that can implicitly authorize far more than the original intent. For humans, that often means broad internal reach. For agents and automation, it can mean every downstream service reachable through the tunnel unless additional controls intervene.

Current guidance suggests replacing static trust with layered controls that reduce standing reach:

• Use identity-aware access instead of network-only access, so policy follows the user, workload, or agent.
• Issue just-in-time access and revoke it automatically when the task ends.
• Prefer short-lived secrets and workload identities over long-lived credentials that remain valid after need has passed.
• Evaluate policy continuously with context such as device posture, request purpose, resource sensitivity, and anomaly signals.

For workload-heavy environments, the same logic applies to NHI governance. The Guide to SPIFFE and SPIRE is useful here because it frames identity as cryptographic proof of what a workload is, not just what network it can reach. That aligns with the OWASP view in the OWASP Non-Human Identity Top 10, where excessive privilege and weak secret hygiene are recurring failure modes. The practical takeaway is that VPNs should not be treated as a substitute for per-request authorization, and persistent privileges should be replaced with scoped, revocable entitlements tied to actual task context. These controls tend to break down when legacy flat networks and shared service accounts force broad connectivity to keep batch jobs and integrations running.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance security gains against application compatibility and administrative load. That tradeoff is real in environments with legacy systems, vendor-managed services, or brittle automation that depends on long-lived connections. Best practice is evolving, and there is no universal standard for how quickly every estate can move off VPN-heavy workflows.

Edge cases usually appear when identity and routing are conflated. A VPN may still be needed for specific administration paths, but it should not become the default trust layer for production access. Likewise, some teams keep persistent privilege for emergency break-glass use, but that exception should be tightly monitored, time-bound, and separately governed. The strongest pattern is to pair zero trust with lifecycle discipline from NHI Lifecycle Management Guide, so access is granted, rotated, and revoked as part of an explicit process rather than left open-ended. For control design, the Top 10 NHI Issues also highlights how excess privilege and stale secrets compound each other in real deployments. The main exception is emergency response, where temporary broad access may be justified, but only with strict logging, approval, and automatic expiry.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?
• What is the difference between zero trust for users and zero trust for NHIs?