VPN replacement requires narrower access, not broader tunnels

At a glance

What this is: This is a guide to replacing legacy VPNs with policy-driven access models, with the key finding that VPNs are increasingly too broad, too slow and too hard to manage for hybrid work.

Why it matters: It matters because IAM and security teams need to separate application access from network access, reduce standing network reach and align remote access controls with identity, device posture and resource sensitivity.

Context

Legacy VPNs were built to extend network access, not to govern modern hybrid access patterns. As employees move between office, home and public networks, that broad model creates more operational overhead, more latency and more unintended reach than many organisations can justify.

The governance gap is that access decisions are still too often made at the network boundary rather than at the application or resource boundary. Where identity-aware access is genuinely needed, the control question becomes whether a user should reach a specific resource, not whether they should enter the internal network at all.

Key questions

Q: What breaks when legacy VPNs are used as the default remote access model?

A: Legacy VPNs break down when they are asked to do too much. They combine encryption, routing and access control into one broad control, which creates latency, exception sprawl and unnecessary network reach. The result is a remote access model that is harder to govern and easier to abuse once credentials or endpoints are compromised.

Q: Why do broad VPN sessions increase lateral movement risk?

A: Broad VPN sessions increase risk because authentication often places the user onto a network segment rather than a single resource. If the account or device is compromised, the attacker inherits that reach and can move to systems the user never needed. The problem is entitlement scope, not tunnel encryption.

Q: How do security teams know whether remote admin access is too broad?

A: Look for accounts that can reach servers, stop services, or manage recovery tooling without task-specific approval or expiry. If the same identity can authenticate broadly and make destructive changes, the access model is overextended. Audit RDP entitlements, backup rights, and service-control permissions together, not separately.

Q: When should organisations use zero trust network access instead of a full VPN?

A: Organisations should use zero trust network access when the real need is access to specific private applications, not entry to the internal network. If users mainly need application-level access and off-network policy enforcement, ZTNA fits better than a full VPN. If the goal is only encrypted internet traffic, a separate control is usually more appropriate.

Technical breakdown

Why legacy VPNs create flat-network risk

A traditional VPN authenticates a user and then places the device onto a network segment, which means the user often inherits visibility beyond the one application they actually need. That design was acceptable when remote access was occasional and application estates were simpler. In hybrid environments, however, the same network boundary becomes a lateral movement opportunity if credentials are stolen or the endpoint is compromised. The issue is not just encryption in transit. It is the way the VPN converts identity validation into broad network reach, making segmentation quality and entitlement hygiene part of the attack surface.

Practical implication: reduce network-wide VPN access and replace it with application-scoped controls for remote users.

How backhaul and split tunnelling affect secure access

Full-tunnel VPNs force all traffic, including SaaS and public web traffic, back through a central gateway before it reaches its destination. That adds latency, consumes bandwidth and concentrates load on a device that is not delivering the application itself. Split tunnelling reduces some of that overhead by sending selected traffic directly to the internet, but it also increases policy complexity because teams must decide what should be tunneled, what should bypass the tunnel and how exceptions are governed. The architectural trade-off is between simpler routing and tighter control versus lower latency and less central load.

Practical implication: define which traffic truly needs private transport and avoid routing every session through one gateway.

Why policy-driven access changes the identity control point

Modern access models move the decision from network placement to continuous authorization. Identity, role, device posture, location and resource sensitivity can all be evaluated before access begins and during the session. That matters because a successful login no longer has to imply persistent access to everything behind the gateway. Instead, the control path can revoke or narrow access when the account changes, the device falls out of compliance or the request no longer matches policy. This is where remote access starts to align with zero-trust design rather than perimeter inheritance.

Practical implication: enforce access at issuance and re-check it during the session instead of relying on a single login event.

Threat narrative

Attacker objective: The attacker wants to turn one valid remote access session into broader internal reach and lateral movement opportunities.

1. Entry begins when a remote user authenticates successfully to a legacy VPN and receives broad network access rather than a narrowly scoped application route.
2. Credential abuse or endpoint compromise then lets an attacker inherit the same network reach, using the VPN connection itself as the access path.
3. Escalation occurs through lateral movement across systems that were never intended to be exposed to that user or device.
4. Impact is broader compromise, because the VPN’s network placement turns one trusted login into access to additional internal resources.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

