Who should own the decision to retire broad VPN access?

Why This Matters for Security Teams

Retiring broad VPN access is a governance decision because VPN is not just a connectivity tool. It is a trust boundary that often grants far more reach than a user or device should have. When identity, network, and operations teams treat it as a routine infrastructure change, they miss the real question: who is allowed to reach what, under what context, and for how long?

That matters because broad remote access amplifies the impact of stolen credentials, weak device posture, and lateral movement. NHIMG research shows that 97% of NHIs carry excessive privileges, and the same over-permissioned mindset often exists in remote access design as well. The pattern is visible in the Ultimate Guide to NHIs and reinforced by real-world incidents such as the SonicWall VPN Mass Breach via Stolen Credentials, where broad access turned a credential event into a wider compromise. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls points toward least privilege, strong verification, and continuous control. In practice, many security teams discover VPN overreach only after an attacker has already used it to move deeper into the environment, rather than through intentional access design.

How It Works in Practice

The decision to retire broad VPN access should be owned jointly by identity, infrastructure, and security leadership, with clear executive sponsorship. Identity defines who should access which resources. Infrastructure defines how that access is delivered and segmented. Security defines the acceptable risk, the logging standard, and the control objectives. No single team can safely own the full decision because VPN replacement affects authentication, device trust, network routing, and incident response.

Practically, the change usually starts by replacing network-wide trust with application-level or workload-level access. That means mapping remote users to specific resources, then enforcing step-up authentication, device posture checks, and time-bound access where needed. For privileged workflows, JIT access and PAM should be used to shrink standing access. For service-to-service and agent-driven access, the identity primitive should be the workload itself, not the network location. This is where current guidance from the Ultimate Guide to NHIs — Key Challenges and Risks becomes especially relevant, because long-lived trust relationships and broad reach are the same structural weakness whether the actor is human or non-human.

• Define the business processes that still need remote access, rather than preserving the VPN by default.
• Move from network-based trust to identity-based access decisions at request time.
• Use short-lived credentials, device checks, and continuous policy evaluation for sensitive systems.
• Retain VPN only where legacy dependencies make removal temporarily impractical, then reduce scope aggressively.

This model works best when access can be decomposed into discrete applications and approved workflows; it tends to break down in flat networks with brittle legacy systems that still assume any authenticated session can reach almost anything.

Common Variations and Edge Cases

Tighter remote access often increases operational overhead, requiring organisations to balance reduced attack surface against user friction, legacy compatibility, and support maturity. That tradeoff is real, and best practice is still evolving for environments with highly dynamic or outsourced access patterns.

Some teams can retire broad VPN access quickly because they already have strong app segmentation, modern SSO, and device posture enforcement. Others must keep a narrow VPN path for administrative break-glass access, third-party maintenance, or legacy systems that cannot yet support zero trust patterns. In those cases, the safer approach is to restrict the VPN to a small set of routes and high-assurance groups, then monitor it as a temporary exception rather than a standard access method. The relevant lesson from the 52 NHI Breaches Analysis is that broad, persistent access paths rarely fail in a neat, isolated way; they become part of a chain that attackers can reuse, extend, or automate.

Where remote admins, contractors, or automation platforms are involved, ownership should include the teams responsible for those identities too. Otherwise the organisation may remove the VPN but leave equivalent risk in static tokens, shared accounts, or unmanaged remote tooling. The control objective is not “no VPN” in the abstract. It is provable reduction of standing access, enforced by identity-aware policy and reviewed as part of access governance.

Related resources from NHI Mgmt Group

• Who should own the decision to move from VPN-based access to identity-based access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?