Remote Zero Trust Access is how you let an engineer, vendor, or on-call operator reach a protected enclave from outside your site. Instead of a full-tunnel VPN that drops the user onto the corporate network, Access Gate binds the remote device to a Tailscale overlay and only exposes the enclaves that the user's identity is allowed to reach.
Why This Is Different From a VPN
A traditional VPN terminates on a corporate gateway and puts the remote machine on a broad subnet. Lateral movement risk is high, and access review is a periodic exercise.
Remote ZT Access works differently:
| Aspect | Traditional VPN | Remote ZT Access |
|---|---|---|
| Reachable surface | Whole network once connected | Only enclaves the user's role allows |
| Authentication | Gateway credential (often shared) | Per-user identity via your IdP |
| Network presence | User IP on the corporate LAN | Overlay IP isolated from the LAN |
| Policy model | Firewall rules by IP | ACLs by user / group |
| Revocation | Disable VPN account (global) | Remove user from enclave / group (per-resource) |
The overlay is provided by the built-in Tailscale client — see Virtual Private Network for the integration details.
What the User Experience Looks Like
- The remote user installs Tailscale on their device (or it's pre-installed by IT).
- They log into Tailscale using your existing Identity Provider (OIDC / SAML).
- They reach the enclaves mapped to their role — at the overlay IPs Access Gate publishes. Systems not mapped to their role are invisible.
- When the user leaves the group (or their role expires), the overlay route drops.
No static VPN config. No per-site gateway login. No standing route onto the production network.
How It Fits With Enclaves
Each enclave you enable for remote access gets an overlay endpoint. Access Gate advertises the endpoint to Tailscale devices whose user identity is on the enclave's ACL. The actual protocol the user speaks to the asset (HTTPS, Modbus, a database wire protocol) is unchanged — Access Gate just gates the path.
For administrative sessions — RDP, SSH, VNC, with session recording — see Privileged Access Management. That path goes through a browser-based proxy instead of the overlay and adds per-session audit controls.
Setting It Up
1. Connect Tailscale to your IdP
- In Tailscale admin, bind your SSO provider (Entra ID, Okta, Google Workspace).
- Create Tailscale groups that mirror the IdP groups you already use for access decisions (
ot-engineers,remote-vendors).
Access Gate reads these identities directly — you do not re-model your user directory here.
2. Enable remote access on the enclave
- Navigate to Enclaves → [Your Enclave] → Remote Access.
- Toggle Remote Zero Trust Access on.
- Pick the Tailscale groups allowed to reach this enclave.
- Save.
Only the groups you list here can see the enclave from off-site. Everything else remains invisible to Tailscale devices.
3. Scope the protocols
Remote ZT Access forwards whatever protocols the enclave ACL allows for the user. If an operator should only speak HTTPS to a historian, the ACL should say so — Access Gate does not silently open extra ports.
See Access control lists to tighten the per-user protocol set.
Revocation
Two ways to cut off remote access:
- Remove the user from the group in your IdP. Tailscale picks up the change on the next token refresh and the overlay route disappears.
- Disable the enclave's remote-access toggle. Every remote user loses the enclave at once — useful during an incident.
Both events land in the enclave change history.
Related
- Virtual Private Network — the built-in Tailscale client this flow rides on
- Privileged Access Management — browser-proxied RDP/SSH/VNC for admin sessions
- Access control lists
- Authenticate users with access screens