ZTA Access Policy

Navigation: Scenarios → ZTA Access Policy

Configure ZTA access so a remote user can connect with the TOORCE ZTA Agent, pass device posture checks, complete login and MFA, and then access only the allowed assets pushed by the user’s ZTA Access Policy.

This scenario focuses on the difference between normal SSL VPN routing and enforced ZTA access:

Design overview

The TOORCE ZTA Agent performs a posture scan, logs in to the SSL/ZTA gateway, connects the tunnel, and then pulls the allowed asset list from the gateway. The asset list controls what the user sees in Remote access: RDP, Web, and SSH entries.

Figure 1 — ZTA posture scan checks antivirus, OS version, UAC, and device hardware ID

Example access policy

Prerequisites

• ZTA/SSL Access profile exists
• SSL VPN listen rule and VPN-to-LAN rule are configured, as shown in SSL VPN Multi-Pool
• Local user or AD user exists
• TOORCE ZTA Agent installed on the endpoint
• Firewall can reach the target assets on the configured ports

Step 1 — Create or edit the user

Go to User Management or Auth & Users and edit the user who will connect with the TOORCE ZTA Agent.

If the user is restricted to device IDs, only endpoints whose TOORCE ZTA Agent reports a matching HWID can log in with that username and password.

MFA behavior

For remote access users, enable MFA unless there is a documented exception.

Step 2 — Add allowed assets under the user ZTA access policy

Open the user’s ZTA Access Policy and add every asset the user is allowed to open from the TOORCE Agent.

Asset examples

Figure 2 — ZTA access policy pushed to the agent after tunnel login

Access method options

Use TOORCE-controlled methods when possible. They keep access inside the managed ZTA workflow and avoid exposing native clients directly to the internal network.

Step 3 — Configure temporary password behavior for target assets

For sensitive RDP/SSH assets, enable temporary password mode.

Recommended defaults:

Temporary password mode requires the TOORCE Agent or helper service on the target asset so it can create and remove the temporary account at session start/end.

Step 4 — Enable Enforce ZTA Access on the SSL/ZTA profile

Go to VPN Tunnels → ZTA/SSL Access and edit the profile used by the user.

Why Enforce ZTA Access matters

If Enforce ZTA Access is disabled, the VPN behaves like a broader SSL VPN: after login, the user can route to whatever the pushed routes and firewall rules allow. If Enforce ZTA Access is enabled, the TOORCE Agent uses the policy asset list and only exposes those exact IP/port entries.

Step 5 — User workflow in TOORCE ZTA Agent

1. Run posture scan

The user opens TOORCE VPN Desktop and starts ZTA Scan. The agent checks endpoint posture:

The bottom bar shows the full hardware UUID/HWID. Add this ID to the user if device binding is required.

2. Login

The user enters:

If MFA is enabled, the user completes OTP after username/password.

3. Connect tunnel

After successful posture and login, the user opens Connection and clicks Connect.

4. Open allowed remote sessions

After the tunnel is up, the Remote access page fetches the allowed sessions from the gateway endpoint. The user cannot add, edit, or delete entries while connected.

Step 6 — Inline firewall rules

Use the same two-rule model from SSL VPN Multi-Pool:

For strict ZTA deployments, Rule 2 should allow only the assets listed in the ZTA policy:

This prevents policy bypass if a user tries to reach another host directly.

Verification

Check logs:

• Logs & Events → SSL/ZTA Logs
• Logs & Events → ZTA Connected Clients
• Logs & Events → Firewall Security

Troubleshooting

Related documentation

• ZTA/SSL Access
• SSL VPN Multi-Pool
• Local Users/Groups
• Inline Rules
• SSL/ZTA Logs