Secure Remote Access Beyond VPN Guide: ZTNA, Bastions and Browser-Based Access

A remote access VPN puts a user's device on the network, and once it is there the network does most of the trusting. That model made sense when the VPN concentrator was the only way in, but the same appliances now dominate exploited-vulnerability lists and a single stolen password can still open a whole subnet. This guide compares the patterns that replace or shrink the VPN: zero trust network access (ZTNA) brokers, identity-aware proxies, cloud-native session services, hardened bastions, browser-based gateways and privileged session proxies. It explains how each one works, which use case it fits, how to migrate without a big-bang cut-over, and what to log and measure. It is written for network, infrastructure and identity architects and for the security engineers who will run the result.

Key takeaways

• Grant access to applications, not networks. Every pattern in this guide narrows the blast radius from "the routed internal network" to a named application, host or session, which is the change that matters most.
• Nothing should listen on the internet if it can dial out instead. Brokers whose connectors make outbound TLS connections remove the exposed gateway that attackers scan for, and cloud session services remove inbound SSH and RDP entirely.
• Pick the pattern by user and protocol. Employees on web apps, administrators on servers, third-party vendors and legacy thick clients need different answers; one product rarely covers all four well.
• The broker becomes your most important identity control point. Its policies, connector credentials, session tokens and logs need the same care as the identity provider, because a stolen session or an over-broad rule recreates the flat network.
• Migrate by application group and measure what is left on the VPN. Run old and new in parallel, move the highest-risk access first (admins and third parties), and set a decommissioning date for the concentrator.

Why the VPN is no longer enough

NIST SP 800-46 Rev. 2 groups remote access into four architectures: tunnelling (the classic VPN), application portals, direct application access and remote desktop access. The VPN is the broadest of them. Once the tunnel is up, the device can usually reach far more than the user needs.

• Edge exposure: the concentrator is an internet-facing appliance that terminates authentication. CISA's Known Exploited Vulnerabilities (KEV) catalog lists dozens of entries for remote access gateways, including the Ivanti Connect Secure chain CVE-2023-46805 and CVE-2024-21887 and the NetScaler memory disclosure flaws CVE-2023-4966 and CVE-2025-5777, all marked as used in ransomware campaigns. In ATT&CK terms the gateway is the target of T1190 Exploit Public-Facing Application and the entry point for T1133 External Remote Services.
• Coarse authorisation: a VPN decides once, at connection time, and usually on group membership alone. Device health, the sensitivity of the destination and the behaviour during the session rarely feed back into the decision.
• Credential gravity: concentrators hold directory bind accounts, RADIUS secrets, certificates and API keys. When the appliance falls, those secrets fall with it.

Government guidance has moved in the same direction. CISA's Modern Approaches to Network Access Security, co-authored with the FBI, New Zealand's GCSB and CERT NZ and the Canadian Centre for Cyber Security, highlights the business risk of remote access misconfiguration and encourages organisations of all sizes to move towards zero trust, Security Service Edge (SSE) and Secure Access Service Edge (SASE). For the hardening of VPNs that must stay, see the VPN Security Guide; for protocol choice, see VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide.

The access patterns compared

Most mature estates run three or four of these patterns, each matched to a population and a protocol.

Remote browser isolation is a related but different control: it protects the user from the web rather than the network from the user. See the Remote Browser Isolation Guide.

How ZTNA brokers and identity-aware proxies work

NIST SP 800-207 describes zero trust as granting no implicit trust based on network location or asset ownership, with authentication and authorisation of both subject and device performed before a session with a resource is established. In its logical model a policy engine makes the decision, a policy administrator sets up or tears down the path, and a policy enforcement point sits in front of the resource. ZTNA products map those roles onto a cloud or self-hosted broker (decision and enforcement), an endpoint agent (device posture and traffic steering) and connectors near the applications.

Connectors that only dial out

The design point that removes the attack surface is the connector. Microsoft's documentation for Entra private network connectors, used by Entra Private Access, describes them as agents that make outbound connections to the service, with port 443 for service traffic and port 80 only for certificate revocation checks, and no documented inbound requirement. Microsoft also advises against TLS inspection on connector-to-cloud traffic, placing connectors close to the applications, grouping them for high availability and draining a connector through a maintenance group before patching it. For any product, ask what the connector can reach, what credential it registers with, and who can add one.

Application definitions are the real policy

Entra Private Access illustrates the trade-off well. "Quick Access" tunnels a broad primary group of FQDNs, IP addresses and ranges, which is quick to deploy and close to VPN behaviour; per-application Global Secure Access apps hold smaller sets of resources, each with its own user assignment and Conditional Access policy. Start broad to retire the VPN, then carve out per-app definitions for anything sensitive. An application defined as "10.0.0.0/8, all ports" is a VPN with a new logo.

