Access Gate v26.6 is about operating Zero Trust across many sites and devices, not just standing it up on one. This post walks through the changes that matter for IT and OT teams. For the complete changelog, see the v26.6 release notes.
Network upgrades over HTTP(S)
Until now, upgrading meant a USB key per device. That does not scale to a fleet of 100+ appliances or to virtualized deployments. v26.6 adds upgrades over the network: a signed package is fetched from a URL, which can be a local air-gapped server, a partner-hosted server, or the Trout public server.
The mechanics matter for a security audience. Each package is cryptographically signed and verified before an A/B installation. A failed upgrade rolls back automatically to the last known-good state, including the pre-upgrade backup. Upgrade downloads are restricted to the admin interface. The result is that upgrades can be scripted and rolled out across sites remotely, instead of being handled by hand at each device. See Upgrading Access Gates for the procedure.
Privileged Access Management for OT
Many OT assets are reachable only through remote access (SSH, RDP, or VNC). In v26.6, those assets appear in Enclave Search and get their own Remote Access control in the ACL, managed independently from network services. You grant or revoke browser-based remote access per enclave, separately from opening a port.
This is Privileged Access Management applied to OT. Every SSH, RDP, or VNC session is brokered through Access Gate, authorized per enclave, and audited. A maintenance team or a third-party vendor reaches only the assets a given enclave grants, and every session is recorded.
Protocol-aware ACL rules
Access control no longer stops at the port. From the ACL table you can now express allow and deny conditions on specific protocol values: cap a Modbus coil value, filter HTTP requests by User-Agent, and so on. A protocol-specific editor turns these conditions into detection rules.
For OT, this means you can enforce process-level safety and security limits, such as blocking an out-of-range Modbus write, without re-architecting the network or adding inline devices.
Reworked Tailscale VPN integration
The Tailscale integration has been rebuilt for reliability. Virtual networks and assets synchronize from the Tailscale API, DNS resolves in both directions between Tailscale and local networks, and access-control rules apply consistently across Tailscale-to-local and Tailscale-to-Tailscale flows.
The point is remote and distributed IT: branch sites, roaming engineers, and cloud workloads. Tailscale handles connectivity, while Access Gate applies the same segmentation, access control, and audit to those flows as to on-premise traffic, so VPN-reachable assets remain governed by the same policies.
New threat detections
v26.6 ships built-in detection rules for several attack patterns common to IT and OT, so they are detected without writing custom detection logic:
- SMB relay: NTLM-over-SMB authentication directed at hosts not declared as SMB servers.
- Reverse shell: outbound shell traffic over suspicious ports and known payload patterns.
- Telnet usage: across zones, to critical assets, brute-force attempts, and recent Telnet CVEs, still relevant on legacy OT/IoT equipment.
- Tor and DNS tunnelling: traffic-pattern rules for anonymized and covert exfiltration channels.
Automated risk-assessment reports
Risk assessments can now be exported as structured PDF documents generated directly from your control-measure data, using a customizable template. The report is generated from current control data rather than compiled by hand, which is useful for NIS2 or IEC 62443 reviews.
Upgrading
Existing deployments can upgrade over the network or by USB. Two notes worth flagging before you upgrade: remote-access assets now require an associated service, so reconfigure them and the enclaves that reference them; and network upgrades restrict downloads to the admin interface, so make sure it can reach your chosen upgrade source. The full upgrade notes are in the v26.6 release notes.
