By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: AppgatePublished September 24, 2025

TL;DR: Legacy VPNs were built for a different access model, and the SonicWall case shows how patch dependency, end-of-life exposure, and broad network reach create avoidable risk in hybrid environments, according to Appgate. The practical shift is toward identity-based, least-privilege access that reduces lateral movement and removes dependence on constant firefighting.


At a glance

What this is: This is an analysis of why traditional VPNs no longer fit hybrid access patterns, with SonicWall’s VPN exposure used to illustrate patch debt, end-of-life risk, and lateral movement concerns.

Why it matters: It matters because IAM and PAM teams increasingly need access models that limit network reach, reduce standing exposure, and align remote access with Zero Trust principles rather than legacy perimeter assumptions.

👉 Read Appgate's analysis of VPN risk, patch debt, and Zero Trust access


Context

Traditional VPNs extend network connectivity, but they do not natively solve the governance problem of who should reach what, when, and under what conditions. In hybrid and multi-cloud environments, that mismatch turns broad tunnel access into an identity and access risk rather than a simple connectivity choice.

The SonicWall example reflects a wider pattern in remote access security: organisations inherit patch cycles, end-of-life constraints, and overly broad reach from tools designed for a different era. Where remote access intersects with identity, the core question becomes how to replace implicit network trust with policy-based access control.


Key questions

Q: What breaks when a VPN is used as the main remote access control in hybrid environments?

A: The main failure is that a VPN authenticates the user and then grants broad network reach, which makes lateral movement much easier than application-scoped access would. In hybrid environments, that means the control protects the entry point but not the post-login attack surface. Security teams should judge remote access by how little it exposes after login, not by whether the tunnel works.

Q: Why do legacy VPNs increase the risk of lateral movement after a successful login?

A: Legacy VPNs often place an authenticated user inside a trusted network zone, where internal segmentation is weaker than the access decision at the edge. Once inside, an attacker can probe multiple systems without repeated authorization checks. That turns a single credential compromise into a much larger security event, especially where third-party or contractor access is involved.

Q: How do security teams know whether a remote access programme is actually reducing exposure?

A: A remote access programme is working when each session has a limited, measurable reach and the organisation can show that users only see the applications they need. Good signals include fewer reachable assets per session, shorter privilege duration, and less dependence on emergency patching of boundary appliances. If the network still behaves like a flat zone, exposure remains too high.

Q: Who is accountable when legacy remote access infrastructure stays in production after support ends?

A: Accountability sits with the teams that own access governance, infrastructure lifecycle, and risk acceptance together. Unsupported remote access systems are not just technical debt, they are formal risk decisions. Organisations should require named owners, retirement dates, and exception approvals so that end-of-life infrastructure cannot persist by default.


Technical breakdown

Why legacy VPNs create broad network access risk

Traditional VPNs were built to authenticate a user and then place that user inside the network, which is very different from authorising access to a single application or resource. That model works poorly when workloads, third parties, and cloud services all sit behind different trust boundaries. Once the tunnel is established, the user often inherits far more reach than the task requires. From an identity perspective, the problem is not authentication alone. It is the absence of continuous, resource-level authorisation after login.

Practical implication: replace network-wide remote access with resource-scoped access policies that enforce least privilege at connection time.

How patch dependency turns VPN security into an operational race

VPN appliances often depend on rapid patching to stay secure, but that creates a structural lag between vulnerability disclosure, testing, rollout, and full remediation. During that window, exposed systems become attractive targets because they sit on the access path into the enterprise. This is a governance problem as much as a vulnerability problem, because the organisation is forced to rely on patch velocity as the primary control. In practice, any delay expands the attack window for credentials, session tokens, and exposed edge services.

Practical implication: treat patching as necessary but insufficient, and reduce reliance on internet-facing remote access gateways where possible.

Why zero trust access changes the identity control model

Zero Trust shifts the decision from 'is the user on the network' to 'is this specific request authorised right now'. That means identity, device posture, context, and policy become the control points, not the tunnel itself. For IAM and PAM teams, this matters because it reduces standing exposure and limits the blast radius of compromised credentials. The operational payoff is narrower access, smaller discovery surfaces, and less dependence on legacy perimeter infrastructure that was never designed for modern third-party and hybrid access.

Practical implication: align remote access redesign with Zero Trust controls that evaluate identity, context, and privilege before granting reach.


Threat narrative

Attacker objective: The attacker objective is to use a compromised remote access path to reach internal resources that should never have been broadly exposed in the first place.

  1. Entry occurs through exposed or vulnerable remote access infrastructure that remains internet reachable while patching or decommissioning lags.
  2. Escalation follows when the VPN grants broad internal reach, allowing an attacker to move beyond the initial access point with minimal friction.
  3. Impact emerges as lateral movement becomes easier and the organisation absorbs avoidable exposure while legacy support windows close.

NHI Mgmt Group analysis

Legacy VPNs create an access governance problem, not just a network design problem. The article’s core lesson is that tunnel-based access still assumes trust after authentication, which no longer holds in hybrid environments. Once a user or third party is inside the network, the model provides too much lateral reach for modern risk tolerance. Practitioners should treat remote access as an authorisation problem governed by identity policy, not as a connectivity layer issue.

