Flat networks and VPNs give any compromised credential broad lateral access to your environment. Zero trust network access (ZTNA) replaces that implicit trust with per-session, identity- and posture-based access to specific applications, never to the network itself. Staying on legacy VPN means higher breach exposure, failed audit findings, and a remote-access stack that gets harder to defend as your workforce, contractors, and cloud footprint grow.
The Real-World Impact: Why Enterprises Are Investing in ZTNA Now
Breach economics. IBM’s 2025 Cost of a Data Breach Report put the global average breach cost at roughly $4.44M, with the US average above $10M. Stolen or compromised credentials remain among the most common initial attack vectors, and VPNs convert one stolen credential into network-level access.
VPN appliances are a target. Edge devices, including VPN gateways, have been repeatedly exploited through zero-day and unpatched vulnerabilities. CISA and the NCSC have both issued advisories on this pattern. Every internet-exposed concentrator is attack surface you patch on someone else’s timeline.
Regulatory and framework pressure. Auditors increasingly expect least-privilege, continuously verified access:
- United States: NIST SP 800-207 (Zero Trust Architecture), the CISA Zero Trust Maturity Model, and OMB M-22-09 for federal agencies and their suppliers. HIPAA, PCI DSS 4.0, and SOC 2 access-control criteria also apply.
- United Kingdom: NCSC zero trust architecture design principles, Cyber Essentials, and the Cyber Security and Resilience Bill for operators of essential services.
- Canada: Canadian Centre for Cyber Security guidance on network security zoning and zero trust, plus PIPEDA obligations.
- Australia: The ASD Essential Eight, the Information Security Manual (ISM), and SOCI Act obligations for critical infrastructure.
Operating model shift. Contractors, M&A integrations, SaaS sprawl, and multi-cloud have made “inside the perimeter” meaningless. ZTNA is the access-layer answer, and it is the usual starting point for a broader SASE or zero trust program.
Core Capabilities You Must Demand
1. Identity-Centric, Application-Level Access
Access must be brokered per application, not per subnet. The user should never receive a network route. Demand default-deny policy with explicit, auditable application segments, including support for non-web protocols (RDP, SSH, SMB, database ports, thick clients, and legacy apps with server-initiated flows).
2. Continuous Device Posture and Risk Assessment
A one-time check at login does not meet NIST 800-207’s intent. The platform should evaluate OS patch level, disk encryption, EDR status, and certificate presence continuously, and revoke or step down access mid-session when posture degrades. Native integrations with your EDR/MDM (CrowdStrike, Microsoft Defender, SentinelOne, Intune, Jamf, and the like) should be bidirectional and not limited to a CSV import.
3. Deep IdP and Conditional Access Integration
Verify SAML/OIDC support, SCIM provisioning, and the ability to consume risk signals from your identity provider (Entra ID, Okta, Ping). Policy should be able to reference group, role, location, device trust, and risk score in one rule. If you must maintain a parallel identity store, walk away.
4. Agent and Agentless Options
You need both. An endpoint agent suits managed devices and gives richer posture data. Browser-based agentless access suits contractors, BYOD, and M&A scenarios where you cannot install software. Ask how policy parity is maintained between the two modes.
5. Inline Inspection and Data Protection
ZTNA alone authenticates and authorizes. It does not inspect what happens inside the session. Evaluate native or tightly integrated DLP, malware scanning, and TLS inspection, or confirm a clean path into your existing SWG/CASB/SSE stack. Without this, you have moved the trust boundary but not reduced data-exfiltration risk.
6. Global Architecture and Performance
Check point-of-presence (PoP) coverage in your actual user geographies (US, UK, Canada, Australia, and APAC if relevant), data residency options, and published uptime SLAs. Ask for latency benchmarks to your hosted applications, not to the vendor’s marketing site.
7. Telemetry, Logging, and Audit Readiness
Require per-session logs (user, device, application, policy decision, bytes, duration) with native SIEM export and a retention period that meets your longest compliance mandate. Ask for pre-mapped reports for SOC 2, ISO 27001, PCI DSS, and NIST 800-53.
8. Third-Party and Privileged Access
Contractors and vendors are frequent breach paths. Look for time-bound access, approval workflows, session recording, and just-in-time elevation. Some vendors bundle these capabilities; others will require a PAM integration.
Vendor Evaluation Matrix: What to Look for vs. Red Flags
| Feature/Capability | The Enterprise Standard (What to look for) | The Red Flag (What to avoid) |
|---|---|---|
| Access Model | Per-application, default-deny, outbound-only connectors; no inbound firewall rules or network-level routing for users | “ZTNA” that is a rebranded VPN with a subnet-level tunnel and IP allow-lists |
| Posture Enforcement | Continuous evaluation with mid-session revocation; native EDR/MDM signal ingestion | Posture checked at login only, or requiring manual rule updates |
| Protocol and Legacy Support | Documented support for web, SSH, RDP, SMB, VoIP, and server-initiated flows; clear limitations list provided up front | Web-app-only coverage, with “roadmap” promises for everything else |
| Architecture and Resilience | Cloud-native, multi-region PoPs, published SLA of 99.99% or higher, and a defined fail-open/fail-closed policy per app | Single-tenant gateways you must patch and scale yourself, or no published failover behavior |
| Logging and Compliance Evidence | Full session telemetry, SIEM streaming, configurable retention, and current SOC 2 Type II / ISO 27001 reports available under NDA | Log access limited to the vendor console, short fixed retention, or no independent attestation |
Deployment and Integration Challenges
Application discovery is the biggest bottleneck. Most organizations cannot produce an accurate inventory of what users actually reach over VPN. Run the VPN and ZTNA in parallel for 30 to 60 days and use flow data to map real dependencies before you write policy. Skipping this step produces broken apps and an overly permissive “allow all” fallback that defeats the purpose.
Legacy and server-initiated protocols break assumptions. Applications that open connections from the server back to the client (some VoIP, file-transfer, and older ERP systems) often fail under outbound-only connector models. Test these first in a pilot, not last.
Policy sprawl. Teams routinely recreate hundreds of VPN firewall rules as individual ZTNA policies. Instead, build policy around roles and application groups, tie it to IdP groups, and enforce a review cycle. Assign a clear policy owner before go-live.
Phased migration beats big-bang. A workable sequence:
- Pilot with IT and a low-risk business unit (weeks 1 to 4).
- Migrate third-party and contractor access, where the risk reduction is highest (weeks 4 to 10).
- Migrate high-value applications (finance, source code, production access).
- Move general workforce traffic.
- Decommission VPN concentrators and close inbound firewall rules.
Don’t leave the VPN running indefinitely. Many programs stall at “ZTNA plus VPN,” which doubles your attack surface and your cost. Set a decommission date in the project charter.
Helpdesk and change management. Agent rollout, certificate enrollment, and MFA prompts produce support tickets. Budget for communications, a self-service enrollment flow, and tier-1 runbooks before the first production cohort.
Procurement due diligence. Request a reference customer of similar size and industry, a documented exit/data-portability clause, and the vendor’s incident disclosure history. For regulated sectors, confirm data residency and sub-processor lists.
Build the Business Case
Frame ZTNA to the CFO as risk reduction plus cost consolidation, not as a security upgrade.
Quantify risk mitigation. Use your own loss expectancy model, with an industry benchmark such as IBM’s breach-cost data as a reference. If ZTNA meaningfully reduces the probability or blast radius of credential-driven lateral movement, the avoided expected loss often outweighs the licence cost on its own.
Identify hard-dollar offsets:
- Retired VPN hardware, support contracts, and refresh cycles
- Reduced MPLS or backhaul bandwidth where traffic moves to direct-to-cloud
- Consolidated tools if the platform replaces a PAM-lite, jump-host, or contractor-VDI layer
- Lower cyber insurance premiums or improved coverage terms, where the insurer recognizes MFA, segmentation, and access controls (confirm with your broker)
Quantify operational gains:
- Hours saved on access provisioning and deprovisioning (SCIM automation)
- Reduced audit prep time through exportable evidence
- Faster M&A onboarding, with days instead of months to grant access to acquired staff
Set realistic time-to-value. Contractor access and a first set of critical apps can typically show measurable results within one to two quarters. Full VPN retirement for a large enterprise commonly takes 9 to 18 months.
Define success metrics up front:
- Percentage of applications behind ZTNA
- Percentage of users off VPN
- Mean time to provision and revoke access
- Number of over-permissioned accounts remediated
- Audit findings closed on access control
Present the CFO with a three-year TCO comparison of the current VPN stack against the ZTNA model, including hardware, licences, staffing, and an explicit risk-adjusted loss line.
FAQ
What is the difference between ZTNA and a VPN?
A VPN places the user on the network and relies on perimeter controls to restrict what they reach. ZTNA grants access to individual applications after verifying identity, device posture, and context for each session. The user never gets a route to the underlying network.
Is ZTNA the same as zero trust?
No. Zero trust is a strategy covering identity, devices, networks, applications, and data. ZTNA is the technology that enforces zero trust principles for remote and application access, and it is typically one component of a wider program.
How long does a ZTNA deployment take?
A pilot typically takes 4 to 8 weeks. Enterprise-wide migration and VPN retirement commonly run 9 to 18 months, depending on application complexity and legacy protocol dependencies.
Does ZTNA replace SASE or SSE?
ZTNA is a core component of both. Many vendors bundle it with secure web gateway (SWG), CASB, and firewall-as-a-service in a single platform. Buyers should decide whether to purchase standalone ZTNA or a consolidated SSE/SASE platform based on their existing security stack and vendor consolidation goals.
Conclusion
ZTNA is now the baseline expectation for secure remote and third-party access, and the gap between mature and legacy access models directly affects breach exposure and audit outcomes. Audit your current VPN and remote-access footprint this quarter, map your real application dependencies, and request demos from at least three vendors using the evaluation matrix above.