What Is ZTNA? VPN Comparison and a Guide to Application-Based Secure Access

What Is ZTNA, and Is It the Same as Zero Trust?

Zero Trust is a broad security approach; ZTNA applies that approach to application access over a network. A single access product cannot address every control across identity, devices, data, applications, and operations. NIST emphasizes that trust should not be granted implicitly because of network location or asset ownership, and treats authentication and authorization as separate functions.

Defining a ZTNA project as “installing a new client for every employee” is therefore inadequate. First identify the applications to protect, the user groups that need them, and the access to remove. Assess success by whether necessary workflows function and unnecessary access is blocked, not by the percentage of clients installed.

The Zero Trust architecture guide covers the broader principles, while the microsegmentation guide examines access boundaries between applications. Here, the focus is on designing and validating the path a human user takes to reach an application.

What Is the Difference Between ZTNA and VPN?

A VPN is a mechanism for providing protected communication and network access; ZTNA focuses on how access decisions should be made. Framing the comparison as “VPN gives access to everything, while ZTNA eliminates every risk” is misleading. VPN access can also be restricted through strong authentication, narrow network rules, and segmentation. NCSC’s example ZTNA architecture can use VPN or similar tunneling mechanisms.

The VPN considered here is the remote access VPN used by employees and support personnel. Site-to-site VPNs or SD-WAN connections (in Turkish) between branches address a different connectivity requirement. An organization can use SD-WAN between locations and ZTNA for user access; they are not necessarily alternatives.

Retaining the existing VPN may be technically more appropriate; that does not prevent improvements to the access model. Base the decision on application compatibility, security benefits, operational workload, and pilot results. Keeping the same broad network access behind a new product merely changes the product name.

How Does ZTNA Work? From the Access Decision to the Application

In a typical flow, a user requests access to a resource, their identity is authenticated, the required signals are evaluated, and the resulting policy decision is implemented at an enforcement point. The component making the decision and the component actually allowing traffic may belong to the same product, but their logical responsibilities remain different. NCSC distinguishes the policy engine, which evaluates signals, from the policy enforcement point, which implements the decision.

In an example access request, an employee first authenticates with their corporate identity. The policy evaluates whether the user belongs to the ERP group and whether the device meets the approved conditions. If access is allowed, traffic is enabled along the defined application path. The ERP system then uses its own role model to determine whether the employee can view orders or approve payments.

Permission to connect to an application does not mean unrestricted privileges within it. OWASP recommends enforcing authorization at the appropriate layer and validating permissions on requests. The presence of a ZTNA layer does not remove the application’s need for object-level and operation-level authorization checks.

How Do Private Application, SaaS, and Clientless Access Differ?

Access to a private application does not require the same traffic path as access to an internet-delivered SaaS application. Private resources can be made accessible through a connector, proxy, or controlled tunnel. For SaaS, identity federation, single sign-on, and the application’s own policy mechanisms may play a more prominent role. NCSC considers these scenarios separately. ^[2]

With client-based access, software on the device can manage traffic and some device signals. A clientless model can provide browser-based access to suitable web applications. However, “clientless” does not mean that every protocol is supported or that equally detailed device signals are available. Use the following table as an application inventory assessment framework, not as a list of guaranteed product capabilities.

For example, Microsoft Entra Private Access offers a product approach that defines private resources using FQDN and IP information and creates application-based access groups. This example does not mean that all ZTNA solutions provide the same addressing, client, or protocol support.

Do not limit the inventory to a note that “ERP worked.” Workflows may differ for regular users, application administrators, and external support personnel. Work with the application owner to identify operations that will not occur naturally during the pilot, such as period-end reports or scheduled integrations.

What Preparation Is Needed for Identity and Device Security?

Before moving to ZTNA, review account provisioning, role changes, access revocation, and device enrollment. NCSC’s preparation guidance identifies a reliable identity source, strong authentication, user and device inventories, data flows, and application dependencies as starting conditions.

MFA uses more than one authentication factor, but not all MFA methods offer the same resistance to attacks. NIST’s authentication guidance treats phishing-resistant methods separately. When selecting methods for critical access, consider account recovery, device loss, and support processes alongside user convenience.

