ZTXGate vs Zscaler Private Access

ZTXGate and Zscaler Private Access (ZPA) both provide policy-driven access to private applications without treating network location alone as authorization.

The important difference is how they approach deployment independence: Zscaler uses a cloud-centric architecture with on-premises Private Service Edge and Business Continuity options, while ZTXGate can use a standalone customer- or MSP-operated deployment as its normal operating model, including permanent air-gapped environments.

At a Glance​

This comparison focuses on deployment architecture and operating model rather than treating either product as a simple checklist of ZTNA features.

Cloud-Centric and Standalone-Capable Architectures​

ZPA normally uses Zscaler's cloud platform together with components deployed in or near the customer's private environment. Zscaler App Connectors establish outbound connections, and ZPA policy and service infrastructure broker private-application access.

Zscaler also provides ZPA Private Service Edge and Private Cloud Controller capabilities for local access, regulatory requirements, and business continuity.

ZTXGate can instead operate standalone as a customer- or MSP-operated access platform. A CoreZT-hosted control service is not mandatory for policy, access enforcement, audit, or integrated ZTXBAS authentication.

Connected ZTXGate deployments can optionally use CoreZT-operated ZTXHub for centralized software-update and license management.

Explore the ZTXGate control-plane model

On-Premises Access​

Both products have meaningful on-premises stories.

Zscaler explicitly documents Private Service Edge for local ZTNA so in-office users can reach private applications without unnecessarily hairpinning traffic through a public broker. Its material also positions the design for environments with regulatory restrictions or unreliable external connectivity.

ZTXGate can be deployed directly in customer- or MSP-operated infrastructure on-premises and use the same access model for local and remote users.

Therefore, “on-premises support” itself is not the differentiator. The meaningful distinction is whether on-premises operation is part of a cloud-synchronized service architecture or can be the product's permanent standalone operating model.

Explore On-Premises ZTNA

Business Continuity vs Permanent Disconnection​

Zscaler documents a Business Continuity architecture in which the Private Cloud Controller normally synchronizes authentication, configuration, and policy information with the Zscaler Zero Trust Exchange. When an outage is detected, the environment can switch into Business Continuity Mode and later return to normal operation when cloud connectivity is restored.

That is substantial outage resilience and should not be described as “ZPA stops working without the Internet.”

ZTXGate's air-gapped model answers a different requirement. A standalone deployment can operate indefinitely without an expected reconnection to a CoreZT-hosted control service. Software updates and license management can remain manual when ZTXHub is omitted.

Explore Air-Gapped ZTNA

Clientless Access​

ZPA Browser Access supports clientless HTTP and HTTPS access and is commonly positioned for users such as contractors and unmanaged endpoints.

ZTXGate also provides licensed clientless access for supported HTTP and HTTPS applications through its policy-enforcing proxy.

Clientless web access is therefore a shared capability rather than a unique ZTXGate differentiator.

The architectural question is where the clientless access and policy service runs and what dependencies are acceptable for the deployment.

Explore Clientless ZTNA

Identity and MFA​

ZPA integrates identity and authentication into its broader ZPA service architecture.

ZTXGate supports connected identity and authentication integrations, and when licensed, tightly integrates ZTXBAS phishing-resistant biometric authentication as a library rather than requiring a separately deployed ZTXBAS server.

The largest distinction appears when the environment is intentionally disconnected rather than merely experiencing a temporary outage.

Authentication When the Cloud Is Unreachable​

ZTXGate​

In a fully air-gapped standalone ZTXGate deployment, licensed integrated ZTXBAS remains available for phishing-resistant biometric authentication inside the isolated environment.

This authentication path does not require an external cloud MFA service or a CoreZT-hosted authentication service. When ZTXHub is not used, license management and software updates can also be handled manually.

Zscaler Private Access​

Zscaler documents a setting named Max Age for Authentication with Private Service Edge. When a Private Service Edge cannot communicate with the ZPA cloud during a network outage, an existing user's authentication can be extended for a configurable period based on the last authentication. Current documentation states a maximum of seven days and identifies the feature as limited availability.

That is a useful business-continuity mechanism, but it is not equivalent to a permanently disconnected authentication architecture. It extends previously established authentication during an outage rather than documenting indefinite new authentication entirely independent of the Zscaler cloud.

The defensible comparison is therefore:

• ZPA: cloud-oriented authentication with documented outage-continuity mechanisms.
• ZTXGate + licensed ZTXBAS: phishing-resistant biometric authentication designed to remain available as part of a permanently air-gapped ZTXGate deployment.

Device and Context Controls​

Zscaler has broad enterprise policy and contextual-access capabilities across its platform.

ZTXGate can combine identity, enrolled device, posture, network location, time, resource, approval state, and other policy inputs. Supported posture integrations include:

• Microsoft Intune
• Microsoft Defender for Endpoint
• SentinelOne Singularity
• CrowdStrike
• Jamf

An organization choosing between the products should evaluate the exact endpoint platforms, posture signals, and policy conditions it needs rather than reducing device trust to a yes/no feature row.

Availability and Disaster Recovery​

Zscaler's architecture includes vendor-operated service resilience and customer-deployed components for local connectivity and Business Continuity.

ZTXGate does not currently provide conventional clustered HA. Administrators can configure periodic backups in the portal and restore a backup into a fresh ZTXGate deployment after a disaster.

Those are materially different resilience strategies.

Which Architecture May Fit Better?​

Zscaler Private Access may fit well when:

• a large cloud-delivered enterprise security platform is desired
• the Zscaler cloud operating model is acceptable or preferred
• extensive enterprise integrations and platform capabilities are required
• local Private Service Edge and temporary cloud-outage continuity satisfy the resilience requirement
• the organization wants vendor-operated service scale rather than operating the ZTNA control environment itself

ZTXGate may fit well when:

• the access platform should be customer- or MSP-operated
• permanent standalone or air-gapped operation is a normal requirement rather than only an outage scenario
• phishing-resistant biometric authentication must remain available inside the air-gapped environment
• a mandatory vendor-hosted control plane is undesirable
• WireGuard-based managed access and licensed clientless HTTP/HTTPS access are both useful
• backup/restore disaster recovery is acceptable instead of conventional HA clustering

This is not an overall ranking. Zscaler and ZTXGate intentionally target different operating models and organizational requirements.

Official Sources Used​

Zscaler facts on this page were verified against current first-party material:

• ZTNA for On-Premises Users
• Configuring Authentication Settings
• About Browser Access

Explore ZTXGate · Start Free Trial