Legacy VPN was designed for a world where the office was the boundary and remote access was the exception. That world no longer exists. ACME explains why VPN has become the attacker’s favourite entry point and how organisations across the GCC are replacing it with Zero Trust Network Access without disrupting their users.
Why VPN Was Never Designed for Modern Work
Virtual Private Network technology was conceived in the 1990s for a specific and limited use case: allowing occasional remote access from a single trusted endpoint to a corporate network. Security assumptions were built around a clear perimeter inside was trusted, outside was not, and VPN was the bridge between them.
Today, that architecture is the default access model for millions of remote workers a role it was never designed to perform. The consequences are well-documented. VPN authenticates users once and grants broad network access, not application-specific access. An attacker who compromises one set of VPN credentials does not gain access to an application they gain access to the network. From there, lateral movement is trivial and the blast radius is limited only by what the network contains, which is typically everything.
What ZTNA Does Differently
Zero Trust Network Access operates on a fundamentally different set of principles. Rather than authenticating a user to a network, ZTNA authenticates and authorises every session for every application, regardless of where the user is connecting from. The key dimensions:
- Identity-aware: The system knows who you are verified through MFA and identity provider integration, not just a username and password
- Device-aware: The system knows what device you are using whether it is compliant with policy, patched, and managed
- Application-specific: Access is granted to specific applications you are authorised to use, not to the network that hosts them
- Session-authenticated: Every session is independently authenticated and authorised, regardless of network location there is no “inside the perimeter” to exploit
The Security Case VPN Is the Attacker’s Favourite Entry Point
The 2024 Verizon Data Breach Investigations Report documented a 312% year-on-year increase in VPN credential stuffing attacks. This is not a coincidence it is the logical outcome of VPN’s architecture. Attackers know that compromising VPN credentials provides broad network access, making it one of the highest-value targets in the enterprise attack surface.
Once inside a VPN, lateral movement is trivial. Attackers can traverse the network, discover assets, and establish persistence with minimal friction. This is the mechanism behind the majority of ransomware deployments ACME’s incident response team has investigated initial access via VPN, lateral movement across the network, and eventual deployment of the payload at scale.
ZTNA eliminates lateral movement by design. There is no network to move through only applications. An attacker who somehow compromises a user session can access only the applications that user is authorised to use, and only for the duration of that authenticated session. The blast radius shrinks from “the entire network” to “one application, one session.”
The User Experience Case
One of the most important properties of ZTNA from a deployment perspective is that users experience it as a transparent improvement. In contrast to VPN which requires a client to be connected and disconnected, introduces tunnel latency, and fails in unpredictable ways ZTNA is designed to be invisible. Applications simply work, at full speed, with no client to manage.
Device compliance checks happen in the background. Conditional access is enforced silently. If a device falls out of policy, access to the affected application is denied but nothing else is disrupted, and the user receives a clear message explaining why. This is security that does not create friction, which is the security that actually gets used.
How ACME Migrates Clients from VPN to ZTNA
ACME’s VPN-to-ZTNA migration methodology is phased to minimise disruption and validate at each stage:
- Phase 1 (weeks 1–4): ZTNA deployed in shadow mode alongside existing VPN. All traffic flows through VPN; ZTNA logs access patterns and validates policy configuration without affecting users
- Phase 2 (weeks 5–10): Application-by-application migration. Each application is cut over to ZTNA in turn, with VPN remaining available as fallback during the transition window
- Phase 3 (weeks 11–14): VPN decommissioned for all successfully migrated applications. Legacy applications assessed for ZTNA compatibility
- Phase 4: Remaining legacy applications remediated or wrapped for ZTNA access. Full VPN decommission completed
“VPN gives users access to the network. ZTNA gives users access to the applications they need and nothing else. That is not a security downgrade it is a fundamentally different and better security model.”
ACME Security Practice Lead
ACME ZTNA Migration Assessment ACME will map your current VPN dependencies, identify the migration path for each application, and design the transition architecture. Includes a risk-ranked view of your current VPN attack surface and the business case for ZTNA migration. Request the assessment →