This table describes questions for policy design, not mandatory fields in a product. For example, when device compliance information is unavailable, record “noncompliant” and “unknown” as separate states. Silently treating both as “compliant” creates an invisible exception; blocking both without explanation can increase the support burden.

The recommended approach is to document the acceptable age of signals and behavior when data is missing for critical applications. Also define the remediation path available to the user. Allowing a blocked device to reach update or support services safely is a separate policy decision from allowing it to access a business application.

How Do You Write an Application-Based Access Policy?

A good policy defines not only the resource and user group, but also the business justification, application owner, conditions of validity, and revocation process. The following matrix is a design example for a fictional organization. It is not a rule set to copy directly into production.

In this example, ERP, reporting, and management components are separate. External support personnel do not share employee accounts; every support specialist has an individual identity. Administrative access is treated as a separately approved workflow rather than a permanent entitlement added to normal user access.

Maintain an exception register alongside the matrix, with an owner, justification, compensating control, and expiry date for each exception. A record stating “temporarily allowed access to the entire network” can become permanent architecture unless it has an expiry and a tested removal process.

Privileged access management can address needs beyond reaching an application, such as administrative credentials, privilege duration, and session oversight. Do not assume these capabilities exist in the selected ZTNA product. For support providers in particular, do not use a single approval to grant both network connectivity and permission to export data or execute administrative commands.

Where Should Connectors Be Placed in Private Cloud and Colocation Environments?

The network containing a connector and the resources it can reach matter as much as the access granted to users. If the selected product uses connectors, clearly define the application group each connector serves and the backend network paths available to it. Restricting a user through a narrow policy while opening the entire management network to the connector produces an inconsistent design.

Microsoft’s connector architecture uses outbound connections from components in the private network and connector groups that can be assigned to applications. The vendor recommends multiple connectors in a group for availability. This product-specific example illustrates why outbound communication, group scope, and redundancy should be assessed separately.

Placing two connectors on the same virtualization host may cover only some process or virtual machine failures. A claim that the design also covers a facility or identity-service failure requires different evidence. Build the redundancy assessment around the failure scenarios it must withstand, not the number of devices.

When evaluating private cloud or colocation, discuss management responsibilities as well as capacity. Hosting a server does not mean that the same team manages ZTNA policies, application roles, and identity infrastructure.

How Do ZTNA, SD-WAN, SASE, SSE, and Microsegmentation Work Together?

These terms are not different brand names for the same answer. SASE combines WAN connectivity and security functions within a common architectural approach; SSE focuses on the security services side of that architecture. ZTNA is one of the access functions that may be included. Product packages vary, so individual functions must be verified during procurement.

For example, a branch may reach ERP over SD-WAN while an employee’s access is separately evaluated against identity and device conditions. The ERP system’s connection to its database can be restricted by a different workload policy. Do not combine these three decisions under a single “secure connection” label.

The SD-WAN guide (in Turkish) examines traffic paths and hub placement, while the microsegmentation guide explores boundaries between applications. Defining which team owns each layer during the ZTNA pilot makes it easier to distinguish identity, connectivity, and application problems during an incident.

Does Disabling an Account Immediately Terminate Existing Sessions?

Do not assume it does; test new access requests and ongoing sessions separately. Account status at the identity provider, the ZTNA connection, the application session, and the access token can have different lifecycles. Preventing an account from signing in again does not, by itself, demonstrate that every previously established application session closes at the same moment.

Microsoft’s explanation of Continuous Access Evaluation illustrates the relationship between events propagated from the identity provider to a resource service and the application/client combinations that support them. This mechanism is not a feature of every ZTNA product; support and time to take effect must be verified for the components in use.

For the pilot, capture five distinct observations: when the account or condition changes, when the policy system detects that change, when a new connection is denied, the state of the existing network session, and the time of the last successful operation inside the application. Correlate timestamps against the same time source. This allows you to explain at which layer the statement “access was revoked” is true.