Identity-aware proxies for web applications

Google Cloud's Identity-Aware Proxy (IAP) shows the reverse-proxy variant. Requests to a protected backend are intercepted, the user is sent to sign in, and the resulting identity is checked against an IAM role (IAP-secured Web App User) before the request is forwarded. Google is explicit about the limits: a user who can reach the application's serving port directly bypasses IAP, and firewall rules cannot stop code running on the same VM. Two consequences apply to any vendor's proxy:

• Close the side doors: restrict the backend so it accepts traffic only from the proxy's address ranges, and have the application verify the signed identity header or token the proxy adds rather than trusting an unsigned username header.
• Protect every ingress path: Google notes that when IAP is enabled on a load balancer in front of Cloud Run, the service's auto-assigned URL is not protected. Enumerate default URLs, health endpoints and management ports for each app you publish.

Design depth on brokers, posture signals and policy is in the ZTNA Guide, and the architecture behind it in the NIST SP 800-207 Zero Trust Architecture Guide.

Bastions and cloud session services for administrators

Administrative access pays off most, because RDP and SSH reachable from a broad network are the standard lateral movement paths (T1021.001 and T1021.004).

Classic jump hosts

A self-managed jump host is still common and still acceptable if it is treated as Tier 0 infrastructure: single purpose, no internet browsing, MFA at the front door, outbound connections only to the managed segment, local admin rights removed, and its own logs shipped off-box.

Managed bastion services

Azure Bastion is a representative managed bastion. According to Microsoft, RDP and SSH are carried over TLS on port 443, target VMs need no public IP, agent or special client, and they are not exposed to port scanning. Features differ by SKU, which matters for security design:

File transfer and shareable links are convenience features that widen what a session can do; enable them deliberately, not by default.

Agent-based session services

AWS Systems Manager Session Manager removes the bastion altogether. AWS documents that it needs no inbound ports, bastion hosts or SSH keys; access is controlled through IAM policies, which can be time-bound; client traffic is encrypted with TLS 1.2 and connection requests are signed with SigV4, with optional AWS KMS encryption; and session activity can be logged to CloudTrail (API calls), S3 or CloudWatch Logs, with EventBridge or SNS notifications on session start and end. AWS also states the important gap: session data is not logged for port forwarding or SSH sessions, because Session Manager is only a tunnel in those cases. If engineers use SSH through Session Manager, command-level audit has to come from the host. Google Cloud offers a comparable route through IAP for administrative SSH and RDP to VMs.

Whatever the mechanism, privileged sessions should be brokered and recorded by your privileged access tooling rather than by each cloud console separately. See the Privileged Access Management Guide and the Privileged Session Management Guide.

Browser-based (clientless) access

Clientless gateways render a remote desktop or terminal inside the browser, so the user's device never joins the network and never holds the target credential. The open-source Apache Guacamole is a useful reference model: a Java web application handles the interface and authentication, and a separate daemon (guacd) loads protocol plugins such as RDP and VNC and translates them into a display protocol drawn on an HTML5 canvas, over WebSocket or an HTTP tunnel.

• Where it fits: contractors, suppliers and staff on unmanaged devices, where installing an agent is impossible and full network access is unacceptable. It also suits short-lived support sessions to OT and legacy hosts; see the OT Remote Access Guide.
• Control the data channels: clipboard, file transfer, drive mapping and printing redirection are the exfiltration paths. Disable them by default and enable per connection.
• Protect the gateway as a credential store: if the gateway injects target credentials, it is a vault in all but name. Put it behind SSO with phishing-resistant MFA, store credentials in a secrets manager rather than the gateway database, and patch it like an edge device.
• Record and watermark: session recording and on-screen user watermarking deter misuse and support investigations, but recordings contain sensitive data and need their own access control and retention.

Unmanaged commercial remote support tools are a different risk: ATT&CK tracks their abuse as T1219 Remote Access Tools. Govern them separately; see the RMM Tool Security Guide.

Choosing by use case

Small organisations: a cloud-delivered ZTNA or SSE service plus the cloud provider's own session service usually covers everything and transfers appliance patching to the provider. Large organisations: expect a mixed estate; standardise on one broker for user access and one PAM layer for privileged sessions.

Where identity fits

Without the tunnel, all trust rests on identity, device and session signals.

