How should security teams reduce VPN risk without disrupting remote work?

Why This Matters for Security Teams

VPNs were built to extend trusted network access, but remote work now depends on contractors, third parties, privileged admins, and cloud services that do not fit a broad tunnel model. The risk is not just “too much access” in the abstract. A single stolen VPN credential can become a pathway to internal systems, lateral movement, and credential harvesting, especially when the environment still assumes that network location implies trust. NIST’s Cybersecurity Framework 2.0 pushes organisations toward outcome-based risk reduction rather than perimeter dependence, which is the right direction for remote access decisions. NHIMG has documented how stolen credentials have enabled broad VPN compromise in the SonicWall VPN Mass Breach via Stolen Credentials, showing how quickly a convenience control can become an enterprise exposure point. In practice, many security teams discover VPN weakness only after a privileged account or third-party session has already been abused, rather than through intentional redesign.

How It Works in Practice

Reducing VPN risk without breaking remote work means shrinking the VPN’s role from “network gateway” to “exception path” for specific use cases. Current guidance suggests moving from broad subnet access to application-scoped access, where each request is evaluated against identity, device posture, session context, and policy at runtime. That approach aligns with Zero Trust thinking and with the control objectives in the Ultimate Guide to NHIs — Why NHI Security Matters Now, because the core issue is not simply where the user connects from, but what the session is allowed to do. A practical sequence looks like this:

• Move high-risk users first, such as contractors, vendors, and privileged admins, to app-specific access instead of full network access.
• Require strong identity verification and device trust before each session, not just at login.
• Use conditional access to check posture, geolocation anomalies, and session risk before granting entry.
• Limit VPN access to legacy systems, administrative break-glass paths, or workflows that cannot yet be decomposed.
• Log every session transition so security operations can see who accessed what, when, and under which policy decision.

For non-human or automated access that still touches remote services, the same pattern applies to workload identity and short-lived credentials rather than shared VPN tunnels. NHIMG’s Top 10 NHI Issues highlights why over-privileged, long-lived access remains a recurring failure mode. These controls tend to break down when remote teams need flat-network reach for fragile legacy applications because the application architecture itself still assumes tunnel-based trust.

Common Variations and Edge Cases

Tighter access controls often increase rollout complexity, requiring organisations to balance reduced blast radius against user friction and application compatibility. The best practice is evolving here, and there is no universal standard for every remote-work environment. A contractor on a managed laptop, a finance user on a home device, and a privileged engineer reaching an OT-adjacent system all need different treatment, even if they all “use VPN” today. Some environments should keep VPN for a limited set of flows, especially when:

• the application cannot be fronted by a modern access proxy or SSO layer,
• device posture cannot be reliably assessed on every endpoint, or
• regulatory or operational constraints require tightly controlled network segmentation.

In those cases, security teams should minimize exposure by scoping routes, shortening sessions, enforcing step-up authentication, and separating privileged access from general remote access. The operational goal is not to eliminate VPN overnight. It is to make VPN a narrowly governed fallback while the default path shifts to identity-aware, application-level access. That distinction matters because broad remote tunnels tend to persist longest in organisations that treat them as a convenience service rather than a controlled security boundary.

Related resources from NHI Mgmt Group

• How should security teams reduce OT remote access risk without blocking maintenance work?
• How should NHS security teams reduce privileged access risk without disrupting clinical operations?
• How should security teams reduce remote-work identity risk for employees using home offices?
• How should security teams reduce identity risk in remote work environments?