What Is ZTNA? Zero Trust Network Access Explained

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.

ZTNA Definition: The Core Concepts

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.

What Does ZTNA Stand For?

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 "Never Trust, Always Verify" Principle

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.

How Does ZTNA Work? A Step-by-Step Explanation

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.

Step 1: The Access Request

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.

Step 2: Identity and Device Verification

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.

Step 3: Policy Evaluation

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.

Step 4: Scoped, Encrypted Access

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.

Step 5: Continuous Monitoring

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.

The Architecture Behind ZTNA

Key Components of a ZTNA Solution

A ZTNA implementation involves several functional components that work together to evaluate, enforce, and monitor access decisions. ‍

• ‍Policy engine: The decision-making core of ZTNA. The policy engine evaluates access requests against defined policies, user identity, device posture data, and contextual signals. It produces a decision: allow, deny, or allow with conditions. The National Institute of Standards and Technology (NIST) describes the policy engine in NIST SP 800-207, Zero Trust Architecture as the component responsible for the ultimate grant or denial of access to a resource. ‍
• Policy enforcement point: The mechanism that acts on the policy engine's decision. The enforcement point sits between the user and the resource, allowing or blocking traffic according to the policy decision. This can be a gateway, a proxy, or an inline service depending on the architecture. ‍
• Connector/gateway: The intermediary that brokers the encrypted connection between the verified user and the protected application. In many architectures, the connector is deployed close to the protected resource (on-premises or in a cloud environment), while the gateway handles user-side connections. Neither the user's IP address nor the application's IP address needs to be directly exposed. ‍
• Identity provider (IdP) integration: ZTNA relies heavily on identity for access decisions. Integration with an IdP such as Microsoft Entra ID, Okta, or Google Workspace is typically a prerequisite, because the policy engine needs reliable, strong identity signals to make access decisions. ‍
• Device posture assessment: A mechanism to evaluate endpoint compliance before granting access. This can be agent-based (software on the endpoint that reports compliance status) or signal-based (assessment of device signals without a dedicated agent).

Agent-Based vs. Clientless ZTNA

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.

How ZTNA Hides Applications from the Internet

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.

ZTNA vs. VPN: Understanding the Fundamental Difference

The ZTNA vs. VPN comparison is worth examining concretely, because the security differences are architectural rather than incremental.

The VPN Security Model and Its Limitations

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.

How ZTNA Addresses What VPNs Cannot

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.

ZTNA vs. VPN Comparison Table

ZTNA vs. Zero Trust: Different Things, Related Concepts

A common source of confusion is treating ZTNA and Zero Trust as synonyms. They describe related but distinct concepts.

Zero Trust is a Strategy; ZTNA is the Technology That Implements It

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.

The Pillars of Zero Trust and Where ZTNA Fits

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.

ZTNA and SASE: How They Work Together

What is SASE?

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 as a Core Component of SASE

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.

Why Cloud-Delivered ZTNA Through SASE Matters

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.

What ZTNA Protects Against

Lateral Movement and Credential Abuse

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 and the Blast Radius Problem

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.

Third-Party and Contractor Risk

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.

ZTNA Use Cases

Secure Remote and Hybrid Work

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.

Replacing Legacy VPN Infrastructure

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.

Securing Third-Party and Contractor Access

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.

Protecting Private Applications in Hybrid Environments

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.

ZTNA for MSPs: Operational Considerations

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."

Why ZTNA Changes the Managed Security Conversation

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."

Multi-Tenant Management and Policy Control

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.

Phased VPN-to-ZTNA Migration for MSP Clients

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:

