Introduction
For nearly three decades, the virtual private network (VPN) was the default method for granting remote employees access to internal corporate resources. As workforces became more distributed and applications moved to the cloud, the assumptions underlying VPN-based access — implicit trust once a user is on the network, broad network-level access rather than application-specific access — became a significant liability. Zero Trust Network Access (ZTNA) emerged as the software category designed to replace this model, built around the principle that no user or device should be trusted by default, regardless of whether it is inside or outside the traditional network perimeter. This article explains how ZTNA works architecturally, how it differs from VPN, the deployment models available, and how to evaluate vendors.
The Zero Trust Principle
Zero trust is an access philosophy, not a single product: every access request is evaluated on its own merits based on identity, device posture, and context, rather than being granted broad access because the requester is on a particular network segment. ZTNA software is the practical implementation of this principle for application access, applying three core rules to every connection request:
- Verify explicitly. Authenticate and authorize based on all available signals — user identity, device health, location, and time — rather than network location alone.
- Use least-privilege access. Grant access only to the specific application or resource required, not the entire network segment the application resides on.
- Assume breach. Design access controls and segmentation on the assumption that some part of the environment may already be compromised, limiting the blast radius of any single compromised credential or device.
ZTNA vs. VPN: Key Architectural Differences
| Dimension | Traditional VPN | ZTNA |
|---|---|---|
| Access granularity | Network-level; user joins the corporate network segment | Application-level; user connects only to the specific authorized app |
| Trust model | Implicit trust once authenticated and connected | Continuous verification per session and per request |
| Visibility of internal network | Often broad; lateral movement risk if compromised | Internal network and other applications remain invisible to the user |
| Device posture checks | Limited or absent in many legacy deployments | Typically integrated; access can be conditioned on device health |
| Scalability for remote/hybrid work | Concentrator hardware can become a bottleneck | Cloud-delivered, elastically scalable by design |
Core Architecture Components
Most ZTNA platforms share a common architectural pattern, sometimes still referred to by its earlier name, the software-defined perimeter:
- Policy engine / policy decision point. The central service that evaluates each access request against configured policies, typically integrating with an identity provider for authentication and with device management tools for posture data.
- Policy enforcement point. A gateway or connector, often deployed close to the application, that enforces the policy engine’s decisions and brokers the actual connection between user and application.
- Lightweight client or clientless access. Many products offer both an installed agent for a richer posture-checking experience and a clientless, browser-based option for unmanaged or contractor devices accessing specific web applications.
- Cloud-delivered control plane. Rather than routing all traffic through a physical hardware concentrator, most modern ZTNA platforms operate through a globally distributed cloud network, reducing latency and eliminating a single choke point.
Deployment Models
ZTNA products generally fall into two broad deployment approaches:
- Service-initiated (outbound-only) ZTNA. A lightweight connector deployed inside the application environment initiates an outbound connection to the vendor’s cloud, meaning no inbound firewall ports need to be opened. This significantly reduces the internal network’s exposed attack surface compared to inbound VPN concentrators.
- Endpoint-initiated ZTNA. An agent on the user’s device initiates the connection request, which is then evaluated by the policy engine before being brokered to the enforcement point near the application.
Many organizations deploy a combination: agent-based access for managed corporate devices, and clientless, browser-based access for contractors, partners, or bring-your-own-device scenarios where installing an agent is impractical.
Relationship to SASE and Microsegmentation
ZTNA is frequently offered as one component of a broader Secure Access Service Edge (SASE) platform, which converges networking and security functions — including secure web gateway, cloud access security broker, firewall-as-a-service, and ZTNA — into a single cloud-delivered service. Organizations evaluating ZTNA in isolation should consider whether a broader SASE platform better serves their long-term architecture, particularly if they are also consolidating branch networking. ZTNA also complements, rather than replaces, internal microsegmentation, which restricts lateral movement between workloads inside the data center or cloud environment; ZTNA primarily governs user-to-application access, while microsegmentation governs workload-to-workload traffic.
Evaluation Criteria for ZTNA Vendors
- Identity provider integration depth, including support for the organization’s existing identity provider and multi-factor authentication methods.
- Device posture assessment capability, including the specific signals evaluated — OS patch level, disk encryption, endpoint security agent status — and whether posture can be continuously re-evaluated mid-session, not just at initial connection.
- Application protocol support, since some early ZTNA products supported only web applications while others fully support legacy client-server, TCP, and UDP protocols required by many enterprise applications.
- Global point-of-presence footprint, which directly affects latency for geographically distributed workforces.
- Clientless access options for third parties and unmanaged devices.
- Logging and integration with SIEM for access telemetry and anomaly detection.
Implementation Roadmap
Organizations rarely migrate from VPN to ZTNA in a single cutover. A phased approach is more common and less disruptive:
- Phase 1: Deploy ZTNA in parallel with existing VPN for a pilot group, starting with a small set of well-understood applications.
- Phase 2: Expand application coverage and user groups, using access logs from the pilot to refine policy granularity.
- Phase 3: Migrate remaining user populations and applications, retaining VPN only for edge cases such as legacy protocols not yet supported.
- Phase 4: Decommission legacy VPN infrastructure once coverage and confidence are sufficient, reducing both attack surface and operational overhead.
Frequently Asked Questions
Does ZTNA eliminate the need for a firewall?
No. ZTNA governs user access to applications but does not replace network firewalls, which continue to control traffic between infrastructure components, enforce segmentation, and protect against network-layer threats.
Can ZTNA support legacy, non-web applications?
Many modern ZTNA platforms support arbitrary TCP/UDP applications, not just HTTP-based web apps, though the depth of protocol support varies by vendor and should be validated against the organization’s specific application portfolio during evaluation.
Is ZTNA the same as a VPN replacement?
ZTNA is most commonly adopted as a VPN replacement for remote access, but its access-broker architecture and continuous verification model differ enough from VPN that it should be evaluated as a distinct category with its own policy design, not simply a drop-in swap.
How does ZTNA handle third-party or contractor access?
Clientless, browser-based ZTNA access allows organizations to grant scoped, time-limited access to specific applications for contractors or partners without issuing a managed device or requiring agent installation, while still enforcing identity verification and logging all activity.
Conclusion
ZTNA addresses structural weaknesses in the VPN model that have become increasingly costly as workforces distributed and attackers grew more adept at exploiting broad network access following credential compromise. Selecting the right ZTNA platform requires looking past the “zero trust” label to the specific architecture — service-initiated versus endpoint-initiated, protocol support, identity integration depth, and global performance — that will determine whether the deployment genuinely reduces risk or simply repackages old assumptions under new terminology.
Leave a Reply