Security topology · 01

Zero Trust Access

TOORCE SWG Agent is one Windows program for posture, login, the secure tunnel, and published applications. A user reaches a remote asset only through that agent. Sign-in is five checks, in order. The TOORCE Secure Tunnel is issued only after the last required check succeeds.

ZTA login

Posture, user login, MFA, device UUID, then biometric

Each step has to succeed before the next one starts. A failure stops the session. There is no tunnel, and no published application, until this login is finished.

1 Posture check
The agent scans the PC first: host firewall, antivirus, operating-system version, and privilege. A desktop with a ZTA profile cannot continue until that report matches the policy.
2 User login
SSO against Windows or the domain, or a username and password through local accounts, LDAP, RADIUS, or TACACS+.
3 MFA
When MFA is on, the one-time password is checked next. Mobile OTP and email OTP are the two methods. A wrong code is refused.
4 Device UUID
The machine UUID must match the UUID stored on that account. The same password on another PC fails. An account marked for any device is the only exception.
5 Biometric
When the profile requires biometric sign-in, the user confirms on that same device. The gateway sends a challenge, and the enrolled key for this user and this UUID signs it. A device that was never enrolled is refused.

ZTA login in order: posture check, user login, MFA, device UUID, biometric authentication, then the TOORCE Secure Tunnel — The login, left to right. Posture, then the person, then MFA, then the device UUID, then biometric authentication. The TOORCE Secure Tunnel is the result, not the start.

Controlled clients

TOORCE Browser, RDP, and SSH — nothing else

The published asset is opened by the TOORCE Browser, the TOORCE RDP client, or the TOORCE SSH client. Windows Remote Desktop, the system SSH command, and a normal browser such as Chrome or Edge are refused. They are not on the gateway’s client list, so they never receive the connection.

TOORCE Browser

Web applications and protected sites. In the managed policy the mode is locked to the TOORCE browser, other browsers are blocked, and the TOORCE extension is forced on.

TOORCE RDP client

Published Windows desktops and servers. Clipboard and file transfer exist only when the gateway turned them on for that connection.

TOORCE SSH client

Published shells. The proxy answers only the TOORCE client. A native SSH program is rejected before it can see the host.

TOORCE client showing an RDP session, a web session set to the TOORCE Browser, and an SSH session — Published sessions inside the TOORCE client. RDP opens with Connect, web opens in the TOORCE Browser, and SSH opens the TOORCE terminal. The list comes from the gateway. The user cannot add a session the administrator did not publish.

One agent, in this order

FortiClient, GlobalProtect, and a Sophos or Zscaler client are often a second or third program next to a VPN, a web filter, and a remote-desktop portal. TOORCE SWG Agent (product v1.2) keeps those jobs in one sidebar. The user learns one window. The gateway pushes one policy after login.

ZTA login. Posture check, then user login, then MFA, then device authentication with the machine UUID, then biometric authentication when the profile requires it. Remember me stores the gateway address for the next start. The tunnel waits until the required checks pass.
Connection. A TOORCE Secure Tunnel inside the same app. The profile can send all traffic through the tunnel, or only the routes and protected domains the gateway assigned.
Remote access. The assigned list: RDP in the TOORCE Remote Desktop client, SSH in the embedded terminal, web apps in the TOORCE Browser. Internet policy for general browsing is the Secure Web Gateway half of the same agent.

Protected domains

Internal names and addresses the gateway marks as protected are routed over the secure tunnel. The user does not add a PAC file or a manual route. Private applications stay on the encrypted path even when the rest of the internet is split out.

Always-on or manual

Setup chooses how the agent behaves after install. Manual means the user opens TOORCE SWG and signs in when they need access. Always-on starts with Windows, can sign in again from Remember me, and leaves the agent in the notification area when the window is closed. In Always-on, the login fields stay view-only until someone enters the gateway tamper password. Uninstall and the Program Files folder can require that same password or the uninstall PIN set at Setup.

