Zero Trust Access Without a Mandatory Cloud Control Plane
ZTXGate does not require a mandatory CoreZT-hosted cloud control plane for core access operation.
The ZTXGate deployment can be operated by the customer or by an MSP. It can run standalone, remain fully air-gapped, or optionally connect to the CoreZT-operated ZTXHub service for centralized software update and license management.
The operating model is a deployment choice rather than a prerequisite for using the product.
What “No Mandatory Cloud Control Plane” Means
The statement does not mean ZTXGate has no administration or policy-control functions.
It means that core ZTXGate access operation does not require those functions to be hosted in a CoreZT cloud service.
The gateway, administration, policy, and access-enforcement environment runs in the infrastructure selected for the ZTXGate deployment.
That infrastructure can be operated by the customer or an MSP.
Standalone ZTXGate
A standalone ZTXGate deployment operates independently of ZTXHub.
This model can be used in connected environments or in networks that are intentionally isolated.
In standalone mode:
- core access operation remains local to the deployment
- license management is handled manually
- software updates are handled manually
- external identity and security integrations are optional and depend on whether those services are reachable
A standalone deployment therefore does not need to become Internet-connected simply for ZTXGate to enforce access policy.
Fully Air-Gapped Operation
A ZTXGate deployment can remain fully air-gapped.
In that model:
- ZTXHub is not used
- licensing is handled through the supported manual workflow
- software updates are handled through the supported manual workflow
- licensed integrated ZTXBAS remains available for phishing-resistant biometric authentication
- Internet-hosted identity, posture, SIEM, or authentication services are unavailable unless the environment intentionally provides connectivity to them
The air gap remains part of the customer's or MSP's security architecture rather than something ZTXGate silently bypasses.
Optional ZTXHub
ZTXHub is an optional service owned and operated by CoreZT.
Connected ZTXGate deployments can use ZTXHub for centralized functions including:
- software update management
- license management
ZTXHub is not required for core ZTXGate access operation.
Organizations that do not want a CoreZT-operated central service can run standalone and use manual licensing and software update workflows instead.
What Changes When ZTXHub Is Used?
The ZTXGate deployment itself remains in the customer's or MSP's operating environment.
ZTXHub adds centralized lifecycle-management functions for connected deployments; it does not turn the ZTXGate gateway into a CoreZT-hosted service.
| Operating model | Standalone ZTXGate | ZTXGate with optional ZTXHub |
|---|---|---|
| ZTXGate deployment operator | Customer or MSP | Customer or MSP |
| Core access enforcement | Local to ZTXGate deployment | Local to ZTXGate deployment |
| Mandatory CoreZT cloud dependency for access | No | No |
| License management | Manual | Centralized through CoreZT-operated ZTXHub |
| Software update management | Manual | Centralized through CoreZT-operated ZTXHub |
| Fully air-gapped operation | Yes | No, because ZTXHub requires connectivity |
Integrated ZTXBAS Across Both Models
When licensed with ZTXGate, ZTXBAS is tightly integrated as a library and does not require a separate ZTXBAS server deployment.
That integrated authentication capability works across ZTXGate deployment models, including fully air-gapped standalone deployments.
Connected environments can additionally use cloud-dependent options such as Okta Verify or Duo when those services are reachable.
Standalone ZTXBAS remains a separate free product for developers integrating biometric authentication into their own applications.
External Integrations Remain External Dependencies
“No mandatory CoreZT cloud control plane” should not be confused with “nothing can ever depend on an external service.”
A connected ZTXGate deployment may intentionally integrate with external systems such as:
- OIDC identity providers
- SCIM provisioning services
- Microsoft Intune
- Microsoft Defender for Endpoint
- SentinelOne Singularity
- CrowdStrike
- Jamf
- Okta Verify
- Duo
- cloud-hosted SIEM platforms
If such a service is part of policy or operations, that specific integration naturally requires the service to be reachable.
ZTXGate's core access platform and those optional integrations are separate dependency decisions.
Customer-Operated or MSP-Operated
Self-hosted does not necessarily mean every organization must operate ZTXGate with its own internal team.
A customer can operate its own deployment, or an MSP can operate the deployment on the customer's behalf according to the chosen service model.
In either case, the ZTXGate access platform runs in the selected deployment environment rather than requiring CoreZT to host the core gateway/control plane as a SaaS service.
Backup and Disaster Recovery
ZTXGate does not currently provide conventional active/active or active/passive high-availability clustering.
Instead, administrators can configure periodic backups through the portal.
If recovery is required, a backup can be restored into a fresh ZTXGate deployment to recreate the working configuration.
This is a backup-and-restore disaster recovery model, not automatic failover.
The site therefore does not claim:
- zero-downtime failover
- active/active clustering
- active/passive clustering
- a guaranteed recovery-time objective
Organizations should incorporate ZTXGate backup and restoration into their broader disaster-recovery planning.
Choosing an Operating Model
Choose Standalone ZTXGate When
- the deployment must remain air-gapped
- manual licensing and software updates are acceptable
- the organization does not want to use a CoreZT-operated central service
- local operational independence is a priority
Add ZTXHub When
- the deployment is connected
- centralized software update management is useful
- centralized license management is useful
- the organization is comfortable using the optional CoreZT-operated service
Neither model changes the basic ZTXGate policy architecture.
Frequently Asked Questions
Does ZTXGate stop working if ZTXHub is unavailable?
Core ZTXGate access operation does not require ZTXHub. ZTXHub is an optional centralized management service.
Is ZTXHub deployed by the customer?
No. ZTXHub is owned and operated by CoreZT.
Can an MSP operate ZTXGate?
Yes. A ZTXGate deployment can be operated by the customer or by an MSP.
Can ZTXGate remain completely air-gapped?
Yes. A standalone deployment can remain air-gapped and use manual license and software update workflows.
Does ZTXBAS require Internet access in an air-gapped deployment?
The integrated ZTXBAS capability inside ZTXGate can operate in an air-gapped deployment and does not require a separately deployed ZTXBAS server.
Does ZTXGate provide high availability?
Not in the conventional clustering sense. ZTXGate uses periodic backups and restore-to-fresh-deployment for disaster recovery.
Control the Dependency Model
ZTXGate lets organizations choose whether core access operates fully standalone or uses optional centralized services where they add operational value.
Compare Control-Plane Models
For current vendor architecture comparisons, see ZTXGate vs Cloudflare Access, ZTXGate vs Zscaler Private Access, and ZTXGate vs Tailscale.