CyphrQ
Menu

ZTNA vs VPN: Why Remote Access Gateways Get Breached

Why VPN appliances are a favourite way in, what zero trust network access changes, the order to migrate in, and what ZTNA does not fix.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

A VPN puts a remote user on your network and then largely trusts them. Zero trust network access (ZTNA) connects a user to one application at a time, after checking who they are and what device they are on. That matters because VPN appliances sit on the internet, hold the keys to the internal network, and appear again and again in government advisories about exploited flaws.

Is ZTNA more secure than a VPN? In my view, yes on one point that matters most in a breach: it limits what a stolen login or a compromised access point can reach. It does not remove identity risk, because a valid stolen session still gets in.

ZTNA is not a product you plug in to make the risk go away. It is a way of designing access. This post explains why the VPN became such a common entry point, what changes when you move to ZTNA, which systems to move first, and the gaps ZTNA leaves open.

Why are VPN appliances such a common way into a network?

Three things make a VPN gateway an attractive target.

  1. It is reachable from anywhere. It has to be, because staff connect from home, hotels and airports.
  2. It is a trust boundary. Once a session is up, the user is often "inside", with network routes to far more than they need.
  3. It is a box few people watch. Many appliances run a vendor operating system that often cannot run standard endpoint agents, so the evidence of a break-in can sit on a device the security team rarely inspects.

The public record shows the pattern.

In practice: Ivanti Connect Secure, January 2024. On 19 January 2024 CISA issued Emergency Directive 24-01 to US federal civilian agencies. It covered two flaws in Ivanti's VPN and network access products: CVE-2023-46805, an authentication bypass, and CVE-2024-21887, a command injection flaw. Chained together, they allow arbitrary command execution. Twelve days later a supplemental direction told agencies to disconnect every instance of the affected products from agency networks by 11:59pm on Friday 2 February 2024. Agencies could only bring a device back after a factory reset and a rebuild.

In practice: the most exploited flaws of 2023. In November 2024 CISA, the FBI, the NSA and cyber agencies from Australia, Canada, New Zealand and the UK published the 2023 Top Routinely Exploited Vulnerabilities (AA24-317A). The top two entries were Citrix NetScaler ADC and Gateway flaws (CVE-2023-3519 and CVE-2023-4966). Fortinet's FortiOS and FortiProxy SSL-VPN (CVE-2023-27997) was also on the list. The agencies reported that most of the frequently exploited vulnerabilities in 2023 were first exploited as zero-days, meaning attackers used them before a patch existed. In 2022, fewer than half were.

That last point is the hard one. Fast patching is still essential, but a gateway can be compromised before a fix exists. Your design has to limit what an attacker gets when that happens.

The advisories above come from the US and its Five Eyes partners. The products are sold worldwide, so the same flaws apply to a bank in the GCC, a manufacturer in India or a hospital in the EU running the same appliance.

What is ZTNA, and how does it differ from a VPN?

Zero trust is the idea that no user or device is trusted just because of where it sits on the network. NIST's SP 800-207 Zero Trust Architecture (August 2020) says zero trust grants no implicit trust to assets or user accounts based on their network location or on who owns the device. It says checking the user and the device, and deciding what they may reach, are separate steps that happen before a session to a resource opens.

Zero trust network access (ZTNA) is the remote access part of that idea. Instead of joining the network, the user asks for a specific application. A policy decides, per request, whether to allow it.

Traditional VPN ZTNA
What the user gets A network connection, often to whole subnets A connection to one named application
When trust is checked Mostly at sign-in At sign-in and on each access request, with device and context signals
What the internet sees A listening gateway on your edge Depends on design; some products publish applications through a broker so the applications accept no inbound connections (confirm with the supplier)
Lateral movement after a stolen login Easy if routes are broad Limited to what that identity is allowed to reach
Typical blind spot The appliance itself The identity provider and the policy rules

The difference that matters most in a breach is the second-to-last row. A VPN account that is stolen or abused can often scan and reach the internal network. A ZTNA identity that is stolen reaches the applications that identity was granted, and no further.

Where does SASE fit next to ZTNA?

SASE (secure access service edge) is an industry term for delivering network connectivity and security services, such as ZTNA, web filtering and firewalling, from a cloud service instead of from boxes in your data centre. It is a packaging and delivery model, not a standard with a fixed definition. If a supplier says "SASE", ask which of the controls in this post it actually provides and where the policy decisions are made.

Which systems should move from VPN to ZTNA first?

You do not need to switch off the VPN on day one. A staged move is safer. My suggested order follows the risk, not the ease.

  1. Third parties and contractors. They usually need one or two applications, not your network. They are the clearest win for per-application access.
  2. Administrator access to critical systems. Domain controllers, hypervisors, backup consoles, cloud admin portals. Put these behind per-application access with phishing-resistant sign-in, and remove them from general VPN routes.
  3. Web applications used by most staff. Intranet, HR, finance and ticketing tools. These are usually the easiest to publish through a ZTNA broker.
  4. Legacy and thick-client applications. These often depend on protocols or fixed network paths. Leave them on a tightly scoped VPN until they can be modernised or wrapped.
  5. Retire the VPN, or shrink it. Once usage is near zero, remove it. If a small group still needs it, limit it to named users and named destinations.

At each stage, measure what is still on the VPN. If you cannot say who uses it and for what, you have found your next task.

What doesn't ZTNA fix?

