Zero Trust is the principle. ZTNA is the implementation. SASE is the architecture that operationalises it at scale.
SASE, VPN and Zero Trust are often discussed as if they are interchangeable. They are not. For most Australian organisations, the right question is not “Should we buy SASE?” It is whether the environment is ready to move from network-level remote access to identity-led, application-level access — and if so, whether that starts with hardened VPN, ZTNA, SSE or full SASE.
See what decision you are actually makingVPN, ZTNA, Zero Trust and SASE definitions; where VPN still fits; when ZTNA should replace user-facing VPN; when full SASE is justified; identity and application prerequisites; Essential Eight and cyber insurance implications; migration sequence and parallel operation; and Microsoft Entra SSE, Fortinet FortiSASE and combined architecture fit. Written for Australian organisations weighing remote access and secure network architecture decisions.
The right architecture depends on what the environment can support now.
The common mistake is selecting an architecture based on what vendors say is the next step rather than what the environment can actually support. ZTNA and SASE require clean identity infrastructure as a prerequisite — deploying either without that foundation produces a more complex environment without a proportionate security improvement.
- Identity infrastructure maturity — ZTNA and SASE require clean identity, enforced MFA, accurate groups and device registration.
- Application environment — cloud and web applications suit ZTNA and SASE more cleanly than legacy protocols and on-premises dependencies.
- Remote workforce scale — VPN remains practical for small occasional remote access. ZTNA and SASE fit permanent hybrid work better.
- Multi-site complexity — branch connectivity, SD-WAN and cloud security requirements determine whether full SASE is justified.
- Compliance posture — Essential Eight, insurer scrutiny, post-incident remediation and contractor access can accelerate the decision.
- Operational capability — ZTNA and SASE need ongoing policy ownership, identity hygiene, access reviews and platform operation.
This is not a question of old versus new.
VPN, ZTNA, Zero Trust and SASE are related, but they answer different questions.
VPN creates an encrypted tunnel that grants network-level access after one authentication event. It is still appropriate for simpler estates: smaller organisations, fewer sites, primarily on-premises applications and limited remote workforce requirements.
VPN also remains practical where identity infrastructure is not yet ready to support ZTNA properly.
Zero Trust Network Access replaces broad network access with application-level access. Users are granted access only to the specific applications they are authorised for, verified per session by identity, device health and context.
ZTNA is the most direct replacement for user-facing remote access VPN when identity infrastructure is mature enough.
SASE combines SD-WAN with cloud-delivered security services, including ZTNA, Secure Web Gateway, CASB and Firewall as a Service.
It is the broader architecture for distributed, cloud-first organisations that need branch connectivity, remote access, internet security and SaaS visibility under a consistent policy framework.
Zero Trust is not something to buy. It is the principle that access should not be granted implicitly because a user is on a network, has connected through a VPN or has authenticated once.
Access should be verified explicitly, scoped to the application and assessed continuously using identity, device and context.
VPN, ZTNA and SASE assume different things about users, applications and trust.
VPN, ZTNA and SASE represent progressively different assumptions about where users are, where applications live and how trust should be granted.
- VPN assumes users are occasionally remote and applications are on-premises.
- ZTNA assumes users are regularly remote or hybrid, applications are cloud-hosted or accessible via an identity broker, and credentials alone cannot be trusted.
- SASE extends this to the full network and security layer: all user traffic, all branch traffic and all cloud application access under one consistent policy model.
VPN creates an encrypted tunnel into the network. After the user authenticates, they usually receive access to a network segment. Access is then controlled by routing, firewall policy and application permissions. The limitation is that the model grants network proximity before application-specific need is verified.
VPN is simple and familiar, but it was designed for occasional remote access — not permanent hybrid work, distributed SaaS use and contractor access.
Zero Trust is the principle. ZTNA is the access technology that applies it to remote access. ZTNA grants access to specific applications instead of the network. Each session is evaluated using identity, MFA, device posture, role, location and context.
The security value comes from removing implicit network trust. A compromised credential cannot move laterally across the network if the user never receives network-level access in the first place.
SASE is the architecture that combines network and security functions into a cloud-delivered model. It includes:
- SD-WAN — branch connectivity and application-aware routing
- ZTNA — identity-based application access
- Secure Web Gateway — internet traffic inspection
- CASB — SaaS visibility and control
- Firewall as a Service — distributed firewall policy
SASE is usually the direction for organisations where hybrid work, branch connectivity, cloud applications, SaaS governance and identity-led access all need to be managed together.
Each model solves a different layer of the problem.
Compare the three models across the same dimensions: what each is, the access model it enforces, where it fits best, its main risk, how it performs and how the transition is approached.
- Access model — network-level access after authentication
- Best fit — smaller environments, on-premises apps, limited remote users, legacy access and site-to-site tunnels
- Main risk — compromised credentials can enable lateral movement across permitted network segments
- Performance — can degrade SaaS and Microsoft 365 if traffic is backhauled through a VPN concentrator
- Transition approach — harden first where replacement is not yet justified
- Access model — application-level access per session, verified by identity, device and context
- Best fit — hybrid workforce, contractor access, Microsoft 365-heavy environments and VPN replacement
- Main risk — depends on clean identity, accurate groups, enforced MFA and device posture
- Performance — better for application-specific access where apps are cloud-hosted or brokered
- Transition approach — deploy alongside VPN and migrate by user group
- Access model — consistent access, internet security and branch policy across users, sites and cloud apps
- Best fit — distributed organisations needing SD-WAN, ZTNA, SWG, CASB and FWaaS under one policy model
- Main risk — scope overrun if deployed before identity, application and SD-WAN readiness are understood
- Performance — stronger for distributed SaaS and branch use when cloud-edge inspection is designed properly
- Transition approach — phase over time: identity, ZTNA, SD-WAN, SWG, CASB and FWaaS as readiness matures
SASE is strongest when users are distributed, applications are cloud-first and the environment is ready for it.
SASE addresses the performance problem VPN creates for cloud applications by routing traffic directly to cloud edges rather than backhauling it through a central concentrator. For organisations where Microsoft 365, Teams and SaaS applications are the primary workload, the performance improvement is architectural rather than incremental.
The security improvement is also architectural. ZTNA removes the implicit network trust that makes compromised VPN credentials so damaging. A credential compromised under ZTNA reaches only the applications that user was explicitly permitted to use and cannot move laterally across the network.
SASE also changes the network operating model, not just the access model. Traffic is inspected at the cloud edge rather than at a central data centre. Branch offices break out directly to the internet under consistent policy rather than backhauling through a concentrator. SaaS pathing improves, user experience becomes more consistent, and policy management shifts from per-device configuration to a centralised policy framework.
- The organisation is under 100 staff with a single or two-site footprint
- Applications are primarily on-premises and remote workers are a small minority
- Identity infrastructure is not yet mature enough to support ZTNA properly
- Operational simplicity is a genuine constraint and SASE overhead is not justified
- No specific compliance or security driver is forcing the architecture decision
- VPN can be hardened with MFA, split tunnelling, tighter segmentation and documented access review
- Hybrid or remote work is permanent and VPN performance is causing friction
- Microsoft 365, Azure or SaaS platforms are the primary application environment
- Identity infrastructure is mature, with enforced MFA and clean account hygiene
- A compliance requirement or security incident has exposed the VPN trust model
- Third-party or contractor access needs to be scoped to specific applications only
- Branch connectivity, internet security and cloud application access need a consistent policy framework
The scenarios that cover most Australian organisation situations.
The right architecture depends on where the organisation actually sits today. None of these scenarios requires the newest technology. All require an honest assessment of the current environment before selecting a platform. The most common error is deploying ZTNA or SASE as a compliance exercise without resolving the identity infrastructure it depends on. Clean Entra ID, enforced MFA and device registration are prerequisites, not afterthoughts.
This usually applies where the organisation has under 100 staff, one or two sites, VPN working adequately and primarily on-premises applications.
What to do:
- Harden the existing VPN rather than replace it immediately
- Enforce MFA on every VPN authentication
- Implement split tunnelling for cloud traffic where appropriate
- Tighten network segments accessible via VPN
- Revisit ZTNA when workforce scale, application mix or complexity grows
This usually applies where the organisation has 100 to 300 staff, multiple sites, Microsoft 365-heavy applications and hybrid work as standard.
What to do:
- Deploy ZTNA as a VPN replacement for remote access
- Confirm prerequisites: clean Entra ID, enforced MFA and device registration
- Migrate users off VPN progressively, not all at once
- Keep site-to-site VPN for branch connectivity during transition where required
- Treat full SASE as the next phase once ZTNA is stable
This usually applies where the organisation has 200 to 600 staff, a distributed workforce, SD-WAN under evaluation and branch connectivity as a current concern.
What to do:
- Plan full SASE direction over 18 to 24 months
- Deploy or stabilise SD-WAN first if branch connectivity is a current problem
- Add ZTNA for remote users
- Add Secure Web Gateway and CASB as governance requirements mature
- Use Fortinet Security Fabric where FortiGate is already deployed and the operating model supports it
- Confirm internal or managed engineering capability to operate the environment after go-live
This applies at any size where Essential Eight uplift, cyber insurance pressure, post-incident remediation or contractor-access risk is accelerating the decision.
What to do:
- Identify which control is driving the requirement
- Map the current access model against that control
- Resolve identity and MFA gaps before platform selection
- Scope privileged access and third-party access at application level
- Avoid using SASE language to satisfy a checkbox while leaving VPN trust risk unchanged
Most failures come from sequencing, not technology.
Stale accounts and MFA exceptions mean ZTNA inherits the same trust problems as VPN. The platform changes. The risk model does not.
Fix: identity remediation runs first, not as a parallel workstream.
Attempting all components simultaneously consistently produces scope overrun. SASE is a target architecture. The migration path should be staged.
Fix: sequence identity, ZTNA, SD-WAN, SWG and CASB as readiness matures.
Legacy applications may not be viable ZTNA candidates.
Fix: complete application dependency mapping before platform selection.
Hard cutovers without parallel validation consistently produce application access gaps.
Fix: decommission VPN by user group, not by fixed calendar date.
This can create a dual-vendor SASE architecture by accident.
Fix: existing stack matters, but platform selection should follow identity, application and operating-model fit.
Zero Trust is an access model, identity model and operating discipline.
Fix: stop treating Zero Trust as a SKU. The principle is enforced through policy, identity and operating practice, not purchased through a product labelled Zero Trust.
ZTNA replaces user-facing VPN. SASE replaces the architecture VPN used to sit inside.
ZTNA is replacing VPN as the remote access model for organisations where identity infrastructure is mature enough to support it. The access layer is shifting from network-level trust granted at the perimeter to application-level access granted per session, per user, per device.
At the broader architectural level, SASE is replacing the combination of MPLS-backhauled WAN, perimeter firewalls and split VPN that many organisations built through the 2000s and 2010s. The architecture that served a world of central data centres and office-bound workers does not serve a world of cloud applications and distributed teams. The same shift is visible at the network layer, where secure SD-WAN is displacing traditional single-carrier WAN designs.
Site-to-site VPN between offices and data centres will remain in many environments for years, particularly where legacy applications cannot be accessed via an identity-aware broker. User-facing remote access VPN is what is being displaced: faster in cloud-first organisations, slower in those with on-premises application dependencies.
Are VPNs becoming obsolete? The decline is real, but uneven:
- User-facing remote access VPN — being displaced by ZTNA in many Australian environments over 18 to 36 months.
- Site-to-site VPN between offices — being displaced by SD-WAN overlays within SASE architectures.
- Site-to-site VPN to legacy data centres — remains appropriate where legacy systems cannot be fronted by ZTNA.
- VPN in small single-site environments — remains practical where ZTNA complexity is not justified.
- VPN for specific on-premises application access — may remain in parallel with ZTNA during long migration windows.
SASE and ZTNA can support Essential Eight controls, but they do not automatically deliver compliance.
This comparison often becomes practical when Essential Eight, cyber insurance, insurer questionnaires or post-incident remediation put pressure on remote access controls. SASE and ZTNA can support several Essential Eight controls, but they do not automatically deliver compliance. The outcome depends on identity hygiene, device compliance, group membership accuracy and operational discipline.
VPN with weak or inconsistent MFA is usually the first control gap to surface. ZTNA and SASE improve the model by enforcing MFA and Conditional Access per session, but only if MFA coverage is complete and exceptions are controlled. VPN with SMS MFA does not satisfy higher-maturity expectations where phishing-resistant MFA is required.
ZTNA's application-level segmentation prevents privileged accounts from having broad network access beyond what they need. Administrative access can be scoped to specific applications and sessions rather than broad VPN access into a network segment.
SASE's Secure Web Gateway and CASB provide application-level visibility and enforcement. This covers which SaaS applications are accessible, what data can be uploaded and where AI or browser-based tools sit outside policy.
ZTNA's device posture checks can identify unpatched or non-compliant devices before access is granted. This does not replace patch management, but it creates a parallel enforcement point that prevents unmanaged or unhealthy devices from accessing sensitive applications.
Identity cleanup came before platform selection.
A multi-site branch operations group was Microsoft 365-heavy with FortiGate already at each branch. VPN was causing Microsoft Teams degradation and generating consistent support tickets during peak hours. Before any ZTNA platform was selected, an identity review found 34 stale accounts, MFA disabled for three service accounts and no device registration policy in place. Identity cleanup ran for six weeks before ZTNA deployment began.
ZTNA was piloted with one user group first. VPN remained in place for a legacy ERP application throughout. Full remote-user migration to ZTNA was completed across 14 weeks from pilot start. The VPN concentrator remained active for the legacy application and site-to-site connectivity throughout.
This is the difference between replacing a remote access product and sequencing a secure access transition.
The right starting point is an access architecture review before selecting a platform.
The decision between VPN, ZTNA and SASE is not primarily a technology comparison. It is an assessment of where the environment sits today — identity hygiene, application dependencies, site architecture, remote workforce scale, branch connectivity and operational capability. Those inputs determine which platform fits and what work is required before deployment begins.
- Assess fit before vendor evaluation — organisations that skip the assessment and go directly to vendor evaluation consistently discover, after purchase, that the deployment requires more prerequisite work than the sales process acknowledged. The vendor roadmap describes the ideal-state deployment. It does not describe what the environment needs first.
- Identity work is the prerequisite, not a parallel project — MFA gaps, stale accounts and on-premises application blockers need to be identified before purchase, not after. The identity remediation work required to make ZTNA function also satisfies several Essential Eight controls at the same time.
- Most organisations need ZTNA before SASE — the typical pattern is identity remediation, then ZTNA as VPN replacement, then SD-WAN if branch connectivity is a current concern, then Secure Web Gateway and CASB as governance requirements mature. Attempting all components simultaneously consistently produces scope overrun.
- Run VPN and ZTNA in parallel during transition — parallel operation is not a compromise. It is the correct approach. Most organisations operate both for 12 to 36 months. Hard cutovers without parallel validation consistently produce application access gaps.
- Match vendor to existing stack — where FortiGate is already deployed, Fortinet Security Fabric is often the operationally cleanest path. Where Microsoft 365 and Entra ID dominate, Microsoft Entra Internet Access and Private Access are the natural progression. Mixing vendors at each SASE layer is viable, but operationally more complex.
Architectural readiness is the benefit. Identity and operating-model discipline is the trade-off.
If a compromised password would reach more than the applications that user actually needs, the environment is still running on network-level trust — whatever the remote access product is called.
Test the access model →Where Inlight IT works alongside the team:
Entra ID health, MFA coverage, stale accounts, group accuracy and device registration.
Current VPN usage, application access paths, legacy dependencies and user group requirements.
Application-level access, pilot group selection, rollback plan, staged user migration and the VPN coexistence period.
SD-WAN, Secure Web Gateway, CASB, Firewall as a Service, identity policy and the operating model for ongoing policy, identity and access review.
Microsoft Entra SSE, Fortinet FortiSASE, Fortinet Security Fabric or combined architecture against the current environment.
Remote access architecture mapped to evidence, MFA, privileged access and application control requirements, including post-incident remediation drivers.
Questions that come up before replacing VPN or planning SASE.
Are SASE and Zero Trust the same thing?
How long does a VPN to SASE migration take?
What identity infrastructure is required before deploying ZTNA?
How does SASE handle on-premises application access?
Does SASE require replacing existing SD-WAN?
Does Microsoft have a SASE product?
How does ZTNA handle third-party and contractor access?
Is VPN obsolete?
Does SASE replace SD-WAN?
When should we run this comparison properly?
Review access architecture before choosing the platform.
A practical review of identity readiness, VPN dependencies, ZTNA suitability, SASE fit, application access and migration sequence before selecting a platform.
Discuss SASE and Zero Trust