Self-Hosted vs Cloud-Delivered ZTNA
“Cloud ZTNA” and “self-hosted ZTNA” sound like two simple categories. In practice, the market contains several architectural models between those endpoints.
The most useful question is not simply where a product runs. It is:
Who operates the control plane, where does application traffic flow, and what remains functional when external services are unavailable?
This guide compares the major operating models without assuming that one is universally better.
Four Common Operating Models
1. Cloud-Delivered ZTNA
The vendor operates the management, policy, and access service as a cloud platform.
This can reduce infrastructure work for the customer and provide vendor-managed availability and geographic reach.
2. Vendor Control Plane + Customer Connectors
The vendor operates central coordination and policy services, while the customer deploys connectors, gateways, or service edges near private applications.
Application traffic may flow through customer components, vendor service edges, direct peer paths, or some combination depending on the product.
3. Self-Hosted ZTNA
The customer or MSP operates the product's control and enforcement infrastructure.
This provides greater deployment control, but the operator also owns more maintenance, backup, availability, and monitoring responsibility.
4. Standalone / Disconnected ZTNA
The access platform can operate without a mandatory vendor-hosted control service.
This is the relevant model for permanently isolated, highly restricted, or fully air-gapped environments.
Control Plane Ownership
The control plane typically handles configuration, identities, resource definitions, policy, authorization, and administrative workflows.
In a cloud-delivered service, the vendor operates that layer.
In a self-hosted system, the customer or MSP operates it.
Neither is automatically more secure. They create different trust boundaries and operational responsibilities.
Questions to ask include:
- who can administer the control service?
- where is configuration stored?
- what external services are required for policy decisions?
- can administrators continue working during an Internet outage?
- what is the vendor responsible for versus the customer or MSP?
Data Path
Control-plane location does not necessarily tell you where application traffic flows.
A cloud-managed ZTNA product may still keep application traffic directly between customer-controlled components. Another may route traffic through vendor service edges. A self-hosted platform may proxy or gateway traffic through infrastructure the customer operates.
When evaluating products, ask separately:
- Where are policy decisions coordinated?
- Where does application traffic actually travel?
Internet Dependency
A connected service can offer excellent availability while still depending on access to the vendor's cloud for management, new authorizations, authentication coordination, or other functions.
That may be acceptable—or desirable—for normal enterprise deployments.
Disconnected environments need a different answer.
Ask what happens when:
- Internet connectivity disappears for minutes or hours
- the vendor control service is unreachable
- an external identity provider is unreachable
- an MDM/EDR service is unreachable
- the network is intentionally isolated indefinitely
“Works during a temporary outage” is not necessarily the same as “can operate permanently air-gapped.”
Identity and Authentication
Cloud-delivered ZTNA commonly integrates with cloud identity providers. Self-hosted products may support external identity providers, local users, or both.
An air-gapped design must use identity and authentication methods available inside the disconnected environment.
This distinction applies to MFA as well. A cloud push service cannot complete an authentication transaction if the deployment cannot reach that service.
Updates and Licensing
Cloud-delivered products generally make software lifecycle management largely the vendor's responsibility.
Self-hosted products need an update model. That may include automated repositories, managed update services, or manual packages.
Disconnected environments need a controlled offline process for updates and licensing if those functions would otherwise depend on external connectivity.
Availability and Disaster Recovery
Cloud services normally provide vendor-managed redundancy as part of the service.
Self-hosting transfers more responsibility to the operator. Products may support clustering, active/passive designs, distributed components, or backup-and-restore recovery instead.
These are not equivalent.
A buyer should ask for the exact model rather than accepting “high availability” or “resilience” as generic labels.
Operational Responsibility
| Area | Cloud-Delivered | Self-Hosted / Customer- or MSP-Operated |
|---|---|---|
| Control-plane infrastructure | Vendor | Customer or MSP |
| Platform patching | Primarily vendor | Customer/MSP according to vendor process |
| Scaling | Primarily vendor | Customer/MSP |
| Backups | Primarily vendor service responsibility | Customer/MSP |
| Monitoring platform availability | Vendor + customer integration | Customer/MSP |
| Internet dependency | Product dependent, commonly significant | Product dependent; may be avoidable |
| Air-gap suitability | Product dependent | Possible if architecture supports it |
The self-hosted model provides more control but also more responsibility.
Compliance and Data-Control Requirements
Some organizations prefer cloud delivery because the vendor can operate a standardized, globally available platform.
Others need infrastructure to remain within defined operational boundaries because of:
- isolated networks
- internal architecture policy
- regulated environments
- customer contractual requirements
- data-location or dependency constraints
The correct decision depends on actual requirements, not on a generic claim that cloud or self-hosting is always superior.
Example Market Models
The current ZTNA market demonstrates the range of possibilities:
- some products use a vendor-hosted controller with customer connectors
- some offer cloud-hosted and true self-hosted editions
- some manage the control plane as SaaS while open-sourcing customer-side components
- some provide local continuity components while synchronizing with a cloud service during normal operation
That variety is why architectural evaluation matters.
Where ZTXGate Fits
ZTXGate is designed to run in infrastructure operated by the customer or an MSP.
Core access operation does not require a mandatory CoreZT-hosted cloud control plane.
Standalone ZTXGate
- customer- or MSP-operated
- can remain fully air-gapped
- license management is manual
- software updates are manual
- integrated ZTXBAS can operate within the disconnected ZTXGate environment when licensed
ZTXGate with Optional ZTXHub
- ZTXGate remains customer- or MSP-operated
- ZTXHub is owned and operated by CoreZT
- ZTXHub provides centralized software-update management
- ZTXHub provides centralized license management
- the service is optional rather than required for core access operation
Resilience Model
ZTXGate does not currently provide conventional HA clustering. Administrators can configure periodic backups and restore a backup into a fresh deployment when disaster recovery is required.
That is a backup-and-restore DR model, not automatic failover.
Explore Self-Hosted ZTNA · No Mandatory Cloud Control Plane
Questions to Ask Any ZTNA Vendor
Before choosing an architecture, ask:
- Who operates the control plane?
- Where does traffic flow?
- What customer-side components are required?
- What happens when the vendor cloud is unavailable?
- Can the system operate permanently disconnected?
- Which identity and posture functions depend on external services?
- How are updates delivered?
- How is licensing handled in disconnected environments?
- What is the actual availability model?
- Who owns backups and disaster recovery?
- Which functions require endpoint software?
- What responsibilities remain with the customer or MSP?
Those answers usually reveal more about the operating model than the label “ZTNA.”