VPN vs ZTNA: Why Zero Trust Network Access Is Replacing VPNs

For decades, the VPN was the gold standard for securing remote access. The model was conceptually simple: encrypt the tunnel, drop the user inside the corporate network, and trust them implicitly once they were in. That model made reasonable sense when corporate perimeters were relatively well-defined, when most employees worked on company-managed hardware, and when the applications they needed lived in on-premises data centers.

None of those assumptions hold anymore. Applications live in SaaS platforms, AWS, and hybrid environments. Employees work from home networks, coffee shops, and personal devices. The "perimeter" has dissolved. And yet many organizations still issue VPN credentials, drop authenticated users onto a flat network, and call it secure. That is an increasingly dangerous approach.

The Fundamental Problem with VPN Architecture

A traditional VPN creates an encrypted tunnel from a client device to a concentrator sitting at the edge of your network. Once the tunnel is established, the client receives an IP address on your internal network and — by default — can reach everything else on that network.

This is the flat-network problem. When a VPN user's device is compromised, or when an attacker steals VPN credentials (trivial without MFA enforcement), they gain access to the same flat network your most sensitive database servers sit on. The VPN itself provides no east-west segmentation. The attacker pivots laterally at will.

The statistics bear this out. The vast majority of ransomware incidents involve an initial foothold through a compromised VPN credential. Attackers don't need to find a zero-day in your application stack; they just need one employee's username and password from a credential dump.

Performance is the other persistent complaint. Traditional VPN architectures route all traffic through a central hub — often a physical appliance or a single cloud region — even when users are accessing SaaS apps like Salesforce or Microsoft 365. Latency compounds when traffic hairpins through headquarters before reaching the internet. Split-tunneling mitigates this but reintroduces security gaps (traffic to the internet bypasses inspection entirely).

MFA enforcement is inconsistent. VPN clients generally support MFA, but enforcement depends entirely on configuration. Many organizations have MFA enabled for some users, bypassed for service accounts, or configured with weaker factors like SMS. ZTNA enforces strong authentication at every session, for every application, by design.

How Zero Trust Network Access Works

ZTNA operates on a fundamentally different model: never trust, always verify. Rather than granting access to a network, ZTNA grants access to specific applications, based on verified identity and device posture, evaluated continuously throughout the session.

The architecture typically looks like this:

1. Identity Verification — Every access request is authenticated against an identity provider (Okta, Azure AD, Google Workspace). There is no anonymous access.
2. Device Posture Check — Before granting access, the ZTNA client checks whether the device meets your security baseline: Is the OS patched? Is endpoint protection running? Is the disk encrypted? Non-compliant devices are denied or quarantined.
3. Application-Level Proxy — Rather than a network-level tunnel, ZTNA creates an application-level connection to a specific resource. The user gets access to your internal CRM. They do not get access to the entire subnet the CRM runs on.
4. Continuous Authorization — Sessions are continuously evaluated. A device that falls out of compliance mid-session can have access revoked without requiring a VPN reconnect cycle.

User Device --> ZTNA Client --> Identity Provider (Okta/Entra)
                                        |
                             Device Posture Assessment
                                        |
                             Policy Engine (Allow/Deny)
                                        |
                         Application Connector (on-prem or cloud)
                                        |
                              Internal Application

The internal application never has a public IP address. External attackers cannot even discover it, let alone connect to it. This approach is sometimes called "application cloaking" or a software-defined perimeter.

ZTNA Vendors and Their Approaches

Cloudflare Access is part of the Cloudflare Zero Trust platform. It integrates tightly with Cloudflare's global network, meaning the latency overhead of the security layer is minimal. Access policies are defined per application and support identity conditions (group membership, authentication method) plus device posture. The WARP client is required for non-web applications.

# Example Cloudflare Access policy (Terraform)
resource "cloudflare_access_application" "internal_dashboard" {
  zone_id          = var.zone_id
  name             = "Internal Dashboard"
  domain           = "dashboard.internal.example.com"
  session_duration = "8h"
}

resource "cloudflare_access_policy" "require_engineering" {
  application_id = cloudflare_access_application.internal_dashboard.id
  zone_id        = var.zone_id
  name           = "Engineering Group Only"
  precedence     = 1
  decision       = "allow"

  include {
    group = [cloudflare_access_group.engineering.id]
  }

  require {
    device_posture = [cloudflare_device_posture_rule.disk_encryption.id]
  }
}

Zscaler Private Access (ZPA) is the enterprise-grade option, deeply integrated into Zscaler's broader security platform (Zscaler Internet Access for web filtering, CASB, DLP). ZPA is the right choice if you need comprehensive security stack integration and are operating at large scale. The licensing cost is significantly higher than Cloudflare.

Tailscale takes a different architectural approach. Rather than a cloud-hosted proxy, Tailscale builds a mesh VPN using WireGuard, with a coordination server handling key exchange and identity. Access control lists define which devices can reach which other devices. Tailscale ACL syntax:

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:production-db:5432"]
    },
    {
      "action": "accept",
      "src": ["tag:ci-runner"],
      "dst": ["tag:staging:*"]
    }
  ],
  "tagOwners": {
    "tag:production-db": ["group:devops"],
    "tag:staging": ["group:devops", "group:engineering"]
  }
}

Tailscale is particularly popular for smaller engineering teams and for machine-to-machine connectivity (CI/CD pipelines, developer access to staging). It requires less infrastructure than a full ZTNA proxy deployment.

Migration Strategy

A ZTNA migration does not need to be a big-bang cutover. The most practical approach is parallel deployment.

Phase 1: Identify your highest-risk VPN use cases. This typically means administrative access — SSH, RDP, database admin tools, Kubernetes API servers. These are the targets attackers prioritize after gaining a VPN foothold. Migrate them to ZTNA first.

Phase 2: Deploy the ZTNA connector alongside existing infrastructure. Install connectors (Cloudflare Tunnel, Zscaler App Connector, or Tailscale) on-premises or in your cloud environment. These establish outbound connections to the ZTNA platform and do not require inbound firewall rules.

Phase 3: Migrate application by application. For each internal application, create a ZTNA access policy and test with a pilot group. Verify MFA enforcement, device posture checks, and logging.

Phase 4: Enforce for all users, then remove VPN for migrated applications. Shrink the VPN's scope progressively. Eventually the VPN may only handle edge cases (legacy protocols, bulk file transfers) or be retired entirely.

What VPN Is Still Good For

ZTNA does not make VPN completely obsolete in every context. Traditional site-to-site VPNs connecting two fixed network locations (office-to-data-center, data-center-to-data-center) are not what ZTNA replaces and continue to work well. IPsec tunnels between AWS VPCs and on-premises networks via AWS Direct Connect or VPN Gateway are an established pattern with no compelling ZTNA substitute.

Legacy applications that speak non-HTTP protocols and require true network-level access present genuine migration challenges. An ancient ERP system that clients connect to over a proprietary TCP port may not proxy cleanly through an application-level ZTNA connector. In those cases, a scoped VPN with tightly restricted firewall rules is still a reasonable interim solution while the application is modernized or replaced.

For organizations with strong network egress controls and mature device management, the VPN tunnel itself may still be the right choice for bulk data transfer workloads, where the overhead of per-application proxies adds complexity without meaningful security benefit.

The practical reality is that most organizations will run both for several years during migration. The goal is to shrink the VPN's footprint and scope progressively — not to eliminate it overnight — while immediately improving the security posture of your highest-risk administrative access paths.