Remote enterprise teams often rely on legacy VPNs that grant broad network access with minimal context. Facing modern threats, regulatory pressure, and a demand for better user experience, assessing whether to retain VPNs, migrate to Zero Trust Network Access (ZTNA), or operate a hybrid model becomes an urgent strategic decision.
ZTNA offers per-application access, continuous verification and richer telemetry; VPNs provide simple network-level tunnels that can be inexpensive to deploy but introduce lateral-movement risk and compliance complexity. The right choice depends on application topology, compliance profile, budget, and operational maturity.
Key takeaways
- ZTNA often reduces lateral risk and improves auditability for SaaS and per-application access while enabling tighter MFA and contextual policies.
- VPNs can remain appropriate for full-network access needs and legacy on-prem systems, especially where latency-sensitive, broadcast or multicast traffic is required.
- Performance trade-offs vary by topology: ZTNA can reduce round-trip time for cloud-hosted apps but may add hops for on-prem systems; independent benchmarks are essential. Indicative numbers current at time of writing.
- Migration costs include connectors, identity integration, and operational changes; total cost of ownership (TCO) can favor ZTNA over 24 months for distributed workforces with strong compliance requirements.
- A staged, application-first migration with an RFP and decision matrix minimizes risk and preserves user experience.
Which enterprises should choose ZTNA over VPN
ZTNA aligns with Zero Trust principles: least-privilege, continuous verification and per-resource access control. The following enterprise profiles typically benefit more from ZTNA:
Cloud-first enterprises with distributed endpoints
Enterprises that host primary workloads in public cloud (AWS, Azure, GCP) and rely on SaaS productivity and business apps often see immediate gains from ZTNA. ZTNA can avoid hairpinning through a central site and can implement per-app policies and CASB integration to enforce data controls.
Regulated organisations with strict audit requirements
Organisations subject to GDPR, PCI DSS, HIPAA or UK-specific rules may prefer ZTNA where per-session logging, fine-grained access, and shortened blast radius reduce compliance scope. Citations: Office of the Information Commissioner (ICO) guidance on data minimisation ICO - For organisations and NCSC guidance on network segmentation NCSC.
Organizations with frequent third-party or contractor access
ZTNA enables per-contractor access for specific apps and time-bound policies without exposing the corporate network. This reduces privileged access sprawl and simplifies certification for auditors.
Enterprises pursuing least-privilege and microsegmentation
When the security roadmap prioritizes reducing lateral movement and implementing Zero Trust in depth, ZTNA provides control points that integrate with IDaaS, endpoint posture, and SIEM for continuous telemetry.
Cases where VPN may still be preferable
VPNs remain useful where broad layer-3 access is required (legacy file shares using SMB broadcast, domain join operations, specialised telemetry protocols), or when network-level performance constraints demand fewer application hops.
Case studies: VPN vs ZTNA in remote teams
This section summarizes anonymized, realistic case studies that illustrate trade-offs, with metrics that are indicative and current at time of writing.
Case A, Global SaaS-first enterprise (5,000 remote users)
Situation: Global engineering and sales teams primarily used SaaS and cloud services with an MPLS hub and site-to-site VPNs. Challenges included long VPN failover times, limited session visibility and PCI audit gaps.
Intervention: Per-application ZTNA deployment with IDaaS integration (SAML SSO + device posture checks), phased connector rollout, CASB and DLP for sensitive SaaS apps.
Outcomes (12 months):
- Median time-to-resource reduced from 4.2s (VPN) to 1.6s (ZTNA) for most SaaS endpoints.
- Reduction in scope for PCI environment: approx. 35% fewer systems classified in scope due to per-app segmentation.
- Operational tickets for VPN connectivity dropped by 62%.
Case B, Manufacturing enterprise with OT and legacy systems (2,300 users)
Situation: Manufacturing floor used legacy SCADA protocols and multicast streams; remote engineering required network-level access for diagnostics.
Intervention: Hybrid approach: ZTNA for corporate SaaS and remote employee access; retained site-to-site and per-user VPN for OT networks with strict jump-hosting and bastion controls.
Outcomes:
- Reduced VPN user base by 70% while preserving necessary OT access.
- duced per-session logging and MFA for engineering VPN accounts; no measurable performance degradation for OT diagnostics.
Case C, Financial services firm (1,200 remote advisors)
Situation: Advisors accessed trading and CRM apps; compliance required strong session audit trails and user privacy controls under GDPR.
Intervention: ZTNA with per-app logging forwarded to SIEM, integrated DLP and conditional access policies by geolocation and device posture.
Outcomes:
- Audit readiness improved: average time to produce access logs for an incident reduced from 4 days to under 2 hours.
- No regulatory breaches attributable to remote access controls in 18 months post-deployment.
Performance depends on topology: brokered ZTNA (cloud service edge), inline ZTNA (on-prem gateway), or connector models. Independent benchmarking is recommended before full migration. The following table shows indicative comparative metrics from controlled lab tests (mixed WAN conditions, 2026 indicative figures).
| Metric |
Typical VPN (site-hub hairpin) |
Cloud ZTNA (direct app access) |
Hybrid ZTNA (connector to on-prem) |
| Initial connection time |
1.8–4.5s |
0.9–2.2s |
1.5–3.0s |
| Round-trip latency to cloud app |
40–120ms (via hub) |
15–60ms (direct) |
25–80ms (connector) |
| Throughput overhead (TLS/session) |
2–5% CPU overhead (client tunnel) |
3–7% (session broker and per-app proxies) |
4–9% (on-prem connector + encryption) |
| Resilience (failover time) |
Depends on VPN concentrator HA; 10–30s |
Cloud edge failover: 1–5s |
Connector failover depends on cluster config: 3–15s |
Practical notes on measurements
- Latency gains for ZTNA are most noticeable when traffic would otherwise be hairpinned through a distant hub.
- For high-throughput bulk transfers, VPN tunnelling can sometimes be faster if local egress is suboptimal for ZTNA connectors; consider split-tunnel or direct egress policies.
- Performance numbers are indicative and vary by vendor architecture, client placement, and chosen deployment model.
DevOps snippet: Kubernetes sidecar connector (example)
A minimal Kubernetes Deployment manifest for a lightweight ZTNA connector sidecar pattern. This example is conceptual and must be adapted to the chosen vendor API and security policy.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-with-ztna-sidecar
spec:
replicas: 3
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: application
image: registry.example.com/app:stable
ports:
- containerPort: 8080
- name: ztna-sidecar
image: vendor/ztna-connector:latest
env:
- name: CONNECTOR_TOKEN
valueFrom:
secretKeyRef:
name: ztna-secrets
key: token
ports:
- containerPort: 8443
resources:
limits:
cpu: "250m"
memory: "128Mi"
This pattern routes inbound/outbound traffic through the connector for per-app controls and can be combined with network policies for microsegmentation.
Cost comparison and hidden operational trade-offs
Cost considerations extend beyond license fees. Key elements include: connectors/proxies, IDaaS and MFA licensing, network egress (for cloud broker models), engineering resources for integration, helpdesk changes, and training.
Total cost of ownership (TCO) factors
- Licenses: Per-user/per-app pricing for ZTNA versus per-concurrent-user or site licenses for VPN appliances.
- Infrastructure: VPN concentrators, HA appliances, and bandwidth, versus ZTNA connectors and cloud egress fees.
- Operational: Ongoing patching and VPN client management vs. ZTNA connector orchestration and ID integrations.
- Incident cost: Faster detection and smaller blast radius with ZTNA can reduce incident response costs.
| Cost Item |
VPN |
ZTNA |
| Upfront license |
Low–medium (appliance + client) |
Medium–high (per-user, per-app) |
| Operational overhead |
Higher (client updates, NAT, HA) |
Medium (connectors, policy mgmt) |
| Network egress |
Concentrated at hub |
Distributed; possible cloud egress costs |
| Compliance ops |
Complex (broad scope) |
Simplified for per-app scope |
Hidden trade-offs
- Operational maturity: ZTNA requires identity-centric policy design and stronger endpoint posture checks; teams without IAM maturity may face a steep learning curve.
- Vendor lock-in: Some ZTNA vendors provide proprietary connectors and orchestration; RFP questions should address exportability and APIs.
- Egress costs and telemetry: Cloud-brokered ZTNA can increase egress volume and data forwarded to cloud SIEMs.
Compliance and breach scenarios: VPN vs ZTNA risks
Auditability and logging
ZTNA typically provides session-level logs, per-application telemetry and user context that simplifies audit trails. VPNs often require network packet capture or additional logging layers to achieve similar levels of traceability.
Data exposure and lateral movement
VPNs that grant full network access increase the risk that a compromised host can move laterally. ZTNA reduces the blast radius by restricting access to specific resources and requiring continuous device posture and identity verification.
Breach scenario comparison
- VPN compromise: An attacker with valid VPN credentials may access multiple services, increasing potential data exfiltration paths.
- ZTNA compromise: An attacker may access only those apps permitted by policies; however, compromised IDaaS or weak connector security may still expose applications. Defence in depth remains critical.
Refer to PCI DSS guidance for segmentation and scope reduction PCI SSC and ICO documentation for GDPR practical steps ICO.
Decision checklist: migrating remote teams from VPN to ZTNA
Pre-migration assessment (2–4 weeks)
- Inventory applications: catalogue SaaS, cloud, and on-prem apps and classify by sensitivity and protocol.
- Categorize access patterns: per-app, network-level, broadcast/multicast needs.
- Identify compliance requirements: GDPR, PCI, HIPAA and local regulations.
RFP and vendor evaluation (4–8 weeks)
Key RFP questions:
1. How is per-session telemetry exported and stored? Include log formats and retention options.
2. Does the vendor support connectors for legacy apps, SSH jump hosts, and RDP proxying?
3. What is the API surface for policy automation and SIEM integration?
4. How does the vendor handle offline devices or intermittent connectivity?
5. Can the solution reduce compliance scope and provide evidence for auditors?
6. What are typical SLA and failover behaviors across regions?
Pilot (4–6 weeks)
- Select 100–500 pilot users across regions and device types.
- Pilot per-app access for low-risk SaaS, then add business-critical apps after validation.
- Measure performance, UX and incident metrics against baseline VPN behavior.
Rollout and decommission (3–9 months)
- Application-first phased migration: SaaS → cloud-hosted on-prem-paths via connectors → legacy on-prem via jump-hosts.
- Retire redundant VPN concentrators after a defined threshold (e.g., 90% app access through ZTNA).
- Update incident playbooks and SIEM parsers for new telemetry flows.
RFP / Technical checklist (condensed)
- Support for SAML/OIDC and SCIM provisioning
- Connector HA patterns and deployment models
- Per-app DLP/CASB integration
- SIEM and SOAR log formats (CEF, JSON) and retention
- Support for split-tunnel and browser-based access
Responsive infographic (HTML + inline CSS)
VPN
- Network-level tunnel
- Broad access (higher blast radius)
- Lower upfront cost for simple setups
➡️
ZTNA
- Per-app access
- Continuous verification and logging
- Improved auditability and reduced scope
Legend: performance and compliance gains depend on topology; pilot tests recommended before full migration.
Strategic analysis: trade-offs and final considerations
- Pros of ZTNA: reduced lateral movement, better per-session telemetry, simpler compliance scope for many SaaS/cloud environments, improved UX for direct-cloud access.
- Cons of ZTNA: requires identity and endpoint posture maturity, potential cloud egress costs, possible vendor-specific connectors and operational learning curve.
- Pros of VPN: Simple model familiar to network teams, useful for full-network diagnostics and certain legacy protocols.
- Cons of VPN: broader access increases breach impact, harder to produce per-app audit trails, and can degrade user experience for cloud-native apps.
Enterprises with strong identity foundations, heavy SaaS use and compliance needs often find ZTNA preferable. Organizations with significant legacy on-prem or OT requirements may need a hybrid approach.
Frequently asked questions
What is the core technical difference between VPN and ZTNA?
A VPN creates a network tunnel granting layer‑3 access to resources; ZTNA enforces per‑application access using identity, device posture, and continuous policy evaluation.
ZTNA can improve performance for cloud-hosted apps by avoiding hub hairpinning, but results depend on deployment model and network egress choices. Benchmarks should be performed before migration.
Can ZTNA reduce PCI or GDPR scope?
ZTNA may reduce the number of systems in scope by limiting access to specific apps, but scope reduction depends on an organisation's environment and auditors' criteria; consult compliance counsel and auditors.
Is hybrid operation (VPN + ZTNA) reasonable?
A hybrid approach is common: ZTNA for general user and SaaS access, VPN for specialised legacy or OT needs, with strict controls and limited VPN user population.
What are the primary operational challenges when migrating to ZTNA?
Challenges include identity integration, re-mapping access policies to per-app rules, connector deployment for legacy apps, helpdesk training, and SIEM ingestion changes.
Run controlled pilots with representative users, measure connection times, round-trip latency to critical apps, throughput for heavy workflows, and monitor UX metrics and helpdesk tickets.
What should an RFP require from ZTNA vendors?
Require APIs for policy automation, connector deployment models, SIEM formats, session log retention, support for legacy protocols, and clear pricing for egress and per-user licensing.
How to handle remote troubleshooting when ZTNA blocks access?
Establish break-glass procedures, temporary time-boxed access policies, and a diagnostic VPN or bastion path strictly limited to privileged engineers.
Conclusion
10-minute action plan
- Inventory top 10 remote-accessed applications and classify them by sensitivity and protocol. (5–10 min to list names and owners)
- Run a short baseline: measure current VPN connection time and latency to three representative apps from remote locations. (5–10 min per app; use simple ping/traceroute or browser timing)
- Initiate a vendor-neutral RFP checklist and schedule pilot with identity team for a 30–90 day proof of concept.
A data-driven, application-first migration with staged pilots, RFP-driven vendor selection and clear compliance mapping often yields the fastest path to measurable risk reduction and improved user experience.
