Zero Trust Network Access (ZTNA) Guide

A remote access VPN authenticates a user once and then places their device on the internal network, where it can reach far more than the handful of applications the user needs. Zero trust network access (ZTNA) replaces that model with identity-based network access: a broker mediates every connection and decides, per application and per session, whether this user on this device may reach this service, and nothing else is reachable or even visible. This guide covers the NIST SP 800-207 model, agent, agentless and service-initiated architectures, connectors, policy, posture, machine-to-machine access and a phased VPN migration. It is written for network and security architects, identity teams and engineers planning or running a ZTNA deployment. Identity strategy across the whole estate is covered in the Zero Trust Identity Guide.

Key takeaways

• ZTNA grants access to applications, not networks. Each policy names a user or group, a device condition and a specific FQDN or IP and port; everything else stays unreachable, which is what NIST SP 800-207 means by access "granted on a per-session basis".
• The connector model removes inbound exposure. Application connectors make outbound connections to the broker, typically over TCP 443, so the data centre needs no listening VPN concentrator, a class of edge appliance attackers exploit repeatedly.
• Policy quality decides the outcome. A ZTNA deployment that publishes whole subnets to all employees is a VPN with a new logo. Inventory applications and build per-application segments before cutover.
• Agent and agentless serve different users. Agents give posture checks and any TCP or UDP protocol for managed devices; clientless browser access suits contractors and BYOD but, as NIST notes, can only assess devices once they connect.
• Machines need ZTNA too. Service accounts, connectors and workload-to-workload flows need short-lived cryptographic identities and per-service policy, not a site-to-site tunnel that trusts everything on the other side.

What ZTNA is and how it differs from a VPN

Google's BeyondCorp paper (Ward and Beyer, 2014) described "removing the requirement for a privileged intranet and moving our corporate applications to the Internet". NIST SP 800-207 later described this perimeterless approach as zero trust architecture, and ZTNA products implement its components.

• Policy engine (PE): makes the grant, deny or revoke decision using a trust algorithm and logs it. In ZTNA this is the broker's policy service, fed by the identity provider, device management and threat signals.
• Policy administrator (PA): "responsible for establishing and/or shutting down the communication path between a subject and a resource". It issues session tokens and instructs the enforcement points; in a ZTNA product it is the controller that stitches the client and connector together.
• Policy enforcement point (PEP): enables, monitors and ends connections. NIST allows it to be split into a client-side agent and a resource-side gateway, which is exactly the agent plus connector pattern.

The term software-defined perimeter (SDP) describes the same pattern from the Cloud Security Alliance. Its specification (now v2.0) names three components: an SDP controller, initiating hosts and accepting hosts, and uses single packet authorization (SPA) so that accepting hosts do not answer any packet until the initiator has proved who it is. Some vendors call it identity-defined networking.

CISA's Zero Trust Maturity Model v2.0 describes the same journey in its Applications and Workloads pillar. At the Traditional stage applications are "available only over private networks and protected public network connections (e.g., VPN) with monitoring"; at Initial they are "available over open public networks to authorized users with need via brokered connections"; at Optimal "all applicable applications" are reachable that way. In the Networks pillar, "bulk traffic VPN tunnels" are listed as a Traditional characteristic.

ZTNA architectures

Products differ mainly in who starts the connection and what sits on the user's device. The labels endpoint-initiated and service-initiated are widely used in the market; NIST's deployment models describe the same choices.

• Cloud-delivered or self-hosted: most products run the broker as a cloud service, often as the private application access part of a security service edge (SSE) platform. Self-hosted brokers suit regulated or air-gapped sites, but you then own the patching and availability.
• Open source overlays: OpenZiti describes itself as "a free, open-source zero trust networking platform" with a controller, a mesh of routers and edge clients delivered as tunnelers or SDKs. Services can be made "dark", with "no open listening ports", and "every identity requires a certificate".
• Universal ZTNA: applying the same broker and policy whether the user is at home or in the office, so that campus users no longer get flat network access just because they are on site. It needs a local enforcement path so office traffic is not hairpinned through the cloud.

Application connectors

The connector is the part most often treated as plumbing and most deserving of care. Microsoft's documentation for Entra private network connectors is a useful reference for the pattern: connectors "only send outbound requests", "You don't have to open inbound ports", and they need outbound TCP 80 and 443 to the service.

