ZTNA and VPN are not interchangeable products, and replacing one with the other is rarely a simple licensing decision. This guide provides a repeatable way to compare identity controls, application access, device checks, administration, user experience, legacy compatibility, cost and migration risk so your remote team can choose a proportionate secure remote access model.
Overview
A traditional remote-access VPN usually creates an encrypted connection between a user’s device and a network or defined network segment. Once authenticated, the user may be able to reach several internal services. This can be practical for older applications, private networks and teams that need broad connectivity.
Zero trust network access, or ZTNA, is generally designed around application-level access. A user requests a specific service, the organisation checks identity and other signals, and access is granted according to policy. The exact controls vary by implementation, so “ZTNA” should be treated as an architectural approach rather than a guarantee of particular features.
The right question is not simply “Which is more secure?” Ask instead: which model gives this organisation the control it needs, at an acceptable cost and migration risk? A VPN may remain suitable for a small number of stable applications or systems that are difficult to publish through an application-aware service. ZTNA may be a better fit where users need narrowly scoped access, the workforce is distributed, identity-provider integration is mature and device posture matters.
For background on related designs, see our client VPN versus site-to-site VPN comparison and the secure remote access checklist for small businesses.
| Decision area | VPN tendency | ZTNA tendency | What to verify |
|---|---|---|---|
| Identity controls | Strong when integrated with MFA and central identity | Usually central to each access decision | SSO, MFA, conditional access and privileged-account support |
| Access scope | Network or segment access | Application or resource-level access | Whether users can reach more than their job requires |
| Device posture | May require separate tooling or configuration | Often a policy input where supported | Encryption, patch state, endpoint protection and managed-device checks |
| Legacy systems | Often easier for network-dependent services | May require connectors, gateways or redesign | Protocols, fixed IP assumptions and non-web applications |
| Logging | Connection and authentication events are common | Policy, identity and application events may be more granular | Retention, export, alerting and investigation workflow |
| Administration | Network rules, clients, gateways and capacity | Identity policies, connectors, applications and posture rules | Who owns each control and how changes are reviewed |
| User experience | Can be familiar but may require a client and routing choices | Can be application-specific but may introduce new sign-in steps | Sign-in time, client support and failure recovery |
| Migration risk | Lower if already stable | Higher during discovery and application onboarding | Rollback plan, pilot scope and dependency mapping |
How to estimate
Use two separate calculations: a cost estimate and a decision score. Keeping them separate prevents a cheaper option from automatically winning when it does not meet a critical security or operational requirement.
1. Estimate total annual cost
Use this simple model for each option:
Annual cost = licences or subscriptions + gateway and hosting costs + implementation effort + administration effort + support and training + contingency
Enter each item using your organisation’s own figures. Implementation effort can be estimated as staff hours multiplied by the fully loaded internal cost rate. Administration effort should include policy changes, access reviews, certificate or connector maintenance, troubleshooting and reporting. Do not count only the advertised per-user charge.
For a fair comparison, use the same period and assumptions. If a platform has a one-off migration cost, show it separately as both a first-year total and a recurring annual total. If pricing depends on users, devices, applications, traffic, connectors or features, calculate more than one scenario rather than selecting a single optimistic number.
2. Score the decision factors
Choose a score from 1 to 5 for each criterion, then assign a weight based on business importance. A simple formula is:
Weighted score = sum of (criterion score × criterion weight)
For example, an organisation with sensitive internal applications might give application-level access and identity controls a higher weight than convenience. A business with specialist legacy software might give compatibility and migration risk the highest weights. Record the reason for every score; this makes the assessment easier to challenge and repeat.
Set “must-have” conditions before scoring. Examples include MFA through the existing identity provider, support for a particular operating system, access to a legacy protocol, audit-log export, or a defined recovery process. An option that fails a must-have should not be rescued by high scores elsewhere.
Inputs and assumptions
Gather evidence before comparing products or architectures. Start with an access inventory containing each application, its owner, users, hosting location, protocol, authentication method, sensitivity and business criticality. Include systems that are often missed, such as development environments, administrative interfaces, file services, remote desktop tools and supplier access.
Then record the current VPN baseline:
- Number of active users, privileged users and managed devices.
- Current gateways, clients, authentication sources and MFA method.
- Peak concurrent sessions and any capacity or reliability issues.
- Network routes, split-tunnelling rules and third-party dependencies.
- Existing logs, alerting, access reviews and incident-response steps.
For a ZTNA assessment, add:
- Identity-provider integration, group quality and joiner, mover and leaver processes.
- Device-management coverage and the signals you can reliably verify.
- Connector placement, resilience, outbound connectivity and support for non-web applications.
- Application ownership and the time required to define least-privilege policies.
- How logs will reach the team responsible for detection and investigation.
Cost assumptions should state whether tax, hardware, professional support, employee time, training and contingency are included. Security assumptions should state what happens when identity, device posture or the access service is unavailable. A design that is strong during normal operation but has no practical break-glass or recovery process is incomplete.
Also consider legal and contractual requirements relevant to your organisation. For a UK business, review applicable data-protection duties, sector rules, customer contracts and data-location requirements with the appropriate internal owner. Do not assume that a product’s “zero trust” label automatically satisfies a compliance obligation.
Worked examples
Example A: small team with a stable application set
Imagine a 30-person organisation with a small number of internal services, mostly managed laptops and an existing VPN that is reliable. One legacy application depends on network-level access. The team has limited capacity for a large redesign.
Its assessment might give VPN a high compatibility score and a lower first-year implementation cost, while giving ZTNA a higher potential score for application-level control but a larger migration-risk deduction. The sensible outcome may be to retain the VPN temporarily, strengthen MFA, reduce network access through narrower groups and improve logging. A small ZTNA pilot could cover one modern application rather than attempting a complete replacement.
Example B: growing team with distributed access
Consider a 120-person organisation with several cloud and private applications, frequent joiners and leavers, and users working from different locations and devices. The current VPN grants broader network access than many roles require, and the IT team wants access decisions tied more closely to identity and device state.
In this case, ZTNA may score higher for application-level access, identity integration and future policy consistency. The cost model must still include application discovery, connector deployment, testing, user support and the continued operation of the VPN for systems that cannot yet move. The migration plan should not assume that every application can be onboarded at the same speed.
Use a pilot before choosing a winner
- Select one low-risk application and one representative user group.
- Document the current VPN path, dependencies, support contacts and rollback method.
- Integrate the proposed access model with the identity provider and MFA.
- Test managed and unmanaged devices, failed sign-ins, lost connectivity and account removal.
- Compare access time, support tickets, policy accuracy, logs and administrator effort.
- Update the cost and weighted-score worksheets using observed effort rather than estimates.
Keep the existing route available until the pilot meets agreed exit criteria. A pilot is not only a product demonstration; it is a test of your organisation’s identity data, application ownership and operational readiness.
When to recalculate
Revisit the comparison at least during the annual access review and whenever a major input changes. Recalculate after a licence renewal or price change, a merger, a significant increase in remote users, a move to new identity or device-management tooling, an application migration, or an incident involving remote access.
Update the worksheet when vendors change licensing units, supported integrations, logging options or application compatibility. Treat pricing as a variable, not a permanent fact. Record the date, assumptions, product versions and people who approved the result so a future review can distinguish a changed environment from a changed product.
A practical next step is to create three scenarios: retain and harden the VPN, run a hybrid VPN-and-ZTNA model, and migrate selected applications to ZTNA. Compare first-year cost, recurring cost, must-have controls, migration workload and rollback risk. Then assign an owner and review date for every open assumption. This turns the ZTNA-versus-VPN debate into a decision that can be tested, measured and updated as your remote-access needs evolve.