Changed modules download from the TOORCE update service. A full reinstall is the fallback, not the usual path. The PC needs Windows 10 or 11, administrator rights for the first install, the Microsoft Edge WebView2 runtime, and a path to the gateway.

What the gateway controls

These clients do not keep their own policy. After sign-in they pull it from the appliance, so an administrator changes behavior for every user without touching the laptop.

Which asset, and which client

Each person receives only their own RDP, SSH, web, and remote-support connections on that pool. A connection they were not given does not appear.

File transfer and clipboard

On every published RDP or SSH connection the gateway sets file transfer and clipboard separately. A contractor can view a desktop with both switches off.

Browser extension and other browsers

The strict policy locks internet access to the TOORCE browser, forces the extension, and blocks every other browser. A relaxed profile is an explicit admin choice, not the default.

Uploads, downloads, and forms

The browser policy sets upload and download size, blocked extensions and filenames, DLP checks, a required download scan, and form fields or patterns that must be blocked.

Admin lock

A tamper password on the profile means the user cannot turn the control off. Disabling it requires the password the administrator set on the gateway.

Screen and sign-in

The same profile decides screenshots, screen watermarking, a required secure tunnel, and biometric sign-in, and the client applies those flags.

That is the business result: one place to allow a person onto a server, and one place to decide whether files, clipboard text, or a personal browser can leave with them. The security result is that the uncontrolled path — mstsc, OpenSSH, Chrome, Edge — is closed, because those programs cannot present themselves as a TOORCE client and cannot read the policy.

Flow from the user PC through a health scan and login to the gateway, then a tunnel or a published RDP, SSH, or browser session — The access flow. A failed scan or a native client stops on the left of the gateway. A healthy TOORCE agent continues to the tunnel, protected domains, or a published application.

The business problem

Most remote-access projects still start with a VPN. The user signs in, receives an address from a pool, and can reach whatever that subnet allows. A stolen password, a laptop with antivirus turned off, or a contractor who only needed one server all look the same once the tunnel is up.

FortiGate SSL-VPN and Palo Alto GlobalProtect are built around that model, then add posture (FortiClient tags, GlobalProtect HIP) and, on the larger licenses, a separate ZTNA or Prisma Access tier. The control often arrives as a second product, a second agent, and a second subscription. The network is still the thing being granted.

TOORCE keeps the decision on the appliance you already operate. Identity, one-time password, device health, web policy, and the list of published applications sit on one user profile. A user with no profile still gets a normal VPN. A user with a profile does not get a tunnel until the device matches the policy.

One agent instead of a stack

Fortinet (FortiGate and FortiClient), Palo Alto (GlobalProtect and Prisma Access), Sophos, and similar suites are strong products. A typical deployment still asks the user to run a VPN client, a posture agent, a web-filter agent, and a remote-access portal. TOORCE puts ZTA scan, tunnel, remote apps, and web policy in one Windows UI, driven by the gateway.

What the business needs	Typical multi-product stack	TOORCE SWG Agent
Stop a bad device before it is inside	Login succeeds first. Posture is often a follow-up check, a tag, or a HIP report after the agent is already talking to the gateway.	Desktop clients must send a health report first. If a required check is missing, failed, or does not match, the TOORCE Secure Tunnel is never delivered.
Give a person an application, not a subnet	ZTNA access proxies and Prisma Access connectors do this, usually as an extra cloud or fabric license on top of the firewall.	The ZTA Proxy publishes the asset only to the TOORCE RDP, SSH, or browser client. Native Remote Desktop, system SSH, and other browsers are refused. Clipboard, file transfer, and the browser extension are switches on the gateway.
One policy the operator can explain	VPN portal, endpoint profile, web filter, and ZTNA server are often separate objects in separate menus.	One ZTA/SWG profile carries device policy, protected domains, location policy, secure-tunnel requirement, watermark, biometric sign-in, and the web-filter profile.
Keep traditional VPN for the people who still need it	Moving to ZTNA often means a parallel access method and a migration project.	No profile assigned means VPN only: username, password, and OTP when MFA is on. Posture and application publishing stay off until you attach a profile.
Prove why someone was refused	Denied sessions are spread across VPN, endpoint, and ZTNA logs.	Every authentication is audited with a reason: bad credentials, bad OTP, missing health report, or the exact check that failed.