• Redundancy: deploy at least two connectors per connector group (Microsoft says "Use at least two connectors in each group for high availability"), in different failure domains. Automatic updates are applied one connector at a time per group, so a single connector means downtime at every update.
• Placement: put connectors as close to the applications as possible, one group per site or VPC.
• Restrict the connector's own reach: a connector can talk to anything its host can route to. Use host or network firewall rules so the connector subnet reaches only the published application ports, never the whole data centre. See the Network Segmentation Guide.
• Harden the host: dedicated minimal servers, no user logons, EDR installed and admin access only through the privileged access path.
• Egress control: allow connectors outbound only to the broker's documented destinations.
• DNS: publish applications by FQDN so IP changes do not silently widen or break access, and log the connector's resolutions.

Designing access policy

NIST tenet 4 states that "Access to resources is determined by dynamic policy". In practice a ZTNA policy is a set of rules binding subjects to application segments under conditions.

• Default deny: an application not explicitly published is unreachable. Resist the "full tunnel to everything" policy that some products offer for quick migrations, or give it an owner and an end date.
• Per-application access, not per-network access: CISA ZTMM v2.0 describes Initial-stage application access as authorising with "contextual information (e.g., identity, device compliance, and/or other attributes) per request with expiration", and Optimal as continuous authorisation with "real-time risk analytics".
• Keep application authentication: ZTNA controls who can reach an application, not what they do inside it. Do not publish applications without their own sign-in on the assumption that ZTNA covers them.
• Privileged protocols: publish SSH and RDP only to admin groups on compliant devices, ideally via a privileged access layer. See the Privileged Access Management Guide.

Posture checks and unmanaged devices

NIST tenet 5 requires the enterprise to monitor "the integrity and security posture of all owned and associated assets". ZTNA brokers take posture from three places: the agent itself (OS version, firewall, disk encryption, certificate present), the MDM or unified endpoint management console (compliance state), and EDR (sensor health and risk score).

• Device identity first: a device certificate issued at enrolment and held in the TPM is a stronger signal than any self-reported attribute. Posture reported by an agent on a compromised device can be falsified, so treat it as one input, not proof.
• Freshness: console-based compliance may be hours old. Know whether a change revokes the session or only applies at next sign-in.
• Unmanaged and BYOD: give browser-only access through the clientless portal, with download, clipboard and print restrictions where the product supports them. See the Enterprise Browser and Browser Security Guide.
• Align with conditional access: use the same compliance definitions in the IdP and the ZTNA broker so a device is not compliant in one and not the other. See the Device Trust and Posture Guide and the Conditional Access Guide.

Where identity fits

ZTNA turns identity into the network access decision, so weaknesses in identity become network weaknesses. NIST SP 800-207 is explicit that subjects include "applications and other nonhuman entities", and lists stolen credentials as a threat: "An attacker with valid credentials (or a malicious insider) may still be able to access resources" the account is authorised for.

• User identity: the IdP is now the front door to the network. Enforce phishing-resistant MFA, disable dormant accounts and protect the IdP's own administrators. See the Identity Provider and SSO Security Guide.
• Service accounts and machine-to-machine access: batch jobs, monitoring tools and integrations that crossed the old VPN or a site-to-site tunnel need their own identities. NIST SP 800-207A recommends that "Each service should present a short-lived cryptographically verifiable identity credential to other services", such as a SPIFFE SVID over mutual TLS, reauthenticated regularly. See the Cloud Workload Identity Guide and the Service Account Security Guide.
• Connector and broker credentials: connector registration certificates, broker API keys used by infrastructure as code and the admin accounts of the ZTNA console can each publish new applications or rewrite policy. NIST names "subversion of decision process" as the first ZTA threat. Vault these credentials, require MFA for console admins and log every policy change.
• Third parties: federate partners or give them expiring accounts, scoped to named applications. See the Third-Party Access Guide.

Migrating from VPN in phases

1. Inventory applications and flows: export VPN logs and firewall flow data for 30 to 90 days to see which users reach which hosts and ports. Group flows into applications and assign an owner to each. Flag server-initiated flows (software distribution push, VoIP, remote assistance tools) that a ZTNA client may not carry.
2. Run a proof of concept: test with three to five representative applications: a web application, an RDP or SSH target, a thick-client application using a non-HTTP port, and one UDP-dependent service. Score sign-in experience, posture enforcement, latency, log detail, API coverage, DNS and split tunnelling, and connector failover (power one off mid-session).
3. Publish the first applications with monitoring: deploy connectors in pairs, publish web applications first through clientless access, and run ZTNA in parallel with the VPN so users have a fallback.
4. Pilot rings: start with IT staff, then a business unit, then third parties, who often gain the most because they currently hold VPN accounts with broad ACLs.
5. Tighten policy: replace any broad migration segments with per-application segments, add device posture requirements, and shorten sessions for privileged applications.
6. Shrink the VPN: remove users from VPN groups as their applications move, restrict remaining VPN profiles to the residual applications, and enforce MFA on whatever is left.
7. Rollback plan: keep the VPN profile available but disabled per ring for an agreed period, so a broken application can revert by group membership change rather than reinstalling software.
8. Decommission: remove the concentrator's internet exposure, close UDP 500, 4500 and TCP 443 inbound, delete VPN-only accounts and certificates, and update the remote access policy.