For example, an organization may require access to a critical application to end within a specified period after an account is disabled. That period should not be treated as an industry standard or product guarantee; the risk owner should define it, and it should be measured against the actual application. If the product cannot meet it, assess shorter sessions, application integration, additional controls, or alternative architectures.

Continuous evaluation does not mean asking the user to enter a password again for every operation. The design objective is to detect changes in access conditions and apply the appropriate action. Rather than arbitrarily shortening session duration, assess security benefits, workflows, and support workload together.

What Happens If the Identity Provider or a Connector Fails?

ZTNA components become part of a critical access path. Design for failures of the identity service, signal source, management component, and connectivity, not just normal operation. NCSC considers observability, resilience, and controlled recovery paths alongside access security.

The following table does not describe any product’s default behavior. It defines the failure-scenario answers to request from suppliers and internal teams. In particular, do not accept an uncontrolled response such as “we will open all access if the cloud service fails” as a recovery plan.

Emergency access must not become a backdoor left open for everyday use. Define in advance who can use it, from which devices, with whose approval, how its use generates alerts, and what review follows. Microsoft’s emergency administrator account guidance is a product-specific example addressing lockouts caused by dependence on the normal identity flow; the same account count and settings need not be applied to every environment.

Actually execute the emergency access test. Keeping a password in a vault does not prove that the vault and the necessary management path will be accessible during an outage. Include this dependency in the business continuity plan.

Which Logs and Performance Measurements Should Be Collected for ZTNA?

When an access problem occurs, operations teams must distinguish “authentication failed,” “policy denied access,” “connector could not reach the target,” and “application returned an error.” A suggested logging model therefore includes user and device identity, target application, timestamp, policy version, decision, reason, session correlation, and the associated support ticket.

Rather than collecting everything from day one, define the questions to answer: Why was a particular employee denied access? Who accessed the critical application? When was external support authorization removed? Can identity, access, and application records be correlated for the same operation? NCSC’s observability approach supports traceable access decisions across different components.

Do not assess performance through network latency alone. Measure sign-in time, initial application access, and completion time for a representative business transaction separately. Compare the previous access model using the same user location, device, and workflow; examine peak-period distributions as well as averages. Do not combine authentication and large file transfers into one undifferentiated “slowness” metric.

Do not put passwords, session tokens, or unnecessary sensitive content in logs. Define access permissions, retention periods, and data sharing for support purposes. The observability guide provides complementary guidance on correlating records and measurements from different layers within a shared service context.

Fictional Example: Restricting an ERP Support Provider’s Access

This section is not a real customer case study. In the example, the ERP application runs in a colocation environment. Employees use their normal business roles, while an external support provider occasionally requests access to investigate issues. The existing problem is that the support group also has network access to management targets unrelated to ERP.

First, the application owner defines the support specialist’s actual task: inspecting application logs and using an approved support interface. Database administration is outside that scope. Next, an individual support account is associated with the support ticket, and the condition for ending access is defined. Third, while the new application access path is prepared, the legacy VPN and direct IP paths are reviewed separately.

The support interface may open successfully on the first day of the pilot, but that alone is not acceptance. The team must also demonstrate that an unauthorized management target cannot be reached, an unapproved device is denied, and access is revoked when the ticket closes. If the initial test shows that broad access remains available through the old VPN, the outcome should not be “ZTNA succeeded,” but “not accepted because an alternative access path remains open.”

Another test may show that the account cannot sign in again while the application session continues to perform operations. The identity and application teams may then have separate actions to take. Instead of relying on a green status icon in the product interface, compare the last successful operation’s timestamp with the organization’s acceptance criterion.

Finally, the support team completes a representative support request. If the work is completed, unnecessary targets are inaccessible, and access revocation behavior is documented, the defined pilot scope can be accepted. The benefit is then expressed as a narrower, verified access relationship rather than simply “the new product is live.”

Which Acceptance Tests Should a ZTNA Pilot Include?

Choose the pilot around the organization’s diversity of users and applications, not the product’s demonstration screens. Including at least one regular business application, one external support workflow, and one management workflow with stricter conditions can be a useful starting point. Keep the scope small enough for the team to investigate failures properly.

