The architectural problem with VPNs isn’t that they’re old. It’s that they were never designed for the access challenge enterprises actually face today.
VPNs were built around a simple idea: give remote managed users the experience of being on the corporate network while they were away from the office. In the era when the network was where applications lived and where the majority of the users were located, it made sense. Users needed to reach resources on the network, and VPNs delivered the network.
That idea faces myriad problems today. First, enterprise architectures have changed. Thanks to ongoing digital transformation, most enterprise applications are now in the cloud. And connecting users to a network that doesn’t contain the resources they’re trying to reach can involve routing traffic into the corporate infrastructure, up to the cloud, and back, which adds latency.
Second, VPNs create the kind of broad network exposure that attackers have learned to exploit. The 2026 Verizon Data Breach Investigations Report found that 29% of breaches involved unpatched vulnerability exploitation in edge devices, including VPNs. The 2025 report noted that edge device and VPN exploitation rose roughly 8x, from 3% to 22% of initial-access cases. VPNs aren’t just architecturally mismatched with modern enterprise infrastructure. They’ve become the preferred entry point for attackers who know that broad network access and limited session visibility are a reliable combination for exploitation.
Third, the users that need access to enterprise applications and resources have changed. When VPNs were introduced, the primary audiences were employees that were away from the office for some reason. Today, between hybrid work, BYOD and third parties, the user and device types have changed dramatically. If attackers want to gain access to an enterprise network, it is easier to plant something on an unmanaged device which may not have the latest security controls or updates than it is to go after well-defended managed endpoints.
The organizations that have replaced VPN with application-level Zero Trust access have found what VPN models were never able to deliver:
VPNs were designed to connect users to networks, not to applications. That distinction sounds subtle, but its implications are significant.
When a user connects via VPN, they get access to the network. What they can do on that network is governed by whatever policies exist downstream, including firewall rules, application controls, and identity checks at the application layer. The VPN itself enforces no application-level access policy. It simply places the user on the network and trusts subsequent controls to manage what happens next.
In practice, this means VPN access is broader than it needs to be. A contractor who needs access to a single project management application gets network-level access to everything their permissions allow. The blast radius of a compromised credential or a session hijack extends well beyond the specific resource the user was accessing.
VPN access is broader than it needs to be. A contractor who needs access to a single project management application gets network-level access to everything their permissions allow.
Split tunneling reduces this somewhat by routing only specific traffic through the VPN. But for many enterprise applications, traffic still routes into the network, up to the cloud, and back, adding latency without reducing the fundamental exposure.
VPN visibility problems compound the access problem. Investigations involving VPN-encrypted traffic require time-consuming techniques such as key acquisition, deep packet inspection, network flow analysis, or log reviews to gain visibility into what happened inside a session. By the time a security team understands what occurred, the damage is done. This isn’t a gap that better logging closes. It’s an architectural limitation. VPNs secure the path. They have no visibility into what happens once the user is on it.
Zero Trust as a framework has always included the principle of continuous authorization, including not just verifying who gets access, but continuously verifying what they’re doing once they have it. VPNs, by design, can’t deliver continuous authorization. They deliver initial authentication and then step aside.
VPNs were designed for human users at human pace. The emerging reality of enterprise AI makes the architectural mismatch significantly worse.
AI agents operate at machine speed. Controls designed for human-paced interaction face a different stress test when agents can iterate thousands of times per minute. A compromised agent with VPN access doesn’t move through a network at the speed a human would—it moves at the speed of code. Lateral movement that would take an attacker hours can happen in seconds.
79% of defenders report AI exploitation speed as their top concern, and it’s already showing up in the field. Agents are also designed to follow instructions, including malicious ones injected through a compromised session. The same quality that makes them useful makes them exploitable. Broad network access, combined with machine-speed execution and no session-layer controls, is a risk profile that VPN architecture has no answer for.
Menlo Secure Application Access replaces VPN by operating at the application layer, not the network layer. The difference in how access is granted, governed, and visible is fundamental.
Users access applications through the Menlo Cloud, which renders a hardened, disposable container for each session. The application never sees the user’s device—it sees a controlled request from Menlo’s cloud infrastructure. The underlying server is never exposed. An attacker who compromises a session can’t use it to reach anything beyond the specific application the session was established to access.
This resolves the central architectural problem with VPNs:
The visibility problem has a compliance dimension that VPNs compound. When a security team needs to understand what happened inside a VPN session for an incident investigation, a compliance audit, or a regulatory inquiry, the work required to reconstruct that picture is significant and the result is often incomplete.
Menlo Browsing Forensics delivers a detailed view of every browser session, including user actions, third-party interactions, session telemetry. Access policies don’t just exist—they’re verifiable. When an auditor asks whether controls were working, the answer is a session record, not a network log that requires interpretation.
For organizations operating under regulatory frameworks that require demonstrable access controls, such as financial services, healthcare, or government, this distinction is meaningful. With Browser Forensics, the enterprise can provide recordings of user sessions, including keystrokes that show what the user did, and timelines that show what the user was doing throughout the session, to provide intent.
The population where VPN access creates the most concentrated risk is third parties. Contractors, business partners, and M&A counterparties need access to specific applications rather than broad access to the corporate network.
The supply chain dimension makes this more than an individual risk. When a business partner has VPN access to your internal applications, their security posture—and their vendors’ security postures—become your exposure. A single partner compromise doesn’t affect one organization. It can cascade across hundreds simultaneously.
Application-level Zero Trust changes this calculus. Third-party access is narrow, specific, and scoped to the applications the relationship requires. It’s easy to revoke the moment the relationship changes—without network infrastructure changes, without credential revocation workflows, without the residual exposure that VPN access leaves behind when an engagement ends.
Replacing VPNs doesn’t require replacing your entire security stack. Menlo Secure Application Access integrates with identity providers, SIEM tools, and existing security infrastructure, which effectively adds application-level control and session visibility to the access model you already have.
The operational changes are significant, but they move in the right direction:
VPNs solved a real problem for a world that has substantially changed. The question isn’t whether they were the right tool—they were. The question is whether the architectural assumption that connecting users to the network is the same as connecting them to their applications still holds.
For most enterprises, it doesn’t. Applications are in the cloud. Users are everywhere. Attackers have identified VPN infrastructure as a reliable entry point. And AI agents are about to place machine-speed workloads on network-access infrastructure designed for humans.
Zero Trust that operates at the application layer rather than the network layer is the architecture that matches the access challenge enterprises actually face. Instead of broader access to everything, followed by downstream controls, enterprises need precise access to specific applications, governed at the session layer, visible to your security team from the moment a connection is established to the moment it ends.
That’s what replacing VPN means. And it’s a meaningfully different security posture than the one you have today.
------------------------------
About the Author
Rsolyn Rissler is a Senior Product Marketing Manager at Menlo Security. Roz brings decades of PMM experience focused across Menlo’s Browser Security Platform.
------------------------------
Schedule a demo to see how the Menlo Browser Security Platform compares to your current VDI deployment — or explore the VPN Reduction solution page.
Menlo Security