Choosing an approach

• Agent vs agentless: choose the agent for employees on managed devices who need non-web protocols; choose clientless for web, SSH and RDP access by contractors and unmanaged devices.
• Small organisations: a cloud-delivered broker bundled with the identity provider or SSE service, with a pair of connectors and web applications published first, removes the VPN appliance and its patching burden quickly. Avoid self-hosting the broker without staff to run it.
• Large organisations: plan connector groups per region, policy as code through the broker API, SIEM and SOAR integration, and universal ZTNA on campus.
• Where VPN or tunnels remain: site-to-site links between data centres, some OT and voice systems, and applications that require inbound connections to the client. Keep these narrow and segmented, and revisit them each year.
• ZTNA vs NAC and segmentation: ZTNA governs user-to-application access from anywhere; NAC governs admission to local network ports; segmentation governs workload-to-workload traffic. See the Network Access Control (NAC) Guide.

Detection and measurement

• Broker access logs: every allow and deny with user, device ID, posture result, application segment, source IP, connector and bytes transferred. Forward them to the SIEM and keep them long enough for investigations. See the SIEM Guide.
• Policy and admin audit logs: new application segments, changes to who can reach them, new connectors registered and API key use.
• Behavioural alerts: repeated denies to unpublished hosts (scanning from inside a session), sudden access to many new applications, sessions from two countries, and connector hosts connecting anywhere other than the broker and published applications.
• Residual VPN: alert on VPN logins by accounts already migrated.

Metrics:

• Percentage of remote access sessions through ZTNA rather than VPN.
• Number of published application segments using wildcard domains or ranges larger than /24.
• Percentage of ZTNA access requiring a compliant managed device or phishing-resistant MFA.
• Number of active VPN accounts and third-party users with network-level access.
• Median time from account disable to session termination in the broker.
• Connector groups with fewer than two healthy connectors.

Framework mapping

Common failure patterns

• Leaving the VPN appliance exposed after go-live: the concentrator stays internet-facing "for a few users" and keeps the old attack surface. The Ivanti Connect Secure Exploitation 2024 showed how two VPN zero-days exposed credentials, service accounts and sessions on the appliance itself.
• Password-only access at the front door: ZTNA or VPN, a single factor on the access path is enough for attackers with stolen credentials, as in the SonicWall SSL VPN Account Compromises 2025.
• Dormant remote access accounts: migrated or departed users keep VPN or ZTNA entitlements nobody reviews. The Colonial Pipeline Ransomware Attack 2021 began with one unused VPN account.
• Broad migration segments that never shrink: "10.0.0.0/8 for all employees" is published to speed migration and becomes permanent, recreating VPN-level lateral movement.
• Long sessions with no continuous evaluation: a session token that lives for days survives password resets and device compromise. The CitrixBleed 2023 incidents showed stolen session tokens bypassing MFA on a remote access gateway.
• Unrestricted connectors: a connector on a flat server VLAN can reach every system, so one compromised connector exposes the whole site.

Practitioner checklist

• Inventory remote access flows from VPN and firewall logs and assign an owner to every application.
• Run a proof of concept covering web, RDP or SSH, a thick client and a UDP service, including connector failover.
• Deploy at least two connectors per group, on hardened hosts, with firewall rules limiting them to published application ports.
• Publish applications by FQDN and port; set an end date for any broad migration segment.
• Require phishing-resistant MFA and a compliant managed device for sensitive and administrative applications; give unmanaged devices browser-only access.
• Give service accounts and workloads short-lived certificate or token identities instead of tunnel access.
• Vault connector, broker API and console admin credentials, and alert on policy changes.
• Revoke sessions automatically when an account is disabled or a device falls out of compliance.
• Remove VPN users ring by ring, then remove the concentrator's internet exposure.
• Report the metrics above monthly to the remote access owner.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• CISA: Zero Trust Maturity Model Version 2.0
• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments
• CISA, FBI and partners: Modern Approaches to Network Access Security
• Cloud Security Alliance: Software-Defined Perimeter (SDP) Specification v2.0
• Google Research: BeyondCorp, A New Approach to Enterprise Security
• Microsoft Learn: Private Network Connectors for Global Secure Access
• MITRE ATT&CK: T1133 External Remote Services

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Remote Access Identity Guide · Network Segmentation Guide · Third-Party Access Guide · Zero Trust for AI Agents Guide