The VPN gateway itself became the way in
Starting 3 October 2026, the UTA0576 group used a chain of zero-day vulnerabilities to gain root on fully patched Ivanti Connect Secure gateways.
Volexity, 13 October 2026OpenZTA Zero Trust · access by device and policy
Access to a resource, not the network — only from a verified device.pilot deployments
The device gets a certificate whose key is stored in a TPM or Secure Enclave — it can’t be moved to another computer. The agent continuously checks device posture: disk encryption, firewall, secure boot, antivirus. The gateway lets a user into a web resource only when both the user and the device are verified. We currently run pilot deployments together with our team.
● TPM 2.0 · Secure Enclave
● Windows · macOS · Linux
● server in your infrastructure
device · MacBook · ivanovaagent online
93%of rules
✓ key in Secure Enclave
✓ disk encryption · critical
✓ firewall on · high
✓ remote management off · critical
! not all updates installed · low
ivanova · MacBook → wiki.corpALLOW
petrov · Windows: disk not encryptedDENY
laptop without certificate → wiki.corpDENY
✓ rules met: critical 100% · high 100% · low 67%Envoy · :443
55device posture checks: Windows — 12, macOS — 24, Linux — 19
30ready-made CEL access rules — with versioning and an editor
5severity levels with 0–100% thresholds and block, allow, notify actions
TPM 2.0or Secure Enclave on Mac — the device key sits in a secure hardware module
Interface
This is Zero Trust at work
Gateway decision log: who was let in to which resource from which device, who was denied and which rule failed.
Demo data.
Why now
Attackers come in through the VPN — with the right password and MFA code.
A VPN checks the account, not the device it is used from, and once someone is in, it often opens up the entire network. VPN gateways themselves have become targets: CISA issued Emergency Directive ED 25-03 (25 September 2025) over Cisco ASA and Firepower vulnerabilities, and according to Verizon DBIR 2026, vulnerability exploitation accounts for 31% of initial access.
from SSL VPN login to encryption
That is how the Akira group operated through SonicWall SSL VPN in 2025 — including against accounts with OTP MFA. A second factor confirms the person but says nothing about their device.
Help Net Security, 29 September 2025started with access through a contractor
That was in 2025 — up from 6% in 2024. A contractor needs access to specific systems from a verified device, not the whole network from any laptop.
Solar 4RAYS, 12 March 2026How it works
Device certificate → posture check → gateway decision.
01
Certificate
The certificate authority issues the device a certificate bound to a key in the TPM (Windows and Linux, with AIK/EK attestation) or in the Secure Enclave (macOS).
02
Posture
The agent continuously checks the device: disk encryption, firewall, secure boot, antivirus, screen lock, auto-login, remote access, SSH settings.
03
Policy
CEL rules compare the device’s posture with your requirements. Each severity level has a threshold — the share of rules that must pass, from 0 to 100%.
04
Decision
The Envoy gateway asks the server for a decision and lets only a verified device and user through to the resource. Every decision is logged.
Capabilities
Not “you’re on the network”, but a decision per resource: who, from which device, in what state.
A certificate that can’t be copied
A built-in certificate authority issues certificates bound to keys in the TPM (Windows and Linux, AIK/EK attestation) and the Secure Enclave (macOS). Separate ECDSA P-384 roots for VPN and mTLS.
55 checks across three operating systems
Windows — 12, macOS — 24, Linux — 19: antivirus, disk encryption, firewall, secure boot, screen lock, UAC, auto-login, remote access, SSH settings, automatic updates on Linux.
30 ready-made rules and a rule editor
Rules in the CEL expression language, with versioning and an editor. A ready-made set for Windows, macOS and Linux — from “Disk encryption is enabled” to “Root login over SSH is disabled”.
Strictness set by severity level
Five levels: critical, high, medium, low, info. Each level gets a threshold of 0 to 100% of rules passed, and each policy gets an action: block, allow or notify.
Envoy in front of your web resources
The Envoy gateway with ext_authz lets only verified devices through to web resources over HTTPS — this scenario has been tested on a lab bench. For SSH and SMTP, authorisation is implemented; the full SSH scenario is validated during the pilot.
Decision log and device history
Gateway decisions are stored in a ClickHouse log and device posture in a history, so you can see who was or wasn’t let into which resource. Metrics go to Grafana.
Windows, macOS and Linux
Windows — a service and a tray icon. Linux — a systemd service, deb, rpm and tar.gz packages, and an OpenRC variant. macOS — a LaunchDaemon and an extension for working with the Secure Enclave.
Roles and multiple organisations
Supervisor, Administrator and User roles; multiple organisations in a single installation. Console login with a client certificate, a password or via Yandex ID.
Who it’s for
Security sets the requirements, IT deploys, and contractors get exactly their resource.
Security team
Device requirements as CEL rules, thresholds by severity level, the gateway decision log and device posture history for analysing denials.
IT administrators
A server on Docker Compose, agent packages for Windows, macOS and Linux, a console with roles and multiple organisations, metrics in Grafana.
Whoever manages contractors
A contractor gets access to the web resource they need, not to the network — and only from a device that has passed the checks.
Deployment
One server on Docker Compose and an agent on every device.
- Status
- Pilot deployments together with the vendor team. Pilot readiness confirmed on a lab bench: 12 of 14 scenarios passed — mTLS, console, certificate authority, agent API, allow and deny decisions, HTTPS via Envoy, SSH authorisation
- Server
- Docker Compose, about 15 services on a single server in your infrastructure
- Devices
- Windows and Linux with TPM 2.0, Mac with Secure Enclave
- Agents
- Windows — a service and tray icon; Linux — a systemd service, deb, rpm, tar.gz and OpenRC packages; macOS — a LaunchDaemon and a Secure Enclave extension
- Certificate authority
- Certificates bound to keys in the TPM (AIK/EK attestation) and Secure Enclave; separate ECDSA P-384 roots for VPN and mTLS
- Checks and rules
- 55 posture checks (Windows 12, macOS 24, Linux 19); 30 default CEL rules with versioning and an editor; 5 severity levels, 0–100% thresholds, block, allow and notify actions
- Resources
- Web over HTTPS (
:443) via Envoy with ext_authz — tested on the lab bench. SSH and SMTP — authorisation implemented; the full SSH scenario is validated during the pilot - Login and roles
- Console login via Yandex ID (OAuth), password or client certificate; Supervisor, Administrator and User roles; multiple organisations in a single installation
- Logs and metrics
- Gateway decision log in ClickHouse, device posture history, metrics in Grafana
- Network
- Console login via Yandex ID requires internet access. Air-gapped operation without internet is on the roadmap
Pilot with the vendor team
In 30 days — a report on which devices pass the checks and whom the gateway lets into which resources.
STEP 1
Scope
We choose the web resources and pilot groups — employees, administrators, contractors — and the requirements for their devices.
STEP 2
Deployment
We install the server in your infrastructure and agents on pilot devices with TPM 2.0 or Secure Enclave.
30 DAYS
Checks and decisions
Posture checks and access decisions for web resources — first in observation mode, then with blocking where agreed.
OUTCOME
Report and plan
Which devices fail the checks, what the gateway decided, what is needed for rollout — and a plan for the next stage.
The pilot requires devices with TPM 2.0 or Macs with Secure Enclave, plus internet access for console login via Yandex ID.
FAQ
What security and IT teams usually ask
Is the product ready for production use?
We are currently running pilot deployments together with our team. On the lab bench, 12 of 14 scenarios have passed, including certificate issuance, mTLS, allow and deny decisions, and HTTPS access via Envoy. The decision on production rollout is made based on the pilot results: the report shows what works on your devices and what needs to be done before rollout.
Which resources can it protect?
Web resources over HTTPS through the Envoy gateway — this scenario has been tested on the lab bench. For SSH and SMTP, authorisation is implemented; the full SSH scenario is validated during the pilot. We don’t claim support for other resource types at this point — tell us about your use case and we’ll discuss it.
Is it a VPN replacement?
Not entirely. Zero Trust covers access to web resources: the gateway lets a verified device and user into a specific resource instead of opening up the network. In the pilot, you can move selected web resources to this model and compare it with your current VPN access.
Does it work without internet access?
The server is deployed in your infrastructure, but air-gapped environments without internet access are not supported yet: in particular, console login via Yandex ID needs the internet. Air-gapped operation is on the roadmap.
Which devices are supported?
Windows and Linux computers with TPM 2.0 and Macs with Secure Enclave. Each one gets an agent: on Windows — a service with a tray icon; on Linux — a systemd service from a deb, rpm, tar.gz or OpenRC package; on macOS — a LaunchDaemon with a Secure Enclave extension.
What do you need from us for the pilot?
A list of web resources and pilot groups, a server for Docker Compose and pilot devices with TPM 2.0 or Secure Enclave. We handle deployment, rule configuration and the review of results together with you.
Does it send events to a SIEM, and does it work with our SSO?
Not yet: the product has no SIEM export and no OIDC/SAML login. Gateway decisions are stored in a ClickHouse log and metrics in Grafana; we record your integration requirements in the pilot report.
Zero Trust pilot
We’ll test it on your devices and your web resources.
Leave a request — we’ll agree the resources, pilot groups and device requirements. We run the pilot together with our team.
Request sent
We’ll contact you at the email you provided to arrange the Zero Trust pilot.
Other OpenZTA platforms
Corporate AIENCLAVEAnswers from documents, with source links and within access rights
AI securityPromtWallInjections, personal data and agents under control
DataOpenDSPMWhere personal data lives and who can access it
CodeOpenASOCEvery code check in one pipeline
MonitoringAI-SOCAttacks in logs without manual rules