How ZTXGate Zero Trust Network Access Works
Zero Trust Network Access is not simply an encrypted tunnel or a different way to connect to a private network.
The important architectural change is that access is explicitly authorized around the user, device, protected resource, and current policy conditions.
ZTXGate brings those decisions together in an access platform that can be operated by the customer or an MSP, on-premises, in cloud infrastructure, across hybrid environments, or in fully air-gapped networks.
The ZTNA Decision
A useful way to think about Zero Trust access is as a repeated authorization question:
Should this user, on this device, be allowed to reach this resource under the current conditions?
ZTXGate can use policy signals such as:
- user identity
- user role
- enrolled device
- device posture
- network location
- time
- protected resource
- access duration
- approval state
- step-up authentication requirements
Network connectivity by itself is not treated as sufficient authorization.
ZTXGate Architecture at a Glance
This is a logical architecture. The blocks describe security responsibilities rather than a one-to-one mapping to individual software processes.
Identity: Who Is Requesting Access?
ZTXGate can integrate with an existing identity environment instead of relying only on a local username database.
OIDC can provide authentication and identity claims, while SCIM can synchronize user lifecycle information from supported identity systems.
Identity becomes one input into policy rather than a one-time gate that automatically grants broad network access.
Explore Identity & Device Trust
Device: Which Endpoint Is Requesting Access?
A user and a device are related, but they are not the same identity.
ZTXGate enrolls user devices individually so a laptop, phone, tablet, or other endpoint can be represented separately in policy.
If one endpoint is lost, retired, or no longer trusted, it can be revoked without necessarily disabling the user's other devices.
Where connected posture services are available, ZTXGate can also use signals from supported platforms including:
- Microsoft Intune
- Microsoft Defender for Endpoint
- SentinelOne Singularity
- CrowdStrike
- Jamf
Policy: What May This User and Device Reach?
ZTXGate policy is centered on defined resources rather than treating access to the surrounding network as the permission itself.
A developer can be authorized for development systems while production remains unavailable. A contractor can be granted one application for a limited time. An administrator can be required to request approval and complete additional authentication before reaching a sensitive resource.
Policy can support both standing and temporary access models.
Managed Access: WireGuard for Secure Transport
Managed endpoints use WireGuard-based connectivity for authorized network access through ZTXGate.
WireGuard provides the secure transport. ZTXGate adds the identity, device, resource, lifecycle, approval, posture, and audit context required to turn that transport into a policy-driven access system.
The existence of a WireGuard tunnel is therefore not the access policy.
Clientless Access: HTTP/HTTPS Through the Proxy
Not every protected application requires endpoint tunnel software.
For supported HTTP and HTTPS applications, ZTXGate can provide clientless access through its policy-enforcing proxy. The proxy terminates the incoming connection and establishes the authorized connection to the protected application.
Because the proxy operates at the HTTP layer, it can apply application-aware policy where the implemented policy model supports it.
Clientless access is particularly useful for browser-based applications, contractors, third parties, and endpoints where installing connectivity software is undesirable.
Continuous Policy Enforcement
An access decision should not remain valid simply because a connection was previously allowed.
ZTXGate can continue evaluating relevant conditions after access begins. If an access window closes, a role changes, or a posture condition no longer satisfies policy, access can be revoked according to the configured policy.
This makes policy responsive to changing conditions rather than only the state that existed at login time.
Step-Up Authentication
Sensitive resources can require additional verification according to policy.
When ZTXBAS is licensed with ZTXGate, it is tightly integrated as a library and does not require administrators to deploy a separate ZTXBAS service. This integrated phishing-resistant biometric authentication path works across connected and air-gapped ZTXGate deployment models.
Connected deployments can also use supported cloud-dependent authentication services such as Okta Verify and Duo when those services are reachable.
Standalone ZTXBAS is a separate free product for developers who want to integrate biometric authentication directly into their own applications.
Audit and Security Visibility
Access decisions should be observable.
ZTXGate records access, authentication, and policy activity so administrators can investigate what happened and export relevant evidence when needed.
Events can also be forwarded to supported monitoring environments using syslog, CEF, or JSON.
Audit visibility does not replace a SIEM or broader security monitoring program; it gives those systems access context that would otherwise be scattered across multiple components.
External Integrations Are Policy Inputs, Not Core Dependencies
A ZTXGate deployment can use external identity, device posture, authentication, and monitoring platforms where those services are reachable.
Examples include:
- OIDC identity providers
- SCIM identity provisioning
- Microsoft Intune
- Microsoft Defender for Endpoint
- SentinelOne Singularity
- CrowdStrike
- Jamf
- Okta Verify
- Duo
- SIEM platforms
These integrations extend the context available to policy and operations. They are not required for every deployment model.
In a fully air-gapped environment, ZTXGate uses the identity, authentication, device, and monitoring capabilities available inside that environment.
Deployment and Control-Plane Model
ZTXGate can operate standalone without a mandatory CoreZT-hosted cloud control plane.
The ZTXGate deployment itself can be operated by the customer or by an MSP.
A standalone deployment can remain fully air-gapped, with licensing and software updates handled manually.
For connected deployments that want centralized license and software update management, CoreZT operates the optional ZTXHub service. ZTXHub is not required for core ZTXGate access operation.
Explore the Control-Plane Model
Backup and Disaster Recovery
ZTXGate does not currently use a conventional clustered high-availability architecture.
Administrators can configure periodic backups through the portal. A backup can be restored into a fresh ZTXGate deployment when disaster recovery is required.
This is a backup-and-restore recovery model rather than active/active or active/passive clustering.
What ZTNA Does Not Replace
ZTNA is one layer in a broader security architecture.
It does not eliminate the need for:
- secure application design
- operating-system hardening
- local network controls and segmentation
- endpoint protection
- certificate and key management
- vulnerability management
- monitoring and incident response
- backups and disaster recovery
ZTXGate reduces unnecessary access scope and makes access decisions more explicit. It does not make the rest of the security stack unnecessary.