This compares a typical multi-product pattern with TOORCE’s single agent. It is not a claim that TOORCE leads on every metric. Fortinet, Palo Alto Networks, GlobalProtect, Prisma, Sophos, and the other names above are trademarks of their owners. Those platforms remain a strong fit when the buyer wants a large cloud point-of-presence network or a very large application library.

What the business gets

A refused laptop never joins the LAN

Required checks run before the tunnel file is delivered. A failed antivirus, host firewall, privilege, OS version, or hardware identity blocks the session.

A copied password is not enough

The account is bound to a device UUID. The same password from another machine fails that check. When biometric sign-in is on, the user must also confirm on the enrolled device.

Contractors see one system

The proxy returns only the connections assigned to that user on that pool. There is no route to the rest of the site.

Browsing policy travels with the person

The same profile that allowed the login also selects the Secure Web Gateway policy, so web control does not depend on which IP the VPN happened to assign.

Sensitive screens stay marked

The profile can require a secure tunnel, turn on screen watermarking, and control screenshots, so a published desktop is harder to walk out of the building on a phone camera.

You can still say yes to a plain VPN

Staff who only need network access stay on credentials and OTP. You turn on zero trust per person, not as a flag day for the whole company.

How it works

The agent runs the posture check first, then calls /auth. The service accepts the user login only when the password and the device UUID match the account. MFA is the one-time password after that, mobile or email. When the profile requires biometric sign-in, the device signs a gateway challenge with the key enrolled for that username and that UUID. A desktop profile still has to present a matching posture report before the TOORCE Secure Tunnel is sent.

TOORCE VPN Desktop login with server, username, and password — User login in the TOORCE agent. The device UUID of this machine is part of the sign-in. MFA follows when the account requires a one-time password.

ZTA scan showing antivirus, OS version, UAC, and hardware ID all passing — The scan the gateway requires before a desktop profile is allowed: antivirus, operating-system version, user-account control, and hardware ID.

TOORCE agent secure tunnel page before the user connects — The tunnel is a step inside the same agent, after the scan and the login. Remote sessions stay on the Remote access page of this client.

No profile — VPN only. If the user has no ZTA/SWG profile, posture is skipped and the service returns the TOORCE Secure Tunnel after the password and OTP succeed.
Desktop with a profile — health first. The client must already have run the device scan. The service compares that report with the policy stored for the user. Each required item must be present, must pass, and must match the expected value. A star in the expected value is a wildcard, so an OS string can match a family of builds without listing every one.
Checks the policy can require. Host firewall, antivirus, operating-system version, user-account control / privilege, and hardware identity. A missing item, a failed check, or a value that does not match is returned to the client. The tunnel file is not.
Application access is a TOORCE client only. ZTA Proxy listens per access pool. It accepts the TOORCE proxy client, checks the account, and checks that the user belongs to that pool. The answer is that user’s RDP, SSH, web, or remote-support list, with clipboard and file transfer set per connection. A native client never gets that list. For the browser, the policy can lock the mode to the TOORCE browser, force the extension, and block every other browser.

Mobile clients skip the desktop health comparison. Location policy, protected domains, biometric sign-in, and the web-filter profile are all fields on the same ZTA/SWG profile, so the operator changes one object when a role changes. A refusal is recorded with a reason, and a live session can be disconnected from the gateway.

Configure it

Step-by-step screens for pools, users, and SSL/ZTA access are in the Firewall administrator guide.

Open the ZTA / SSL Access guide