Document expected behavior before the following tests; do not invent success criteria during execution. The organization sets time limits according to application criticality. Perform denial tests only against approved pilot targets and test accounts.

An exception can be recorded for a failed test, but do not treat that as automatic acceptance. Document which risk is accepted, by whom, and until when. Unauthorized access to a critical target and an unclear user message do not have the same priority; classify security and usability outcomes separately.

How Should You Plan the Transition from VPN to ZTNA?

1. Define the Access Inventory and the Access to Remove

Map user groups, destinations, application owners, and existing access paths. Reviewing active sessions alone is not enough; ask about periodic maintenance and integration activities as well. The first deliverable should be an approved inventory of access relationships to protect, not a product list.

2. Complete the Identity and Device Prerequisites

Shared accounts, unclear group ownership, and devices that cannot be managed affect the pilot’s boundaries. Do not hide these issues behind broad exceptions. Record the required preparation, unresolved dependencies, and alternative access options separately.

3. Test the Policy Within a Limited Scope

An observation or reporting mode can be useful if the product supports it, but do not assume every solution does. Observe pilot users’ everyday work. Distinguish expected policy denials from missing application dependencies. Do not proceed to a broad rollout before completing the acceptance matrix.

4. Manage Old and New Paths Together in a Controlled Way

VPN and ZTNA can coexist during migration. Clearly define the access path for each application; do not leave unnecessarily broad access in place indefinitely under a “temporary” label. NCSC identifies legacy access paths that continue to bypass the policy engine as a significant design anti-pattern.

5. Roll Out in Application Waves and Hand Over to Operations

For each wave, obtain acceptance from the application owner, ensure support teams can see denial reasons, and execute the rollback procedure. Update the inventory to reflect rules and accounts removed from the old environment. Final deliverables should include current policies, ownership assignments, and test evidence, not just a technical installation record.

This sequence is not a fixed-duration project schedule. Application diversity and identity preparation may require more time than installing devices. Moving applications that have not passed acceptance through general network access simply to meet a deadline reduces the intended benefit.

Which Responsibilities Belong to the Organization, Application Team, and Service Provider?

Using a managed service does not automatically outsource responsibility for deciding business entitlements. The business owner should determine who needs access to an application; technical teams should make that decision enforceable and auditable. The following allocation is an illustrative starting model, not a contractual scope.

Make it clear who performs initial diagnosis, particularly when access fails overnight. If identity services, network operations, and application maintenance belong to different teams, they need a shared incident record. Do not assume that 24/7 monitoring includes authority to resolve every application problem.

When evaluating managed infrastructure services, clarify separately whether access policy management, identity integration, client support, and incident response are included.

How Should Cost and Dependency Be Evaluated When Selecting ZTNA?

Do not compare ZTNA costs solely through per-user licenses. Existing investments in identity and device security, application compatibility, connector operations, and support workload all contribute to total cost. The following questions provide a product-independent framework for assessing proposals.

At the end of the pilot, request more than a total price: ask which applications are not covered and which operations will remain manual. “All users are licensed” does not mean every business workflow is supported.

Apply the exit-planning approach discussed in the vendor lock-in guide here as well. Exporting a policy file does not mean another product will directly reproduce the same user/application mappings and session behavior. Considering an alternative access plan for a small application makes dependencies visible before a contract is signed.

Which Mistakes Should ZTNA Projects Avoid?

Treating product installation as architectural transformation: If the same broad network access remains behind the new access layer, the outcome may fall short of expectations. Assess policy and access scope independently of the product change.

Performing only positive tests: Acceptance should include a user’s inability to reach unauthorized targets as well as their ability to connect to ERP. Demonstrate that blocking applies to the right user at the right destination.

Overlooking existing sessions and alternative sign-in paths: Account disabling, application tokens, direct IP paths, and legacy VPN access may not pass through the same control point. Make every path visible in the inventory.

Equating device security with ownership: An organization-owned device is not necessarily healthy at the moment of access. Examine the signal actually used by the policy and when it was produced.

