Replace Broad VPN Access with Zero Trust

Remote access should give people the resources they need—not unnecessary access to the network around them.

ZTXGate replaces broad remote-access VPN connectivity with identity-, device-, and resource-aware access policies. Instead of deciding whether someone may simply connect to a private network, ZTXGate evaluates whether that user, on that device, under the current conditions, should be allowed to reach a specific resource.

Why Organizations Look Beyond Traditional Remote-Access VPNs​

VPN technology remains useful and can be deployed securely.

The challenge is that traditional remote-access VPN architectures typically establish network connectivity first. Organizations then use routes, firewall rules, segmentation, identity systems, endpoint controls, and other mechanisms to limit what a connected endpoint is allowed to reach.

ZTNA approaches the problem from the other direction:

Should this user, using this device, be allowed to access this resource right now?

ZTXGate is built around that decision.

Network Connectivity vs Resource Access​

A remote-access VPN commonly gives an endpoint connectivity into a private network and then depends on surrounding controls to limit that connectivity.

ZTXGate focuses access on explicitly defined resources. Developers can reach development systems without receiving broad production-network access, contractors can receive access only to systems required for their engagement, and administrators can receive temporary access to sensitive resources when approved.

VPN vs ZTXGate​

Modern VPN deployments can implement many of these capabilities through additional systems. The difference is that ZTXGate makes identity-, device-, resource-, and policy-aware authorization the core access model.

Explore the ZTNA architecture

Reduce Access Scope​

ZTXGate lets administrators define exactly which resources should be available to a user or role. A policy can consider user identity, role, enrolled device, device posture, network location, time, protected resource, and access duration.

Everything outside the defined policy remains unavailable through ZTXGate.

Give Temporary Access a Defined End​

ZTXGate supports temporary and request-and-approve access for resources where standing access is unnecessary.

A user can request access to a protected resource, an authorized approver can grant an appropriate access window, and the permission expires automatically when that window closes.

Make Device Identity Part of Access​

ZTXGate enrolls devices individually. A user's laptop, phone, tablet, or other enrolled endpoints can be tracked separately and used as part of policy decisions.

If one device is lost, retired, or no longer trusted, it can be revoked without disabling the user's other devices.

Use the Identity Systems You Already Have​

ZTXGate supports OIDC authentication and SCIM provisioning so replacing remote-access VPN connectivity does not require creating another isolated identity lifecycle.

Add Stronger Verification Where It Matters​

ZTXGate can require supported step-up authentication methods for sensitive resources, including ZTXBAS biometric approval, Okta Verify Push, and Duo Push.

Keep Access Visible​

ZTXGate centralizes access, authentication, and policy records. Events can also be forwarded to existing monitoring infrastructure using syslog, CEF, or JSON.

Move at Your Own Pace​

Replacing an existing remote-access model does not need to be an all-or-nothing migration.

A practical rollout can begin with a small user group, a limited set of resources, clearly defined access policies, and device enrollment. Existing access mechanisms can remain in place during a staged transition.

A Practical Pilot​

A focused evaluation might begin with one team and a few applications:

• Users: Development team
• Resources: Development servers and internal tools
• Policy: Enrolled devices only
• Sensitive resource: Production administration
• Additional requirement: Request-and-approve access with step-up authentication

This lets an organization evaluate the ZTNA model without redesigning the entire network first.

Frequently Asked Questions​

Does ZTXGate make VPN technology obsolete?​

No. VPN technology remains appropriate for many network-connectivity use cases. ZTXGate addresses a different access model: authorizing users and devices to reach defined resources according to policy.

Do we have to remove our current VPN immediately?​

No. A migration can begin with a subset of users and resources while existing access methods remain in place.

Can ZTXGate work with our existing identity provider?​

ZTXGate supports OIDC authentication and SCIM provisioning for integration with compatible identity systems.

Can access expire automatically?​

Yes. Policies can support temporary access and request-and-approve workflows with defined access windows.

Does ZTXGate require a CoreZT cloud service?​

Core ZTXGate access operation does not require a mandatory CoreZT-hosted cloud control plane. Third-party integrations naturally retain their own connectivity requirements.

For browser-only private applications and third-party users, see Clientless ZTNA and Contractor Access.

Start With a Focused Deployment​

Choose a small set of users and resources, apply the policies you want to evaluate, and expand from there.

Explore ZTXGate · ZTNA vs VPN · How ZTNA Works · Explore self-hosted ZTNA · Explore Security & Trust