When your team asks for remote access, the usual answer for years was a VPN. Lately a new approach has moved from niche to mainstream: Zero Trust Network Access, or ZTNA. If you’ve been deciding whether to update access for a remote or hybrid workforce, you’ll want to understand what each option actually does for security, how users will feel day to day, and what those choices will do to your budget.
How ZTNA, and VPN Grants Access
Traditional VPNs (virtual private networks) extend network-level access. In practice that means: your device authenticates, a secure tunnel forms, and the device behaves as though it’s on the corporate network. If the network has a file server, internal admin tool, or older database, the VPN makes them reachable. That model worked well when most apps were inside corporate data centers and few people worked remotely.
ZTNA flips the focus. Instead of giving access to the network, it grants access to individual applications based on identity, device posture, and contextual signals. Think of ZTNA as a gatekeeper who checks a badge, makes sure the badge is valid for this particular doorway, inspects whether the person is carrying a known-good device, and optionally monitors what happens during the visit. The device never receives broad network privileges unless specifically allowed.
Those sound like subtle distinctions, but they change how risks and usability show up. VPNs are broad: once someone is in, tools that aren’t properly segmented can be discovered and misused. ZTNA is narrow: the user sees only what they have explicit permission to use. The tradeoff is integration, ZTNA depends on a reliable identity system and device posture checks. If your identity foundation isn’t solid, ZTNA can feel brittle.
Security, and Practical Differences Between ZTNA, and VPN
Security is the reason teams often consider change, but it helps to be specific.
First: attack surface. VPN appliances and concentrators expose a few high-value targets: correctly configured firewalls and regularly exposed ports are attractive to attackers. Compromised credentials or unpatched vulnerabilities at that perimeter can let an adversary step into the network. ZTNA reduces exposure by hiding applications behind access controls; the external surface is smaller, and scanning for reachable services returns fewer results.
Second: granularity and continuous validation. Classic VPNs generally check identity at connection time and grant network-level access for the session length. ZTNA, by design, re-evaluates trust signals such as device health, user identity, and sometimes telemetry during an active session. This continuous posture reduces windows where a stolen credential or a compromised device can be abused at length.
Third: lateral movement. Suppose an attacker gains entry through a compromised account. With a VPN, that entry often travels freely across subnet boundaries unless teams have aggressively segmented traffic. ZTNA enforces application-level least-privilege: the attacker only sees the application the user is permitted to access. Fewer lateral paths mean fewer escalation opportunities.
Fourth: visibility and logging. A “user connected to VPN” log tells you someone was on the network. ZTNA logs which specific application endpoints were accessed, by whom, from which device, and under what posture. That level of detail lines up better with modern incident response needs and compliance records.
That said, ZTNA is not an instant cure-all. It relies on solid identity providers (IdPs), multi-factor authentication, and often endpoint agents for posture checks. If those foundations are weak (if MFA is optional, devices aren’t managed, or logs aren’t collected centrally) ZTNA’s advantages shrink. Also, some legacy applications expect subnet-level connectivity or broadcast traffic; wrapping them in ZTNA may require redesign or temporary hybrid approaches.
I once led a phased rollout for a mid-sized company that had an aging VPN farm and a handful of critical legacy tools. We started by rolling ZTNA for web-based internal apps first. Within weeks, an attacker tried credential stuffing against public services. Because we had the ZTNA path in place, the attackers couldn’t discover backend admin tools that remained hidden by application-level controls. The VPN appliances still needed urgent patching, that work would have been riskier had we not already reduced the discoverability of key systems.
ZTNA vs VPN: Performance and User Experience
Performance is less glamorous than security but just as decisive. When people slow down, they look for workarounds.
VPN performance problems usually come from the traffic path. Many VPN deployments send traffic from user devices to a central corporate gateway and then back out to the internet or into datacenter apps, often called “hairpinning.” That adds latency and consumes central bandwidth. When remote teams rely on cloud applications, routing their traffic through corporate data centers is inefficient.
ZTNA often routes connections more directly. For cloud or SaaS applications, many ZTNA models let users connect to the application endpoint through a nearby enforcement point or a cloud fabric that avoids unnecessary backhaul. The result is lower latency and less load on the corporate network. For on-prem apps, ZTNA uses lightweight connectors that proxy only the allowed application traffic rather than all network streams.
Scalability matters too. VPN concentrators are capacity-limited, each has finite CPU, encryption throughput, and concurrent session limits. When usage spikes, IT teams must add appliances or licensing, and that work takes time. ZTNA providers, especially cloud-native ones, scale elastically across regions. That reduces the need for constant capacity planning.
User friction is also a factor. VPN clients often require installation and can be intrusive: full-tunnel traffic policies can slow down home internet, and frequent re-authentication prompts disrupt flow. ZTNA can be more seamless: single sign-on via the IdP, context-aware access, and fewer full-tunnel redirects. The modern remote worker often notices faster page loads and fewer timeout errors with a well-implemented ZTNA setup.
Another practical note: not all apps behave the same. Bulk file transfers or applications that require raw network-level access (certain admin tools or network discovery protocols) may still run better over a VPN-like connection or an appropriate site-to-site tunnel. Many organizations end up with a hybrid pattern: ZTNA for user-facing apps and cloud services, VPN or direct tunnels for heavy internal flows.
A quick example from a client: after switching their internal CRM to ZTNA, sales reps reported faster logins and fewer dropped sessions when they were on mobile networks. Meanwhile, the IT team removed multiple VPN concentrators that had been straining under evening traffic. The migration required upfront planning, but the day-to-day user experience improved noticeably.
Total Cost of Ownership (TCO)
Cost comparisons often get reduced to licensing numbers, but the full picture includes operations, risk, and migration friction.
Up-front costs differ. If you already have VPN appliances and licenses, sticking with them can feel cheaper because there’s no new subscription. ZTNA is commonly delivered as a subscription and usually requires integrating with identity and device posture systems. That means initial work and possible added seats for IdP licensing.
Ongoing operations change shape. VPNs bring ongoing appliance maintenance, patching, firmware upgrades, and capacity management. They also require monitoring for unusual traffic patterns that might indicate compromise. Those operational overheads can be hidden: they show up as staff hours, emergency patching sprints, and sometimes as incident response costs when a zero-day affects an appliance.
ZTNA moves much of the scaling and patching burden to the vendor. You trade a chunk of CapEx for more predictable OpEx. The subscription cost often includes global enforcement points, but you still pay for identity seats, endpoint posture agents, and logging/analytics capacity. High-fidelity logging (which ZTNA encourages) increases storage and SIEM costs, and that should be part of your model.
There’s also migration cost. Moving dozens of apps to ZTNA connectors or redesigning legacy flows is non-trivial. For organizations that do a slow phased migration, you may run both systems in parallel for months, duplicating some costs. But many teams recoup that migration expense as they reduce VPN appliance counts, lower bandwidth expenses at central egress points, and reduce emergency patch workloads.
Another hidden line item is risk cost. A successful breach through a VPN appliance can lead to extended downtime or expensive remediation. While it’s hard to put a dollar figure on avoided breaches, organizations increasingly factor potential incident response costs into their TCO calculations. Analysts have observed that at scale (particularly for globally distributed teams) ZTNA subscription models often reach cost parity or savings within 18–36 months, but results depend on app mix and user distribution.
Deployment Patterns and Sequences
If you’re responsible for change, the deployment path matters more than the labels.
1. Start with inventory: Understand every application your people use, the protocols they depend on, and which ones require subnet connectivity or special ports. That inventory determines whether each app is a clean candidate for ZTNA, needs a connector or proxy, or should remain behind a VPN or site-to-site link for now.
2. Pilot from low risk to high: Pick a small set of internal web apps and a friendly user group. Integrate the IdP, enable MFA, validate device posture rules for that group, and measure latency and login success rates. A focused pilot surfaces integration gaps (single sign-on misconfigurations, header forwarding quirks, or legacy auth flows) without risking core operations.
3. Parallel operation is normal: Treat VPN as a fallback for legacy flows while you convert apps to ZTNA. For several months you’ll likely operate both; plan for monitoring and cross-mapping of access logs so incident response teams aren’t blind during the transition.
4. Plan your observability: ZTNA produces more granular logs. That’s good, but it requires SIEM capacity, retention planning, and clear dashboards. Decide what you need to keep, for how long, and what alerts should look like.
5. Train users and support teams: While the user experience often improves with ZTNA, support teams will handle different calls: SSO errors, posture agent updates, or permission escalations. Prepare documentation and scripts to help them diagnose problems quickly.
6. evaluate governance. ZTNA encourages least-privilege, but governance still matters: role definitions, access approval workflows, and periodic reviews should be baked into your identity policy so access doesn’t creep over time.
Edge Cases and When to Keep Both
There are clear winners in many scenarios, but both approaches can coexist.
Keep VPN for site-to-site tunnels connecting datacenters or for special-purpose flows that require raw network access. Preserve VPN access for a small set of trusted administrative accounts where subnet-level diagnostics or certain protocols are essential.
Use ZTNA for user-driven access to SaaS apps, internal web portals, SSH/RDP sessions proxied at the application level, and developer-facing APIs. Prefer ZTNA when you want to hide services from the public internet and limit discovery.
Hybrid patterns often prove the most pragmatic: ZTNA for web and cloud applications, and VPN for specific legacy paths. Over time, teams that commit to modernizing applications can shift more traffic to ZTNA and reduce VPN scope.
Measuring Success: What to Watch After Rollout
After you roll something out, check the metrics that show real improvement.
- Security signals: number of exposed services visible to external scans, incidents caused by compromised appliances, and the median time to contain lateral movement during test scenarios.
- Performance signals: user-reported slowdowns, average page load or RDP latency before and after, and the change in bandwidth consumption at corporate egress points.
- Operational signals: time spent on emergency patches, number of capacity upgrades required, and helpdesk tickets per user related to access.
- Cost signals: appliance counts, subscription fees, and any changes in SIEM or IdP expenses. Don’t forget to account for staff hours saved by reduced maintenance or patching.
In short, success is not a certificate that you’ve deployed ZTNA; success is observable reduction in risk, better user experience, and predictable operational cost.
A short checklist for evaluating vendors and options
Rather than a table, here are the questions to ask when you talk to a vendor or your internal team:
- How does identity integrate? Can we use our IdP and existing MFA?
- What protocols are supported natively (web, SSH, RDP, custom TCP)?
- How is device posture checked and what agents are required?
- Where do logs go, and what retention/volume pricing applies?
- What happens during an outage of the vendor (can we fail open or do we have offline access)?
- For on-prem apps: how are connectors deployed, and do they open inbound ports?
- Pricing model: per user, per application connector, or bundled?
These questions focus evaluation on fit, not feature gloss.
How to Align Identity Systems for a Smooth ZTNA Launch
First, integration is more work than marketing slides suggest. ZTNA felt like a light-weight overlay in one sales demo I watched; in practice we had to map out SSO attributes, fix inconsistent header forwarding across internal apps, and standardize service accounts. The project still saved time later, but the early weeks required patient plumbing.
Second, human behavior is unpredictable. When full-tunnel VPN slowed home internet for certain power users, some tried disabling VPN routes locally, an insecure workaround. ZTNA’s more limited access reduced that incentive. Tech alone doesn’t fix behavior; clear communication and simple support channels help.
FAQs
Will ZTNA stop every breach? No. It reduces attack surface and narrows blast radius, but attackers still exploit human and device weaknesses. Good identity hygiene, MFA, and endpoint management remain essential.
Is ZTNA just a cloud thing? No. Many ZTNA vendors provide connectors or appliances to expose on-prem apps securely without opening arbitrary ports. ZTNA can protect on-prem apps while avoiding broad network access.
Will ZTNA break legacy apps? Sometimes. Apps that rely on L2/L3 broadcasts, proprietary authentication tied to network location, or certain management protocols may require redesign or temporary VPN access. Plan those migrations deliberately.
Do I need a consultant? Not necessarily. Small teams with clear inventories and a solid IdP can pilot ZTNA themselves. Larger, heterogeneous environments may benefit from outside help for migration planning and application adaptation.
How to Decide Internally
If most of your users rely on cloud and web applications, and you have or can enable a mature IdP with MFA, start moving toward ZTNA for user access. Plan a phased rollout: inventory, pilot, integrate posture and logging, then migrate core apps. Keep VPN for specific, high-need legacy flows and site-to-site tunnels as you modernize.
If your environment is heavily tied to legacy on-prem traffic or you have constrained identity tooling, prioritize strengthening your identity foundation first. A poorly implemented ZTNA can introduce workarounds and friction that erode the security gains.
Above all, treat network access as a program rather than a product swap. The gains come from identity hygiene, device management, and observability as much as from any one vendor’s features.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
