VPNs Are Dead: The Engineering Case for Identity-Aware Proxies (Zero Trust)

The perimeter that no longer exists

The Verizon 2024 Data Breach Investigations Report attributes over 80% of web application breaches to credential theft or abuse. The attackers did not tunnel through firewalls. They simply logged in. Yet most enterprise security budgets still allocate the majority of their spend to a technology built for a world where every employee worked inside a physical office: the Virtual Private Network.

For twenty years, corporate cybersecurity relied on a medieval concept, the castle and moat. Firewalls and VPNs formed the moat. If an employee successfully authenticated at the gateway, they were implicitly trusted with broad access to the entire internal network. This architecture was designed when the “perimeter” was a real, physical boundary: the office building’s ethernet backbone. Every server, database, and internal tool lived inside that perimeter, and the VPN was just a secure tunnel back to it for the occasional remote worker.

That perimeter no longer exists. Employees use personal laptops on airport Wi-Fi. Critical SaaS tools run on third-party infrastructure across AWS, Azure, and GCP. Internal APIs are distributed across containers that spin up and down every few minutes. When a VPN is breached, through a stolen password, a compromised endpoint, or a zero-day exploit in the VPN concentrator itself, the attacker gains lateral movement across everything. They can quietly enumerate internal services, exfiltrate databases, and deploy ransomware, all without triggering a single alert, because the network has already decided to trust them.

The Zero Trust paradigm shift

The architectural response is codified in the NIST SP 800-207 Zero Trust Architecture standard. Zero Trust mandates a fundamental inversion: no user, device, or network segment is trusted by default. Trust is never granted based on network location. Instead, trust is continuously evaluated per request based on dynamic risk signals.

Instead of authenticating a user once at a VPN gateway and granting them a network-wide session, Zero Trust authenticates and authorizes every single HTTP request based on a matrix of real-time signals: Who is the user? Is their device managed by the company’s MDM solution? Is the operating system fully patched? Is the browser up to date? Are they logging in from a geographically impossible location (e.g., London and Shanghai within the same hour)? Did they pass a hardware-backed MFA challenge via FIDO2/WebAuthn, or are they still using SMS codes that can be SIM-swapped?

The conceptual difference is profound. A VPN says: “You proved your identity once, so here’s the entire network.” Zero Trust says: “You must prove your identity continuously, and even then, you only get access to the specific resource you’re requesting right now.”

Identity-Aware Proxies in practice

The concrete implementation of Zero Trust for web applications relies on the Identity-Aware Proxy (IAP). Originally deployed at scale by Google’s BeyondCorp initiative, the IAP eliminates the need for desktop VPN clients entirely.

When an engineer tries to access an internal service (a staging environment, a Grafana dashboard, a Jenkins CI server) they navigate to a standard HTTPS URL in their browser. They do not install a VPN client. They do not configure split tunneling. The IAP sits at the edge of the network and intercepts the HTTP request before it reaches the target service. It interfaces with the corporate SSO provider (Okta, Azure AD, Google Workspace) to verify the user’s identity, evaluates the posture of the endpoint device, checks the request against a granular access policy, and only then proxies the connection, strictly to that single application.

# Conceptual Zero Trust IAP policy (e.g., Cloudflare Access, Google IAP)
routes:
  - path: /internal-dashboard
    target_service: internal-dashboard-v1
    access_policy:
      require_mfa: true
      require_managed_device: true
      allowed_groups: ["engineering", "devops"]
      deny_if:
        risk_score: "HIGH"
        geo_country_not_in: ["PT", "GB", "US"]

  - path: /admin-panel
    target_service: admin-panel-v2
    access_policy:
      require_mfa: true
      require_hardware_key: true  # FIDO2 only, no SMS fallback
      allowed_groups: ["platform-admins"]
      session_duration: "1h"      # Re-authenticate every hour

Services like Cloudflare Access and Google’s Cloud IAP have made this pattern accessible to organizations far smaller than Google. A 20-person startup can deploy an IAP in front of their staging server in under an hour, immediately eliminating the need for a VPN while gaining granular, auditable access control that the VPN never provided.

The VPN is not dead everywhere

It is important to not overcorrect. VPNs are still the correct solution for specific use cases. If an application requires raw TCP or UDP connectivity (not HTTP), an IAP cannot proxy it. Legacy on-premise systems that cannot be exposed via HTTPS still need a network-level tunnel. For these cases, modern VPN protocols like WireGuard offer dramatically better performance than legacy IPsec or OpenVPN, WireGuard’s kernel-mode implementation typically achieves 3–5x higher throughput with significantly lower CPU overhead and a codebase of roughly 4,000 lines versus OpenVPN’s 100,000+.

The architectural mistake is not using a VPN (it is using a VPN as the sole access control mechanism for the entire organization. The VPN should be a narrow, tightly scoped tunnel for the small number of legacy services that cannot be fronted by an IAP. Everything else) every internal web dashboard, every API, every CI/CD tool, should sit behind an identity-aware proxy.

Security as an enabler of velocity

VPNs cause immense friction. They require desktop client software, consume high CPU and memory resources on the employee’s machine, constantly drop connections during network transitions (Wi-Fi to mobile), and generate a continuous stream of IT support tickets. According to OWASP’s guidelines on access control, the principle of least privilege should be enforced at the application layer, not the network layer.

By migrating to an IAP and a Zero Trust architecture, enterprises achieve two seemingly contradictory goals simultaneously: they drastically improve their security posture by eliminating lateral network movement, and they improve developer velocity by making internal platform access as seamless as logging into a public website. The security team gains per-request audit logs. The engineering team loses the VPN client. Both sides win.

The transition is not a weekend project. It requires a full inventory of internal services, a mature SSO/IdP deployment, and a device management strategy (the type of infrastructure migration x078 architects for B2B environments. But the alternative) continuing to trust a 25-year-old perimeter model in a world where the perimeter is a fiction, is an invitation to the next breach report headline.