Zero-Trust Remote
Access (No VPN)

The firm needed engineers and authorized personnel to reach an isolated lab environment from the corporate network. Traditionally, that problem gets solved with a VPN. Provision access. Open firewall rules. Build the tunnel. Grant network-level connectivity. Hope nobody pivots laterally once connected. Repeat every time another environment comes online. Every part of that architecture creates operational and security overhead.

The security concern was not just remote access itself — it was the trust model behind it. VPNs operate at the network layer. Once authenticated, users are effectively placed onto the target network segment whether they need broad network access or not. The infrastructure becomes another permanent surface area to manage: exposed services, inbound firewall rules, VPN concentrators, patch cycles, certificate maintenance, routing complexity, and access reviews that inevitably drift over time.

The security team wanted something narrower and more deterministic. Access scoped only to the applications and resources explicitly required. Authentication tied directly to identity and device posture. No inbound firewall exposure on the lab side whatsoever. The ask was not "build a better VPN." The ask was to solve the remote access problem without introducing another piece of infrastructure that itself becomes a liability.

AOtech implemented a Zero-Trust Network Access architecture using a cloud-hosted broker as the control and relay layer between corporate users and the isolated lab environment. Instead of exposing inbound services or standing up a VPN concentrator, the lab-side connector establishes an outbound-only TLS tunnel to the broker. No inbound firewall rules are required because the lab environment never accepts unsolicited inbound connections.

On the corporate side, users authenticate through the broker using identity-aware controls tied into the organization's authentication systems. Before access is granted, the broker evaluates both user identity and device posture conditions. The decision point becomes contextual instead of network-based: who the user is, what device they are using, and whether that device meets policy requirements.

The architecture intentionally prevents direct network reachability into the lab environment. Users do not "join" the lab network the way they would through a traditional VPN. Access is scoped only to the approved application or resource path routed through the broker. The broker becomes the single control plane for authentication, authorization, posture evaluation, and connection mediation. The lab network itself remains isolated behind outbound-only connectivity.

The most important shift was elimination of network-level trust as the access model. Remote users no longer receive broad connectivity into isolated environments simply because they authenticated successfully once. Access decisions are now tied to identity, posture, and explicit resource authorization instead of tunnel membership.

Operational complexity also dropped significantly. There are no inbound firewall holes to maintain, no exposed VPN infrastructure, and no requirement to manage traditional remote-access concentrators for the lab environment. The isolated network remains operationally dark from an inbound perspective while still allowing authorized users to reach the resources they need.

The result was a cleaner security boundary with less infrastructure to defend. The organization gained controlled remote access into isolated engineering environments without increasing the attack surface of the lab itself. The architecture effectively turned remote access from a network problem into an identity and policy problem.