Most ZTNA purchases are judged on a demo of a web application opening in a browser, then struggle months later with the thick-client, UDP, SSH and server-to-server traffic the VPN used to carry. Zero trust network access (ZTNA) products broker access to named private applications instead of placing a device on the network, and they differ widely in client options, connector design, posture checks, protocol coverage and how much of the policy decision you can see. This vendor-neutral buyer's guide is for network, identity and security teams evaluating a standalone ZTNA platform, usually as a VPN replacement. For how ZTNA works and how to migrate, read the ZTNA Guide; if you are buying ZTNA as part of a converged bundle with secure web gateway and CASB, use the SASE and SSE Buyer's Guide instead.
Key takeaways
- Start from your application inventory, not the feature list. The protocols, ports and client types your private applications need decide which products can actually replace the VPN.
- Agent and agentless are both needed. Agents cover managed devices and any protocol; browser-based access covers contractors and unmanaged devices, usually for web, RDP and SSH only.
- Connectors are critical infrastructure. They sit inside your network with reach to applications, so their hardening, redundancy, update model and credentials matter as much as the cloud broker.
- Posture and session re-evaluation separate products. Joint guidance from CISA and partners expects brokers to check device posture, enforce phishing-resistant MFA and disconnect suspected compromised devices.
- Test the hard cases in the proof of concept. Legacy thick clients, out-of-hours connector failure, posture drift mid-session and log export reveal more than any datasheet.
Define requirements
- Application inventory: list every private application in scope with its FQDN or IP range, ports, protocols (TCP, UDP, ICMP), whether it is web, thick client, RDP, SSH, database or file share, and where it is hosted (data centre, IaaS, OT site).
- User populations: employees on managed devices, employees on personal devices, contractors, third-party support suppliers and privileged administrators. Each needs different client and posture rules.
- Machine and server-initiated flows: server-to-server traffic, VoIP call-back, remote support tools that connect back to the user and update services that push to endpoints. Many ZTNA products handle only user-initiated connections, so name these flows early.
- Identity and device sources: your identity provider (SAML or OIDC sign-in, SCIM group sync), MDM and EDR products whose signals should feed posture, and whether device certificates are available.
- Locations and performance: where users and applications are, latency budgets, data residency for logs, and whether a self-hosted or private broker is needed for sites with restricted internet access.
- Control mapping: NIST SP 800-53 AC-17 Remote Access and AC-17(1) Monitoring and Control, AC-3 Access Enforcement, IA-2 Identification and Authentication, SC-7 Boundary Protection; NIST CSF 2.0 PR.AA-05 and PR.IR-01.
Where identity fits
ZTNA turns identity weaknesses into network weaknesses: a phished account with a compliant laptop gets exactly the applications its group allows. Require phishing-resistant MFA at the identity provider, keep application-level sign-in in place, and treat the connector enrolment tokens, API keys for policy automation and the admin console accounts as privileged non-human and human identities. See the Zero Trust Identity Guide.
Capability areas
| Area | What to look for | Why it matters |
|---|---|---|
| Client models | Endpoint agent for Windows, macOS, Linux, iOS and Android; clientless browser access for web, RDP and SSH; option to use both under one policy | Determines which users and protocols can leave the VPN |
| Application connectors | Outbound-only connectors, high availability groups, automatic updates with a maintenance window you control, small and hardenable footprint, container or virtual appliance options | Removes inbound listening services, but each connector is a privileged foothold |
| Protocol coverage | TCP and UDP, wildcard and FQDN publishing, server-initiated and bidirectional flows, private DNS resolution | Thick clients and VoIP break first in most migrations |
| Policy model | Default deny, per-application segments, group and attribute conditions, time and location conditions, policy simulation or "what if" testing | Broad "all private networks" segments recreate the VPN |
| Device posture | Native checks (OS version, disk encryption, firewall, EDR running), MDM and EDR integrations, device certificates, re-evaluation during the session | Self-reported attributes are weak; posture checked only at sign-in goes stale |
| Session controls | Re-authentication on new application, session lifetime, step-up MFA, immediate revocation on identity provider or EDR signal | CISA guidance expects compromised devices to be blocked or disconnected |
| Privileged and third-party access | Browser-isolated RDP and SSH, session recording, just-in-time access windows, approval workflows | Support suppliers are a common entry point and often overlap with PAM tools |
| Visibility and logging | Per-session logs with user, device, application, decision and reason; admin audit trail; streaming to SIEM in a documented format | Needed for detection, investigation and evidence of access control |
| Administration | Role-based admin with scoped delegation, API and infrastructure-as-code support, change history and rollback of policy | The console can grant access to everything |
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Application coverage | All in-scope applications reachable without split VPN, including UDP and server-initiated flows | Publish your ten hardest applications | [25%] |
| Policy precision | Per-application rules, attribute conditions, simulation before enforcement | Rebuild one VPN access group as least privilege segments | [15%] |
| Posture and continuous evaluation | EDR and MDM signals, device certificates, mid-session revocation within minutes | Disable EDR on a test device during a session | [15%] |
| Connector resilience and security | Redundant, outbound only, restricted reach, signed updates, rotated enrolment credentials | Kill one connector in a group; review its network reach | [15%] |
| Unmanaged and third-party access | Clientless web, RDP and SSH with no data download, approval and expiry | Onboard a contractor on a personal laptop | [10%] |
| Logging and integration | Complete session and admin logs streamed to SIEM; SCIM and API support | Trace one session end to end in your SIEM | [10%] |
| Cost and operations | Clear licence metric (users, devices, applications, bandwidth), predictable growth cost | Model three-year cost at [20%] growth | [10%] |
Weights are illustrative: set them from your own drivers before responses arrive and do not change them afterwards.
Decision guidance: a standalone ZTNA platform suits organisations replacing a VPN for private applications while keeping their existing web proxy and CASB. If you are also replacing a secure web gateway or need SD-WAN, a converged SSE or SASE platform may be simpler to run. Smaller organisations with mostly SaaS and a few private web applications may get enough from an identity-aware proxy in their identity provider or cloud platform; large estates with OT sites, thick clients and many suppliers need the full connector, protocol and third-party feature set. Keep site-to-site links on purpose-built network tools.
Questions to ask vendors
- Which protocols do you support through the agent and through clientless access, including UDP and connections initiated from the server side towards the user?
- How does a connector authenticate to your broker, how are its credentials rotated, and what happens if a connector host is compromised?
- Who controls connector and client updates, how are they signed, and can we stage them through rings?
- Which posture signals do you collect natively, which come from MDM and EDR integrations, and how quickly does a change in posture end an active session?
- Do you re-authenticate when a user requests a different application, and can session lifetime vary by application sensitivity?
- Can we simulate a policy change against real traffic before enforcing it, and roll back a policy version?
- What does a session log record, in what format, with what latency to our SIEM, and how long do you retain it?
- Where is the policy decision made, where is traffic inspected or decrypted, and in which regions are logs stored?
- Which of your own staff can access our tenant, how is that access approved and logged, and which independent assurance reports cover the service?
- What is the licence metric, and how are service accounts, shared devices and contractors counted?
Red flags
- Demonstrations limited to browser access to a web application, with no thick-client or UDP test offered.
- A recommended first policy that publishes whole subnets to all users "to start", with no plan to narrow it.
- Posture checked only at sign-in, or based solely on attributes the client reports about itself.
- Connectors that need inbound firewall rules, run as a privileged account on a domain-joined server, or have unrestricted reach into the network.
- Session logs only visible in the vendor console, or exported without the policy decision and reason.
- A self-hosted gateway with a public listening interface marketed as zero trust: that is a VPN concentrator with another name, and CISA's joint guidance lists exploited VPN appliances among the problems ZTNA is meant to solve.
- No answer on how the vendor protects its own control plane and admin access.
Proof of concept
- Pick the test set: choose ten applications covering web, thick client, RDP, SSH, a UDP service and one server-initiated flow, plus three user groups (managed employee, contractor on a personal device, administrator).
- Deploy connectors properly: two connectors per group on hardened hosts, outbound only, with network reach limited to the published applications. Record time to deploy.
- Build least privilege policy: translate one existing VPN access group into per-application rules, run them in simulation or monitor mode, then enforce.
- Test posture and revocation: during a live session, stop the EDR service, disable the user in the identity provider and revoke the device certificate. Record how long each takes to end access.
- Test failure: stop one connector and the broker region nearest the pilot users; confirm failover and measure user impact.
- Test third-party access: give a contractor time-bound, browser-only RDP access with approval and expiry; confirm no file transfer if policy forbids it.
- Trace logging: follow three sessions, one allowed, one denied, one revoked, from the console to your SIEM, and check admin changes are logged.
- Score and clean up: score against the criteria table, then remove connectors, revoke enrolment tokens and API keys, and delete trial tenants.
Afterwards, track the share of remote sessions through ZTNA versus VPN, the number of broad segments remaining, median time to revoke access after a posture or identity change, and connector availability. See the VPN and Firewall Log Detection Guide for monitoring the VPN while it is wound down.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: ZTNA Guide · SASE and SSE Buyer's Guide · SASE and SSE RFP Template · Secure Remote Access Beyond VPN Guide · Zero Trust Identity Guide