Patch dependency is a control weakness when it becomes the primary defence. If security depends on racing disclosure notices with redeployments, the organisation has accepted an attack window by design. That is especially problematic for remote access gateways that sit at the boundary of identity, perimeter, and privileged access. The stronger approach is to reduce the number of systems that must be trusted and patched on a constant emergency basis.

Zero Trust is increasingly the correct operating model for remote access, but only when paired with tight privilege boundaries. NIST-based Zero Trust thinking aligns well here because it replaces implicit trust with per-request decisioning. For identity teams, the key issue is not simply adopting the label, but ensuring the access policy actually limits what a session can do once granted. The practical conclusion is to shrink standing access rather than just modernise the front door.

End-of-life risk exposes a wider lifecycle failure in security infrastructure. Legacy access systems are often kept alive long after their support assumptions have decayed, which turns retirement dates into risk events. That is a governance failure, not a procurement one. Security programmes should therefore link technology lifecycle management to access risk reviews so that unsupported remote access paths never become the default fallback.

Network reach inflation: broad access paths inflate the blast radius of a single login, which is exactly why remote access controls must be measured by how little they expose, not how easily they connect. The organisation that can authenticate but cannot constrain post-login reach has not solved access governance. The practitioner takeaway is to measure and reduce reachable assets per session.

What this signals

Network reach inflation is the governing idea here: the more internal systems a remote session can touch, the larger the blast radius of a single compromise. That is why programmes moving toward Zero Trust should measure reachable assets per session as seriously as they measure login success. For identity teams, policy quality is visible in how small the post-authentication attack surface becomes.

Remote access modernisation also changes how security leaders should think about lifecycle management. A gateway that is approaching end of support is not merely a patching task, it is a decision point for access architecture, ownership, and residual risk. Where identity intersects with remote access, the right question is whether a session is narrowly authorised enough to survive credential compromise.

The broader signal for practitioners is that VPN replacement is not a product refresh, it is a governance redesign. Teams should align IAM, PAM, and network security around per-request authorisation, device context, and decommissioning of broad trust zones. That shift makes remote access less dependent on emergency operations and more aligned with policy-driven control.


For practitioners

  • Inventory all legacy VPN exposure points Map every internet-facing remote access gateway, its support status, patch history, and the internal resources reachable after authentication. Prioritise systems that still provide broad network reach rather than application-scoped access.
  • Tie remote access retirement to lifecycle deadlines Build a formal replacement plan for end-of-life VPN infrastructure before support expires, including migration milestones, fallback controls, and owner assignments for each environment.
  • Reduce lateral movement through resource-scoped policies Move remote users and third parties to policies that authorize access to specific applications or services instead of full network segments. Use identity context and device posture to decide each session.
  • Measure blast radius per session Test how many internal systems a valid remote session can reach, then use that number as a governance metric for remote access redesign. A smaller reachable set is a stronger control outcome than faster login alone.

Key takeaways

  • Traditional VPNs create broad internal reach after login, which makes them a poor fit for hybrid and third-party access models.
  • The SonicWall example shows how patch dependency and end-of-life exposure can turn boundary infrastructure into a persistent risk window.
  • Zero Trust access reduces exposure when it limits what a session can reach, not just when it changes the login flow.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Remote access authorisation and least privilege are central to this VPN critique.
NIST Zero Trust (SP 800-207)The article argues for Zero Trust remote access instead of perimeter trust.
NIST SP 800-53 Rev 5AC-6Least privilege is the control principle that counters broad VPN reach.
MITRE ATT&CKTA0008 , Lateral Movement; TA0006 , Credential AccessBroad VPN access supports lateral movement once credentials are compromised.
CIS Controls v8CIS-6 , Access Control ManagementAccess control management is directly implicated by broad remote connectivity.

Use Zero Trust architecture to evaluate identity, context, and device before granting application reach.


Key terms

  • Zero Trust Network Access: Zero Trust Network Access is a remote access model that authorises users to specific resources instead of placing them broadly on the network. It combines identity, device, and policy checks so each request is evaluated before access is granted, reducing lateral movement and excessive trust.
  • Network Reach: Network reach is the amount of internal infrastructure a session can contact after authentication. In security governance, it is a practical measure of blast radius, because wider reach gives attackers more options if a credential or endpoint is compromised.
  • End-of-Life Risk: End-of-life risk is the exposure created when a system is no longer supported by the vendor but remains in production. It often forces organisations into fragile maintenance patterns, delayed patching, and exception-based risk acceptance that weaken overall security posture.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

  • Specific arguments for replacing broad tunnel access with identity-based access controls in hybrid environments
  • Discussion of the SonicWall patching and end-of-life lessons that shape the broader remote access risk story
  • Explanation of how Zero Trust changes the access model from network entry to resource authorisation
  • Operational framing for why modernization is about resilience rather than product substitution

👉 Appgate's full article expands on the SonicWall example, remote access lifecycle risk, and the case for identity-based access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners building tighter access control models. It is designed for security teams that need to connect identity decisions to real operational risk.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org