Leaving operations and recovery paths until the end: An incorrect policy can affect the access product’s own administrators. Support, monitoring, controlled emergency access, and rollback procedures should be tested during the pilot.

Assess Access Architecture and Operational Scope with Ixpanse

Secure access to enterprise applications involves the hosting infrastructure, network paths, and operational responsibilities as much as identity and device controls. The multi-factor authentication, managed firewall, and access control topics on Ixpanse’s Data Protection page can be evaluated alongside infrastructure monitoring and management within Managed Services.

The scope of any particular ZTNA product, license package, identity integration, or managed access service must be confirmed for the specific project. Do not assume that hosting alone manages user roles, device compliance, or every application access path.

Contact the Ixpanse team to assess employee and external service provider access to critical applications together with identity, device, network, and operational responsibilities.

Conclusion: From a Secure Connection to a Verified Access Model

The real outcome of a ZTNA project is not a new connection icon, but a clear explanation of which users can reach which resources under which conditions. Reliable identity information, application dependencies, narrow access policies, and testable session behavior must be considered together.

Start with one critical application. Document the required operation, prohibited destinations, access revocation behavior, and failure conditions. Validating that limited scope with evidence provides a stronger foundation than moving every user to an ambiguous policy.

Frequently Asked Questions About ZTNA

What is ZTNA?

ZTNA is an architectural approach intended to control user and device access to applications through explicit policies and contextual information. It does not treat connecting to a network as sufficient grounds for access to every resource. It is designed alongside controls such as in-application authorization and workload security.

Are ZTNA and Zero Trust the same thing?

No. Zero Trust is a broader approach spanning identity, devices, applications, data, and operations. ZTNA focuses on the access aspect of that approach. Purchasing a ZTNA product does not demonstrate that an organization has met every Zero Trust requirement.

Does ZTNA eliminate the need for VPNs entirely?

Not necessarily. Some VPN paths may remain for application compatibility, site connectivity, or recovery needs. Define the purpose, access scope, and owner of retained paths; do not leave uncontrolled alternatives that bypass the new policy.

Is MFA sufficient for ZTNA?

No. MFA strengthens authentication. The target application, user entitlement, device posture, and session behavior must be assessed separately. Permissions for operations inside the application also remain separately managed.

Does clientless ZTNA work with every application?

Do not make that assumption. Browser-accessible applications have different requirements from applications using desktop clients or other protocols. Verify client requirements and the quality of device signals in the selected product and actual workflow.

Can ZTNA protect applications running in a company’s own data center?

Yes. A suitable architecture can provide controlled access to applications on a private network. Design connector or proxy placement, name resolution, certificates, application dependencies, and security boundaries together. The use of cloud services or local components varies by product.

Does disabling a user account immediately end an existing session?

The same behavior is not guaranteed across every product and application. Preventing a new sign-in may not close an open application session. The pilot should measure both new connections and the last successful operation within existing sessions.

Does ZTNA replace microsegmentation?

No. ZTNA controls human users’ access to resources, while microsegmentation helps restrict communication between workloads. Used together, they cover different access paths; in-application permissions still require separate attention.

How should external support providers receive access?

Use targets limited to the business need, individual accounts, appropriate identity and device conditions, approved durations, and recorded access. Do not combine application support and infrastructure administration into the same access group. Access revocation should also be tested.

Will ZTNA work during an identity provider outage?

Behavior for new sign-ins and existing sessions depends on the product, cached state, and policy. Verify the outage scenario through vendor documentation and pilot testing. Controlled emergency administrative access can be planned; this does not mean opening unrestricted access for every user.

When is a ZTNA pilot successful?

It can be considered successful when approved users can complete their work, unnecessary access is blocked, and revocation and failure behavior meet the acceptance criteria. The report must identify the applications and user groups tested; one pilot is not automatic evidence for the entire organization.

Which items have the greatest effect on ZTNA cost?

Assess identity and device tools, application compatibility, connector resources, support, log retention, and transition-period operations alongside licensing. Read the current proposal together with the user and application inventory, rather than comparing only unit license prices.