The way organizations grant access to their applications and data has changed fundamentally, but many of the tools people rely on to secure that access have not. Zero Trust Network Access, or ZTNA, represents the architectural shift that closes that gap. This article explains what ZTNA is, how it works, why it performs differently than a VPN, and what organizations and managed service providers need to understand before putting it into practice.
Zero Trust Network Access (ZTNA) is a security technology that grants access to specific applications and resources based on verified user identity, device posture, and defined policy, without placing the user onto the broader network. Access is denied by default and granted only when identity and context checks pass.
The definition matters because it establishes what ZTNA actually does, and what it specifically does not do. ZTNA is not a VPN replacement in the surface sense of "something that moves traffic securely." The access model is categorically different: a VPN extends network access, while ZTNA grants application access. A user connected through ZTNA reaches the specific resource they are authorized to use, nothing more.
ZTNA stands for Zero Trust Network Access. The name combines the Zero Trust security philosophy, under which no user, device, or network connection is trusted by default, with a practical access control mechanism for network and application resources.
The phrase "never trust, always verify" captures the operational logic of ZTNA. Traditional perimeter-based security granted broad network access once a user or device cleared the perimeter. ZTNA treats every access request as unverified, regardless of whether the request comes from inside the corporate network, from a trusted device, or from a user with valid credentials from a previous session.
This assumption changes what the access decision is based on. Rather than asking "is this user inside our network?" ZTNA asks: "Who is this user? What device are they on? Does the device meet our security requirements? What exactly do they need access to? Does the current context, including time, location, and behavioral signals, align with policy?" Access is granted when each condition is properly met.
ZTNA operates through a series of discrete checks that happen before a user reaches a protected resource. The workflow can be broken into five stages.
A user requests access to an application or resource, such as an internal business application, a cloud service, a remote desktop, or a private API endpoint. This request triggers the ZTNA authentication and policy flow. The application itself remains hidden from the internet; it has no exposed IP address or open port that an unauthenticated user could discover or probe.
The ZTNA system verifies the user's identity, typically through an integration with an identity provider (IdP) and multi-factor authentication. Simultaneously, the system assesses device posture: is the device managed? Does it have current security patches? Is endpoint protection active? Is disk encryption enabled? A user with valid credentials on an unmanaged, non-compliant device may be denied access at this stage, regardless of who they are.
This dual verification of identity and device is one of the structural differences from legacy access control methods. A VPN verifies the user. ZTNA verifies the user and the device they are operating from.
Once identity and device checks pass, the request moves to the policy engine. The policy engine evaluates contextual factors against pre-defined access policies: which resources is this user authorized to access? Does the current context (location, time of day, connection type, behavioral signals) match the expected pattern for this user and role? What is the sensitivity of the resource being requested?
Policy evaluation is dynamic. The same user may receive different access decisions depending on context: full access from a managed, enrolled corporate device, restricted access from a compliant personal device, or no access from an unmanaged device with outdated software.
When policy evaluation succeeds, the ZTNA system creates a direct, encrypted connection between the user and the specific application they are authorized to reach. This happens through a connector or gateway that brokers the connection between the user's client and the protected resource. No other resources are visible or reachable through this connection. The rest of the network remains invisible.
This scoping is the mechanism that limits lateral movement. An attacker who compromises a user's credentials cannot use that credential to explore the network or reach systems that user was not explicitly authorized to access.
ZTNA does not grant access once and then disengage. The session is monitored continuously. If risk signals change, whether the device disconnects from MDM, behavioral anomalies appear, or the session context shifts in a way that violates policy, the system can restrict, downgrade, or terminate access without waiting for the session to end naturally.
This continuous evaluation is what distinguishes ZTNA-enforced access from static credential-based models. Access is evaluated at the start of a session and maintained throughout it, rather than granted once at login.
A ZTNA implementation involves several functional components that work together to evaluate, enforce, and monitor access decisions.
ZTNA deployments generally fall into two architectural approaches, and the distinction matters for how different use cases are handled.
Agent-based ZTNA requires a lightweight software client installed on the endpoint. The agent enforces device posture checks locally, brokers the secure connection, and ensures all traffic to protected resources flows through the ZTNA system. Agent-based ZTNA is suited for managed endpoints, meaning corporate-owned devices enrolled in device management, where deploying software is practical and device-level policy enforcement is required.
Clientless (agentless) ZTNA provides access through a browser or web portal without requiring software installation on the endpoint. The user authenticates through a web interface and reaches protected applications without an agent managing the connection. Clientless ZTNA is better suited for scenarios where installing software is not practical: contractors using personal devices, third-party vendors with unmanaged endpoints, and BYOD environments where organizations need to grant limited access without full endpoint control.
The two approaches are not mutually exclusive. Most enterprise and MSP deployments use agent-based ZTNA for managed devices and clientless ZTNA for contractors and unmanaged access scenarios, applying different policy levels based on the access method.
Application concealment is one of ZTNA's most operationally significant features. In a traditional network or VPN architecture, applications are reachable via IP addresses or domain names that are publicly discoverable. Attackers can enumerate these addresses, scan for vulnerabilities, and target them directly.
ZTNA uses a software-defined perimeter (SDP) model: protected applications have no inbound ports exposed to the internet. Connectors establish outbound-only connections to the ZTNA service. An unauthenticated user cannot reach, discover, or even identify that the application exists. The attack surface for internet-facing reconnaissance is effectively eliminated.
Todyl's Secure Global Network (SGN) incorporates this SDP approach. The platform can hide internet-connected infrastructure from non-verified users, which reduces exposure to initial access attempts and reconnaissance-phase attacks.
The ZTNA vs. VPN comparison is worth examining concretely, because the security differences are architectural rather than incremental.
A VPN authenticates a user once, typically with a username and password and sometimes with MFA, and then grants that user access to the network segment behind the VPN server. From that point forward, the user can reach any resource accessible from that network segment, which in a typical SMB flat network is most of the infrastructure.
The model has several structural problems. First, there is no device posture check by default. A compromised personal laptop with outdated patches and no endpoint protection can connect if the credentials are valid. Second, there is no inspection of traffic through the encrypted tunnel. The VPN secures the transport; it does not evaluate what is being transmitted or where within the network the user is going. Third, the broad network access model means that a single compromised credential hands an attacker access to everything that user could reach, rather than the single application they needed.
Beyond security design, VPN infrastructure carries an operational burden. Hardware or virtual appliances require patching, and the CVE history on major VPN platforms shows consistent, high-severity vulnerabilities that ransomware operators and nation-state threat groups exploit at scale. The Ivanti, Fortinet, and Cisco IOS XE vulnerabilities documented in Todyl's analysis of why MSPs are moving away from VPNs illustrate how quickly a known VPN vulnerability becomes an active exploitation campaign.
ZTNA resolves the VPN's structural issues at the architectural level. A stolen credential in a ZTNA environment does not grant network access. The attacker would also need to pass device posture checks, which an unknown or unmanaged device will fail. Even if an attacker somehow passes both identity and device checks, they reach only the specific resources that user's policy permits, scoped at the application level. Lateral movement requires a separate, successful compromise of a different authorized user's access, not just free traversal of the network.
The operational burden difference is also meaningful. Cloud-native ZTNA platforms have no hardware to patch, no appliances to maintain, and no infrastructure sitting at the network edge waiting to be exploited.
A common source of confusion is treating ZTNA and Zero Trust as synonyms. They describe related but distinct concepts.
Zero Trust is a security framework and philosophy, not a product category. NIST's foundational guidance in SP 800-207 defines zero trust as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. Zero trust assumes no implicit trust is granted based on network location or asset ownership.
ZTNA is one of the primary technical mechanisms for implementing that philosophy at the network access layer. Deploying ZTNA moves you meaningfully toward a zero trust security posture, but ZTNA alone does not constitute a complete zero trust architecture. A full zero trust implementation addresses identity governance, device management, application security, data protection, and visibility across all of these domains.
CISA's Zero Trust Maturity Model organizes zero trust across five pillars: identity, devices, networks, applications and workloads, and data. ZTNA addresses primarily the network and application access pillars, enforcing identity-based access at the network layer and restricting access to specific applications based on user and device context.
The identity and device pillars depend on the IdP integration and device management capabilities that feed signals into the ZTNA policy engine. The data pillar requires additional controls beyond what ZTNA addresses alone.
Practically, organizations that deploy ZTNA and consider zero trust "done" have addressed a critical piece, but the broader zero trust strategy requires a coordinated set of controls across multiple domains. Todyl's approach, described in depth in the zero trust strategy and capabilities overview, implements zero trust through ZTNA for remote access and through LAN ZeroTrust (LZT) for internal network segmentation, which addresses the lateral movement risk within the LAN that ZTNA alone does not cover.
Secure Access Service Edge (SASE) is a cloud-native architecture that converges network connectivity and security services into a single platform. Rather than deploying separate tools for secure web gateway, DNS security, firewall, VPN, and remote access, SASE unifies these capabilities in a cloud-delivered service. Users connect to the nearest point of presence (PoP), where security services run inline before traffic reaches its destination.
SASE was coined by Gartner in 2019 and has become the primary architectural framework for consolidating network security and access control for distributed workforces.
ZTNA is a foundational component of SASE. When users access private applications through a SASE platform, the ZTNA capability handles identity verification, device posture assessment, policy enforcement, and application-scoped access. The secure web gateway, DNS security, and threat inspection capabilities in SASE handle traffic to internet destinations such as public SaaS apps, websites, and cloud services, while ZTNA controls access to private and internal applications.
Security Service Edge (SSE) is a related term that describes the security components of SASE (secure web gateway, CASB, and ZTNA) without the SD-WAN networking layer. For organizations focused purely on security service delivery rather than network transformation, SSE is the relevant category. For organizations (and MSPs) who need both secure access and network-layer threat prevention, full SASE is the more complete solution.
Cloud-delivered ZTNA, delivered through a SASE platform, provides operational advantages that standalone ZTNA tools do not. Security controls run consistently at every PoP, regardless of where the user is located. Policies are managed centrally and applied globally. There is no hardware at the edge to patch, no VPN concentrators to maintain, and no routing inefficiency from backhauling traffic through a central data center.
Todyl's SASE platform, built on the Secure Global Network (SGN), delivers ZTNA as part of a unified security stack that includes NGFW, IPS/IDS, secure DNS, web proxy with SSL inspection, and LAN ZeroTrust. The SGN routes connections through 40+ global points of presence, ensuring that users in distributed locations get low-latency connections without compromising enforcement. ZTNA is one of the configurable outcomes the platform enables, alongside Software-Defined Perimeter (SDP), conditional access, and secure remote desktop capabilities.
Read more about how these capabilities work together: Todyl SASE platform.
Lateral movement, meaning an attacker's ability to move through a network after gaining initial access, is one of the defining characteristics of modern ransomware campaigns and advanced persistent threats. In a flat network behind a VPN, a single compromised account gives an attacker the ability to communicate with other endpoints, escalate privileges, and spread malware across the environment before defenders have visibility into what is happening.
ZTNA constrains lateral movement at the architectural level. Users access only the specific applications they are authorized to reach. Devices on the network are isolated from each other unless a policy explicitly permits communication. An attacker who compromises one user's credentials reaches only that user's authorized applications, not the network infrastructure, other users' workstations, or sensitive servers outside that user's access scope.
Todyl extends this concept beyond remote access with its LAN ZeroTrust (LZT) technology. LZT functions as a firewall for the internal network: devices on the LAN are isolated from each other by default, blocking the device-to-device communication that ransomware relies on for propagation. When combined with ZTNA for remote access, organizations close the lateral movement risk both from external connections and from compromised internal devices.
Ransomware operators rely on two things: initial access and the ability to reach as many systems as possible before triggering a response. VPN-based access provides both. A valid VPN credential is initial access. Broad network connectivity is how the infection spreads.
ZTNA removes the broad connectivity piece. Even if an attacker obtains valid credentials and somehow passes device posture checks, they reach only the specific resources that user was authorized to access. The blast radius of a single compromised account is bounded by policy, not by whatever the network topology happens to permit.
Contractors, vendors, and third-party service providers are a persistent access control challenge. Traditional approaches often grant these users the same VPN access as full-time employees, sometimes with fewer controls, because deploying agents on non-corporate devices is impractical. The result is that third parties frequently have more network access than they need, and that access is difficult to audit or revoke cleanly.
ZTNA's deny-by-default model changes this dynamic. Third parties can be granted access to specific applications they need for their engagement. A contractor reaches the ticketing system and the project management tool, and nothing else. Clientless ZTNA handles the unmanaged device scenario without requiring software installation. When the engagement ends, access revocation is a policy change, not a manual infrastructure operation.
Remote and hybrid work transformed secure remote access from an occasional need to a daily operational requirement. Employees connect from home networks, hotel Wi-Fi, co-working spaces, and coffee shops, environments where the network cannot be trusted and where a VPN's always-on connection is often bypassed because the performance impact is too painful.
ZTNA addresses the performance problem by routing traffic to the nearest cloud PoP rather than backhauling everything through a central server. It addresses the security problem by enforcing identity and device checks regardless of where the connection originates. Users get consistent access to the applications they need; the organization gets consistent enforcement of access policy.
VPN replacement is one of the most common ZTNA deployment drivers. Organizations running aging VPN appliances face a compounding problem: the CVE record on major platforms is extensive, exploitation happens at scale and often faster than patching cycles allow, and the operational overhead of managing hardware at the edge grows as the remote workforce does.
A phased VPN-to-ZTNA migration, covered in detail in the implementation section below, replaces hardware-dependent, perimeter-anchored remote access with a cloud-native approach that requires no on-premises infrastructure, scales without new hardware, and eliminates the CVE exposure that VPN appliances carry by default.
As described above, ZTNA's deny-by-default model and clientless access option make it particularly well-suited for third-party risk management. Access is scoped, time-bounded if needed, and revocable without infrastructure changes.
Organizations running applications across a mix of on-premises, IaaS, and SaaS environments have historically struggled to enforce consistent access control. VPNs were designed for access to on-premises resources; extending that model to cloud-hosted applications introduces routing inefficiency and policy inconsistency.
ZTNA handles this naturally. The policy model is application-aware rather than network-topology-aware. Whether a private application runs in an on-premises data center, an AWS VPC, or a co-location facility, ZTNA enforces the same identity and device checks and delivers the same scoped access. The deployment location of the application is an infrastructure detail, not an access control constraint.
MSPs face a version of the ZTNA deployment challenge that is qualitatively different from what an enterprise security team faces. Enterprise teams manage one organization. MSPs manage dozens or hundreds of client environments simultaneously, each with different IT maturity levels, different compliance requirements, different application stacks, and different user populations. For an MSP, the harder question is not how ZTNA works, but how to manage it across every client without creating an operational burden."
For MSPs, ZTNA is both a security improvement and a service differentiation opportunity. Clients still running VPNs for remote access are carrying known, documented risk. Cyber insurance underwriters are tightening requirements around access control, MFA enforcement, device posture validation, and session logging, requirements that legacy VPNs cannot satisfy. Compliance frameworks that apply to healthcare, defense, and financial services clients have provisions that speak directly to how remote access is managed, logged, and audited.
An MSP who can walk into a client meeting with a concrete explanation of why VPN is a structural liability and a clear migration path to something better has a differentiated position. The conversation moves from "here is how we are maintaining your current tools" to "here is how we are modernizing your security posture."
The operational model for ZTNA in an MSP context requires multi-tenant architecture. Each client environment needs isolated policy management: one client's access policies cannot overlap with or affect another's. The MSP needs a single management plane to operate efficiently, but the policy and data separation across client tenants must be airtight.
When evaluating ZTNA solutions and platforms, MSPs should confirm that the architecture supports true tenant isolation, that role-based access control limits what each client-level administrator can see, and that the management interface supports centralized operations without requiring per-client infrastructure deployments.
Migration from VPN to ZTNA does not require a high-risk cutover event. A phased approach lets MSPs build confidence in policies and access patterns before decommissioning existing infrastructure.
A practical migration sequence:
Remote access controls only address part of the lateral movement problem. An employee working from the office, a device that gets infected through a phishing email, or an attacker who has already established a foothold inside the network can all move laterally without ever triggering a ZTNA policy, because ZTNA governs remote access rather than internal LAN traffic.
This is the gap that LAN-level zero trust addresses. Todyl's LAN ZeroTrust (LZT) technology isolates devices from each other on the internal network by default. Devices cannot communicate directly unless a policy explicitly permits it. The segmentation does not require VLAN reconfiguration or network architecture changes; it operates at the device level, which makes it practical to deploy even in the flat SMB network environments that MSPs manage most commonly.
The combination of ZTNA for remote access and LZT for internal traffic creates a layered zero trust posture that limits lateral movement regardless of where the attack originates. For MSPs, that means a single platform can address both the remote access and internal LAN security conversations with clients.
For MSPs serving regulated industries, ZTNA and SASE capabilities map directly to control requirements that clients must satisfy.
MSPs who can map their SASE and ZTNA deployment to these specific framework requirements have a concrete differentiator in competitive conversations with clients in healthcare, defense contracting, and financial services.
Successful ZTNA implementation depends on having the right foundational elements in place before access policies go live.
Incomplete application inventory: Teams frequently begin deploying ZTNA before they have a full picture of what the VPN was carrying. Legacy applications using non-standard ports, thick-client applications, or applications with server-initiated connections may require additional configuration. Documenting these before deployment avoids mid-migration surprises.
Identity provider gaps: If an organization's primary authentication is still on-premises Active Directory without cloud synchronization, hybrid identity configuration is required before ZTNA policies that depend on cloud identity signals can function correctly.
User communication: ZTNA changes how users experience application access. Proactive communication that explains what is changing, why, and what users should do if something is not accessible reduces support tickets and resistance during the transition.
For MSPs evaluating how ZTNA fits into a broader security architecture, Todyl's SASE platform delivers ZTNA as part of a unified stack that includes NGFW, IPS/IDS, DNS security, web proxy, and LAN-level zero trust, managed through a single console designed for multi-client, multi-tenant operations.
ZTNA stands for Zero Trust Network Access. It is a security technology that grants users access to specific applications and resources based on verified identity, device posture, and policy, without placing them on the broader network. Access is denied by default and granted only after identity and context checks pass.
A VPN authenticates a user once and grants broad access to the network segment behind the VPN server. ZTNA verifies identity, device posture, and context before granting access, then scopes that access to the specific resource the user needs. A compromised credential in a ZTNA environment does not hand over the network; the attacker reaches only what that credential was authorized to access.
No. Zero Trust is a security framework and philosophy. ZTNA is one of the primary technologies used to implement Zero Trust at the network access layer. Deploying ZTNA moves an organization meaningfully toward Zero Trust, but a complete Zero Trust architecture also addresses identity governance, device management, application security, and data protection.
ZTNA does not replace a next-generation firewall, but it does change what the firewall needs to do. A next-generation firewall handles network-layer threat inspection, content filtering, and lateral traffic enforcement. ZTNA handles identity-based access control for application access. In a well-designed architecture, such as a SASE platform that includes both, they operate as complementary layers.
ZTNA reduces the blast radius of a ransomware attack by limiting lateral movement. Even if an attacker gains access through a compromised credential, ZTNA confines that access to the specific resources the user was authorized to reach. However, ZTNA is one component of a defense-in-depth strategy, not a standalone ransomware prevention tool. Endpoint protection, email security, and threat detection capabilities address other stages of a ransomware attack chain.
Agent-based ZTNA is typically used for managed corporate devices. For BYOD and unmanaged devices such as personal laptops, contractor devices, and partner endpoints, clientless (agentless) ZTNA provides browser-based access to specific applications without requiring software installation. Different policy levels can be applied based on the access method.
Yes, and it handles this use case more cleanly than VPN. Clientless ZTNA allows contractors to reach the specific applications they need through a browser portal without requiring device enrollment or agent installation. When the engagement ends, access is revoked by removing the policy. There is no credential cleanup on remote infrastructure required.
ZTNA is a core component of SASE (Secure Access Service Edge). SASE is the broader architecture that converges network connectivity and security services, including secure web gateway, DNS security, NGFW, and ZTNA, into a cloud-delivered platform. ZTNA handles the private application access layer within that architecture. Deploying ZTNA through a SASE platform provides cloud-native delivery, centralized policy management, and complementary security services that a standalone ZTNA tool does not include.
Effective MSP ZTNA management requires a multi-tenant platform with true client isolation, centralized policy management, and role-based access that keeps client data separated. Phased migration from VPN to ZTNA, starting with new users and high-risk accounts and then expanding by cohort, lets MSPs validate policies across each client environment without a high-risk cutover.
Yes. Cyber insurance underwriters now require documented access controls, MFA enforcement, device posture checking, and session-level logging. ZTNA natively addresses all of these requirements. When delivered through a SASE platform, it is typically easier to produce the audit-ready documentation and compliance evidence that underwriters require.
ZTNA solves the access control problems that have made legacy remote access infrastructure a persistent liability, but it works best as part of a broader security architecture that includes network threat inspection, endpoint protection, and centralized detection and response.
For MSPs looking to move clients off VPN infrastructure and onto a modern, zero trust access model, Todyl's SASE platform delivers ZTNA alongside next-generation firewall, LAN ZeroTrust, DNS security, IPS/IDS, and 40+ global PoPs, all managed through a single console built for the multi-tenant operational model that defines managed services.
See how Todyl SASE and ZTNA work together
Or explore additional resources:
Evaluate your security posture against AI-powered attacks and get recommendations to close any gaps.
Subscribe to our newsletter to get our latest insights.