ZTNA changes where the trust decision is made. It does not remove the need for the controls around that decision.

  • Identity becomes the front door. If an attacker steals a valid session, ZTNA lets them in as that user. A session cookie copied by malware can pass the checks, as described in Infostealers and Session Cookie Theft. Phishing-resistant sign-in and short session lifetimes still matter.
  • The broker is now critical infrastructure. Whether the ZTNA service runs in your data centre or in a supplier's cloud, its availability and its own security are now your risk. Ask how it is patched and how you would know if it were compromised.
  • Device checks are only as good as the signal. A posture check that trusts a self-reported "antivirus on" flag is weak. Tie access to managed, compliant devices where you can.
  • Over-broad policies recreate the VPN. A rule that grants "all staff to all internal apps" is a VPN with extra steps.
  • It does not stop data leaving through approved apps. A user allowed to open the finance system can still export from it. Data controls are a separate layer.
  • Internet-facing applications still need patching. ZTNA hides many internal apps, but your public website, mail and file-transfer services remain exposed. The ransomware guide covers patching that edge.

Going deeper: for security and IT teams

Architecture in NIST terms. In SP 800-207 the policy engine (PE) is "responsible for the ultimate decision to grant access", using enterprise policy plus external inputs such as threat intelligence. The policy administrator (PA) is responsible for "establishing and/or shutting down the communication path" between subject and resource, "via commands to relevant PEPs". The policy enforcement point (PEP) handles "enabling, monitoring, and eventually terminating connections". In a ZTNA product, map these to the vendor's components: where does the decision run, which signals feed it, and what enforces it at the application? NIST's National Cybersecurity Center of Excellence published the final SP 1800-35 Implementing a Zero Trust Architecture on 10 June 2025, built with 24 vendors to demonstrate 19 sample implementations. Use it to compare real integrations rather than marketing diagrams.

Maturity model. CISA's Zero Trust Maturity Model version 2.0 (April 2023, aligned to OMB M-22-09) has five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. The v2.0 document adds three cross-cutting capabilities: Visibility and Analytics, Automation and Orchestration, and Governance. Each pillar moves through four stages: Traditional, Initial, Advanced and Optimal. CISA's announcement notes "Initial" was added in version 2 so organisations can mark a starting point. Score each pillar separately. A ZTNA rollout moves Networks and Applications; it does nothing for Data on its own.

Treat an exploited gateway as an identity incident. ED 24-01's supplemental direction is a useful playbook. Before returning a device to service, agencies had to export configuration, factory reset, rebuild and upgrade, then reset admin passwords, API keys and local user passwords. They also had to assume domain accounts associated with the device were compromised: reset on-premises account passwords twice, revoke Kerberos tickets and revoke cloud tokens. The original directive required running Ivanti's external Integrity Checker Tool and applying updates within 48 hours of release. A later revision added CVE-2024-22024, a flaw that gave access to restricted resources without authentication.

Hardening the VPN you still run. - Track every remote access product against CISA's Known Exploited Vulnerabilities catalog; the CVE, CVSS, EPSS and KEV guide explains how to rank them. - Keep older entries in view. AA24-317A's second table still lists CVE-2018-13379 (FortiOS SSL VPN) and CVE-2019-11510 (Pulse Connect Secure), years after patches shipped. - Do not store domain credentials on the appliance, a point CISA and partners make in AA24-038A. Restrict the management interface to an admin network. - Ship appliance logs off the device in real time, so a compromised box cannot erase its own history.

Detection. AA24-038A recommends reviewing VPN and account logons for impossible travel, unusual frequency and unusually long sessions. Add alerts for VPN sessions that reach domain controllers or backup systems, new local accounts on the appliance, configuration changes outside change windows, and outbound connections from the appliance itself. After a ZTNA rollout, alert on policy changes that widen access, and on access from devices that fail posture checks.

Questions for a ZTNA supplier. - Where do the PE and PEP run, and can traffic reach my applications if your control plane is down? - Do my applications accept any inbound connections from the internet once published? - Which device signals can policies use, and are they attested by a management tool or self-reported? - How do you patch your own edge, and how fast do you notify customers of a vulnerability in it? - Can I export every access decision to my SIEM, with user, device, application and result?

A ZTNA readiness checklist

  1. List every way into your network: VPNs, remote desktop gateways, remote support tools, file-transfer servers.
  2. For each VPN user group, write down which applications they actually use.
  3. Move contractors and admin access to per-application access first.
  4. Require phishing-resistant sign-in for anything that grants remote access.
  5. Set a patch target for internet-facing appliances measured in days, and track KEV entries for your vendors.
  6. Write the step for "our VPN was exploited": isolate, rebuild, reset credentials twice, revoke tickets and tokens. The incident management guide shows where it fits.
  7. Review VPN logs weekly for long sessions and logons from unexpected places.
  8. Score yourself against the five pillars of CISA's maturity model once a year.

Key takeaways

  • A VPN connects a user to a network; ZTNA connects a user to one application after checking identity, device and context.
  • VPN and edge appliances keep appearing in advisories: Ivanti Connect Secure triggered CISA Emergency Directive 24-01 in January 2024, and Citrix NetScaler and Fortinet SSL-VPN flaws were among the most exploited of 2023.
  • Most of 2023's frequently exploited flaws were first used as zero-days, so design to limit the damage, not just to patch.
  • Move contractors and admin access first, legacy applications last.
  • ZTNA makes identity the front door. Pair it with phishing-resistant sign-in, managed devices and narrow policies.
  • If a gateway is exploited, treat it as a domain-wide identity incident, not only a device problem.

Sources