The decision is not ZTNA or VPN. It is whether the identity infrastructure is ready for ZTNA.
Most organisations asking about ZTNA are not asking a theoretical architecture question. They are running VPN that has become a performance, security or compliance problem. VPN grants network-level access after authentication; ZTNA grants access to named applications, verified per session. That difference matters most when credentials are compromised.
See the side-by-side comparisonUnder VPN, a valid credential can open network-level access and allow lateral movement across the permitted segment. Under ZTNA, the same credential can reach only the applications that user is explicitly allowed to access. The improvement is architectural, but it is not automatic — ZTNA only works properly when the identity foundation is clean: accurate groups, enforced MFA, registered devices, known application dependencies and clear access ownership. This comparison covers the access model (network vs application access), lateral movement under compromised credentials, identity-infrastructure prerequisites, contractor and third-party scoping, legacy applications and where VPN still fits, the migration sequence and parallel operation, Microsoft Entra Private Access and FortiSASE ZTNA platform paths, and the Essential Eight, cyber insurance and Australian decision factors. The right question is not whether ZTNA is newer. It is whether identity is ready for it.
The right choice depends on identity, application fit and operating capability.
Six decision areas shape this comparison.
ZTNA depends on clean identity, enforced MFA, accurate groups and device posture.
Cloud and web applications suit ZTNA more naturally than legacy protocols.
ZTNA becomes more valuable when remote and hybrid access are permanent, not occasional.
ZTNA can scope contractors to named applications rather than network segments.
ZTNA can provide stronger access evidence where identity and policy are properly governed.
ZTNA requires ongoing ownership of access policy, group membership, exceptions and application onboarding.
ZTNA is not a VPN upgrade. It is a different access model with different prerequisites.
VPN assumes that a user who authenticates successfully can be trusted with network-level access for the duration of the session. ZTNA assumes nothing by default — every session is verified against identity, device posture and access policy, and access is scoped to a specific named application rather than the network. That difference matters most when credentials are compromised: under VPN, an attacker with valid credentials has network-level access and can move laterally; under ZTNA, the same credential reaches only the applications that user is explicitly permitted to access, and cannot move anywhere else.
- Creates an encrypted tunnel granting network-level access after one authentication event
- Users can reach anything on the permitted network segment once connected
- Designed for occasional remote access to on-premises applications
- Grants access to a named application only — no network-level access
- Verified per session by identity, device posture and policy
- Applications are invisible to users who are not authorised for them
Both encrypt. The difference is what is trusted and how broadly.
VPN's security model was designed for a world where users were occasionally remote and applications were on-premises. The authentication event established trust, and that trust persisted for the session. At the scale of occasional remote access, the risk was manageable. At the scale of permanently hybrid workforces, Microsoft 365 as the primary application platform and contractors with network access, the same trust model becomes a liability.
ZTNA does not replace encryption — both VPN and ZTNA encrypt sessions. ZTNA replaces the scope and persistence of trust. Every ZTNA session is evaluated against current identity and device state: a device that becomes non-compliant during a session can have access revoked, and a credential used from an unregistered device is evaluated differently to the same credential from a compliant managed device. The question is not whether VPN encrypts. It does. The question is whether "authenticate once, trust for the session" is the right model for a permanently hybrid workforce.
ZTNA changes who can reach what, for how long, and under which conditions.
VPN grants access to a network segment. ZTNA grants access to a named application. A contractor under VPN can potentially reach any system on the permitted subnet; under ZTNA, the same contractor reaches only the applications they are authorised for and nothing else.
VPN makes lateral movement possible for any compromised credential that can authenticate. ZTNA removes network-level lateral movement because access is application-scoped — there is no broader network to traverse.
VPN trusts for the duration of the session after a single authentication. ZTNA evaluates continuously — device posture changes, context signals and session anomalies can trigger re-evaluation during a session.
Under VPN, any application on the accessible network segment is potentially discoverable. Under ZTNA, applications are hidden from users who are not authorised for them — an attacker who authenticates sees only the applications they are explicitly permitted to access.
VPN is simpler to deploy and has lower prerequisites. ZTNA requires clean identity infrastructure before it works correctly — that prerequisite work is real and should not be underestimated.
Where each model is genuinely stronger.
An honest comparison acknowledges where VPN retains genuine advantages. This is not a case where one architecture universally dominates the other. The right answer is environment-specific.
When ZTNA is the right choice, and when VPN still fits.
- Contractor or third-party access runs through VPN — ZTNA scopes access to named applications and can support agentless access for unmanaged devices
- A lateral movement incident has exposed VPN trust risk — ZTNA removes network-level access, though identity remediation is required first
- Essential Eight, insurer or audit pressure is forcing uplift — ZTNA on a clean identity foundation produces the required access evidence and MFA posture
- VPN performance is degrading Microsoft 365 and Teams — ZTNA enables application-level access without backhauling all cloud traffic through the concentrator
- Remote work is permanent, not occasional — ZTNA suits a workforce that regularly accesses applications from outside the office network
- Identity infrastructure is not mature enough for ZTNA — with stale accounts, MFA exceptions or inaccurate groups, remediate identity first; hardened VPN with enforced MFA is the proportionate answer during remediation
- Legacy applications cannot be fronted by an identity proxy — Kerberos without federation or non-standard protocols; partial deployment (ZTNA for cloud/web, VPN for specific legacy apps) is often right
- Site-to-site connectivity is the actual use case — ZTNA replaces user-facing remote access, not site-to-site VPN; that is replaced by SD-WAN, and the two decisions do not need to be made together
Identity assessment comes before platform selection.
Most ZTNA migrations that fail or stall do so because they begin with platform selection rather than identity assessment. Running ZTNA and VPN in parallel during migration is not a compromise — it is the correct approach.
Audit Entra ID or the current identity provider for stale accounts, MFA exceptions, unregistered devices and group membership accuracy. This determines whether ZTNA can begin immediately or whether remediation is required first. If identity is not clean, select a platform after remediation, not before.
List every application remote users access. Identify which are cloud-hosted and accessible directly, which are on-premises and need a connector, and which use non-standard protocols that may require VPN to remain. This determines what can be migrated and what must stay.
ZTNA deployment does not require VPN decommission. Deploy ZTNA and keep VPN running. Migrate one user group first, validate that all required applications are accessible, and confirm performance before proceeding.
Users with simple, cloud-first application stacks migrate first. Users with legacy dependencies migrate last, or remain on VPN for those specific applications while migrating to ZTNA for everything else.
VPN is decommissioned for a user group when that group has been stable on ZTNA and no application access gaps remain. Do not set a hard site-wide VPN decommission date before all groups have been validated.
ZTNA migration succeeds when identity remediation happens first.
A 180-user organisation across four sites was Microsoft 365-heavy, with FortiGate at each branch. VPN was generating Teams quality degradation, and an external review had identified contractor accounts with network-level access to systems they had no business reason to reach. The identity assessment found 28 stale accounts and MFA disabled on two service accounts.
Contractor access migrated to agentless ZTNA first, scoped to three specific applications. Internal remote users migrated by group over eleven weeks. VPN was retained for one legacy ERP application throughout, and full remote-user migration completed before VPN was decommissioned for that user group. This is the practical difference between buying a ZTNA product and sequencing a secure access transition.
In Australian environments, the decision usually turns on identity, assurance and legacy dependencies.
Microsoft Entra ID is usually the identity foundation
Most Australian organisations evaluating ZTNA already operate Microsoft 365 and Entra ID. That does not make Microsoft Entra Private Access automatically right, but it does mean the identity foundation is usually Microsoft-led. The first question is whether Entra ID is clean enough to carry the access model.
Essential Eight and cyber insurance change the frame
ZTNA is often raised during Essential Eight uplift, cyber insurance renewal or post-incident remediation. The value is not the acronym — it is the ability to show MFA coverage, device posture, scoped access, contractor control and access evidence in a way a traditional VPN model often cannot.
Legacy application dependency is usually the constraint
ZTNA migration is rarely blocked by the remote access platform itself. It is blocked by unclear application ownership, older protocols, poor documentation and identity debt. That is why application mapping and identity remediation sit before platform selection.
Most organisations asking the question are ready to start the assessment, not the deployment.
For organisations with clean Entra ID, enforced MFA and a hybrid workforce where VPN is causing daily friction or compliance problems, ZTNA migration is straightforward. The architecture is proven, the platforms are mature, and the migration path is predictable when identity is in order. The decision to start should not be delayed on the basis of platform evaluation. That is the last decision, not the first.
For organisations where identity infrastructure has not been maintained, ZTNA migration begins with identity remediation, not platform selection. ZTNA deployed on top of stale accounts and disabled MFA exceptions is a more expensive version of the same trust problem — and that outcome is preventable with the right sequence. The platform choice — Microsoft Entra Private Access, FortiSASE ZTNA, or another suited to the environment — is the last decision in that sequence, not the first. It follows the identity foundation and the application map rather than leading them.
Access model clarity is the benefit. Identity infrastructure debt is the trade-off.
The comparison is settled by your identity maturity and application estate, not by the technology argument.
Check your readiness →Questions that come up before replacing user-facing VPN.
Is ZTNA more secure than VPN?
What are the disadvantages of ZTNA compared to VPN?
What is replacing VPNs?
Does Microsoft have ZTNA?
What is the difference between ZTNA and IPSec VPN?
Does ZTNA require Microsoft Entra ID?
How long does ZTNA migration from VPN take?
Can ZTNA and VPN run in parallel during migration?
Why is ZTNA better than VPN?
Move from network trust to per-session verification.
A short review maps where VPN network trust still sits in your environment and sequences a ZTNA transition — identity, device posture and application-level access — without a disruptive cutover.
Scope a ZTNA transition