VPN replacement is really an access governance problem, not a transport problem. The article shows that the old model bundles encryption, routing and entitlement into one control, which is why it becomes brittle as remote work and cloud use expand. In practice, the security decision is no longer whether to keep a tunnel, but where identity-aware authorization should begin and end.

Flat-network inheritance is the core governance failure in legacy remote access. Once a user is placed onto a broader network segment, the organisation is relying on segmentation discipline to contain damage after authentication has already succeeded. That is a weaker posture than resource-scoped access, especially when contractors, MSPs and roaming staff all share the same remote access fabric.

Selective tunnelling creates a more honest control split. Private application access, DNS-layer protection and internet transport are different jobs and should not be forced through the same control plane. The more clearly teams separate those jobs, the easier it becomes to govern identity, reduce latency and preserve policy consistency across devices and locations.

Narrower remote access supports zero-trust principles without pretending everything is zero trust. The article aligns with the idea that trust should be repeatedly verified and access should be limited to what the user needs. That is especially important for hybrid environments where one login can otherwise expand into too much implicit reach.

Remote access governance now has to account for off-network enforcement. If users work from home, hotels and public Wi-Fi, the control stack must follow them rather than assume the corporate network is the only place worth protecting. That shifts the practitioner focus toward continuous policy, device context and resource-level authorisation instead of gateway-centric control.

What this signals

VPN replacement is a governance cleanup exercise as much as a technology change. Teams that continue to treat network entry as the primary access decision will keep inheriting flat-network risk, exception sprawl and over-broad trust. The practical direction is to move remote access decisions closer to the resource and the device.

Hybrid work exposes the weakness of monolithic access controls. When users move between offices, homes and public Wi-Fi, a single tunnel is rarely the best answer for every traffic type. The better model is to govern private application access, internet transport and DNS-layer policy separately, then keep the rules consistent across all three.

Remote access policy should be written around resource scope, not around the existence of a VPN. That means reassessing which sessions deserve broad network transit, which need only application-level entry and which should never be allowed to persist after posture changes. The security gain comes from narrower trust boundaries, not from preserving the tunnel by default.

For practitioners

• Define access by use case first Separate private-application access, internet traffic protection and DNS-layer policy enforcement before selecting replacement controls. The wrong buying sequence is to start with the tunnel and then try to make every use case fit it.
• Remove broad network placement from remote sessions Limit remote users to the specific applications or services they need, rather than placing them onto a larger internal network segment. This reduces lateral movement potential when credentials or endpoints are compromised.
• Make device posture part of the access decision Check operating system status, endpoint protection and management state before and during access so that identity alone does not open the session. Re-evaluate access when device compliance changes mid-session.
• Treat split tunnelling as a governed policy Document which traffic must remain encrypted through the access platform and which traffic should go direct to the internet. Use consistent rules rather than one-off exceptions that accumulate across users and tenants.
• Monitor for access that outlives its purpose Use revocation and re-authorisation checks when an account is disabled, a device falls out of compliance or a request no longer matches policy. Standing access is the condition that turns a compromise into a broader breach.

Key takeaways

• Legacy VPNs are increasingly a poor fit for hybrid work because they grant broad network reach where application-scoped access is usually enough.
• The main security issue is not encryption failure but entitlement scope, since a compromised remote session can inherit more access than the user actually needs.
• A modern replacement strategy separates private access, internet traffic protection and continuous policy enforcement so remote access can be governed at the resource level.

Key terms

• Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
• Split Tunnelling: Split tunnelling is a VPN configuration where only selected traffic goes through the corporate tunnel while other traffic uses the user’s local internet connection. That can improve performance, but it also removes consistent monitoring and policy control, which increases exposure to interception, unapproved access, and weaker enforcement of security controls.
• Network Segmentation: Network segmentation divides traffic and resources into controlled zones so access can be restricted between groups, systems, or applications. In remote access design, segmentation limits what a connected user or workload can reach after authentication, which reduces lateral movement and shrinks blast radius.
• Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to connect identity controls to broader access governance and operational risk.