• Session tokens are the new perimeter: brokers and proxies issue cookies or tokens after MFA. Keep lifetimes short, bind sessions to the device where the product supports it, and make sure you can revoke every active session centrally. ATT&CK T1550.004 Web Session Cookie describes the replay that follows a token theft.
• Connectors and agents are non-human identities: connector registration tokens, bastion managed identities and session-service instance roles need owners, least privilege and rotation. A connector that can reach every subnet is a standing machine credential with VPN-level reach.

See the Remote Access Identity Guide and the Zero Trust Identity Guide.

Migration plan

1. Inventory what the VPN is actually used for. Pull 30 to 90 days of VPN and firewall flow logs and group destinations into applications, protocols and user populations.
2. Retire dormant access first. Disable VPN accounts with no recent logins and remove legacy profiles that bypass MFA; this costs nothing and removes the easiest path in.
3. Stand up the broker in parallel. Deploy connectors in pairs per site, integrate with the identity provider and device management, and publish two or three low-risk web apps to an IT pilot ring.
4. Move administrators and third parties next. These populations carry the most risk on a VPN. Route them through PAM and the bastion or session service, and remove their VPN entitlement once the new path is proven.
5. Migrate employees by application group. Use broad Quick Access style definitions to move people quickly, then split sensitive applications into their own policies with stricter conditions.
6. Close the old paths. For each migrated application, remove the VPN firewall rule and check that the backend accepts traffic only from connectors or proxies.
7. Decommission or shrink the concentrator. Keep a scoped VPN only for documented exceptions with owners and review dates, then set a retirement date.

Testing and rollback: keep VPN access available to pilot users during each wave, measure help desk tickets and failed connections, and roll back an application group by re-enabling its VPN rule rather than widening the broker policy.

Detection and measurement

Metrics that show progress:

• Percentage of remote access sessions that go through the broker, proxy or session service rather than the VPN, tracked monthly.
• Number of internet-facing remote access listeners (VPN, RDP, SSH) found by external attack surface scans, with a target of zero for RDP and SSH.
• Percentage of published applications with per-app policy and backend restricted to connector or proxy addresses.
• Percentage of privileged and third-party sessions recorded.
• Median time to revoke all sessions for a user or for a compromised gateway, tested in exercises.

Framework mapping

Common failure patterns

• Leaving the old door open: a new broker is deployed but a legacy VPN profile without MFA stays live. In the Colonial Pipeline Ransomware Attack 2021, attackers used a leaked password on a VPN account that was no longer used but had never been disabled, and the VPN did not require MFA.
• Patching the gateway but not killing sessions: in CitrixBleed 2023, stolen NetScaler session cookies stayed valid after patching, and Citrix told customers to terminate all active and persistent sessions. Any broker or proxy compromise needs the same token revocation step.
• Forgetting what the appliance stores: in the Ivanti Connect Secure Exploitation 2024, attackers harvested user passwords and service account credentials, API keys and certificates held on the gateway, and CISA told organisations to assume stored credentials were compromised. Brokers, bastions and clientless gateways hold similar secrets.
• "ZTNA" with a /8 definition: one application covering whole internal ranges and all ports.
• Proxy in front, port open behind: the identity-aware proxy works but the backend also answers on its internal address or default cloud URL, so the policy can be bypassed.
• Audit gaps by design: engineers tunnel SSH through a session service whose logs do not capture tunnelled sessions, and nobody collects host-level command logs.

Practitioner checklist

• Inventory VPN usage by application, protocol and population, and disable dormant VPN accounts and legacy profiles now.
• Require phishing-resistant MFA and device compliance on every remote access path, including fallbacks and vendor routes.
• Deploy connectors that make outbound connections only, in pairs, with owners and least-privilege reach.
• Define applications narrowly for anything sensitive; ban network-wide definitions outside a time-limited migration phase.
• Restrict published backends to accept traffic only from connectors or proxies, and verify signed identity headers.
• Route administrators and third parties through PAM with just-in-time access and session recording.
• Remove internet-facing RDP and SSH; use a managed bastion or cloud session service instead.
• Disable clipboard, file transfer and drive mapping by default on clientless and bastion sessions.
• Rehearse revoking all sessions and rotating connector and gateway secrets after a compromise.
• Track the share of access still on the VPN monthly and set a decommissioning date.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-46 Rev. 2 Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• CISA: Modern Approaches to Network Access Security
• NCSC: Zero trust architecture design principles
• Microsoft Learn: Learn about Microsoft Entra Private Access
• AWS: AWS Systems Manager Session Manager
• Microsoft Learn: What is Azure Bastion?
• Google Cloud: Identity-Aware Proxy overview

Related NHI Mgmt Group resources: ZTNA Guide · VPN Security Guide · Privileged Access Management Guide · Remote Desktop (RDP) Security Guide · Remote Access Policy Template