1. Audit current VPN usage. Map who is connecting, to what resources, how frequently, and from what devices. Documented access policies rarely match actual usage patterns. This audit informs ZTNA policy design from the start.
2. Enroll new users directly into the new platform. Every new hire and new device goes through ZTNA from day one. This builds a validated policy baseline without touching existing users.
3. Move high-risk users first. Users with administrative credentials, broad access, or connections to sensitive systems have the highest blast radius if their credentials are compromised. ZTNA-scoped access for these users reduces that exposure immediately.
4. Migrate by cohort. Move users in groups organized by role, department, or access profile. Validate and refine policies between cohorts. Problems are easier to diagnose incrementally than after a full migration.
5. Run parallel for a defined window. Keep VPN available as a fallback while confirming all required access is available through ZTNA. Set a clear decommission date and communicate it.
6. Retire the VPN infrastructure. Once all users are enrolled and policies are stable, decommission the appliance entirely. That device is no longer on the attack surface.

ZTNA and LAN-Level Zero Trust: Closing the Full Loop

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.

Compliance Alignment Across Client Environments

For MSPs serving regulated industries, ZTNA and SASE capabilities map directly to control requirements that clients must satisfy. ‍

• ‍HIPAA: Covered entities and business associates must implement technical safeguards controlling access to electronic protected health information (ePHI). VPN access grants access to the network, not to specific systems; demonstrating that only authorized users accessed specific ePHI systems requires session-level logging that a VPN cannot provide. ZTNA scopes access to specific applications and logs every session, so the audit trail is native to the architecture. ‍
• CMMC 2.0: Defense industrial base contractors must implement access control, audit logging, and configuration management practices tied directly to how remote users connect. ZTNA-enforced access with device posture validation and session logs maps to these requirements in a way that VPN deployments do not. ‍
• PCI-DSS v4.0: Payment card environments require controlled, logged, and monitored access to cardholder data environments. ZTNA scopes access to specific resources and logs every session, making assessment evidence far cleaner than what a VPN-based deployment can produce.

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.

How to Implement ZTNA: A Practical Starting Point

Prerequisites Before You Deploy

Successful ZTNA implementation depends on having the right foundational elements in place before access policies go live.

• A reliable identity provider with MFA enforced. ZTNA access decisions are only as strong as the identity signals they receive. If MFA is not enforced on user accounts, including service accounts, credential-based attacks can still yield valid access tokens that ZTNA will honor.
• Device management enrollment. For agent-based ZTNA, devices need to be enrolled in an MDM or device management system that can report compliance status. Without this, device posture checks cannot function.
• Application inventory. Know what applications you need to protect, where they are hosted, what protocols they use, and which users or roles need access to each. The completeness of this inventory directly determines the completeness of your initial policy coverage.
• Defined access policies. Identity alone is not enough. You need policy definitions that map user roles or groups to specific applications, with context conditions that reflect your security requirements.

Implementation Steps

1. Confirm identity infrastructure is in place and MFA is enforced.
2. Enroll managed devices in your device management solution.
3. Deploy connectors close to the protected applications (on-premises or in cloud environments).
4. Define and test access policies in a pilot group, such as IT staff or a single department, before broader rollout.
5. Validate that all required applications are accessible through the new platform for pilot users.
6. Expand enrollment by cohort, validating access and refining policies at each stage.
7. Decommission legacy remote access infrastructure once all users have transitioned and the policy baseline is stable.

Common Implementation Challenges

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.

‍What to Look for in a ZTNA Solution

Essential Capabilities

MSP-Specific Requirements

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 FAQs

What is ZTNA?

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.

How is ZTNA different from a VPN?

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.

Is ZTNA the same as Zero Trust?

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.

Does ZTNA replace a firewall?

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.

Can ZTNA prevent ransomware?

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.

How does ZTNA handle BYOD and unmanaged devices?

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.

Can ZTNA work for contractors and third parties?

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.

What is the relationship between ZTNA and SASE?

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.

How do MSPs manage ZTNA across multiple client environments?

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.

Does ZTNA help with cyber insurance requirements?

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.

Taking the Next Step

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:

• A Closer Look at Todyl's SASE and Zero Trust Network Access

• VPN Is Dead: Why MSPs Are Moving to SASE

• Todyl's Zero Trust Strategy and Capabilities