ZTNA is not a product. It is the access model that replaces implicit network trust.
Zero Trust Network Access, or ZTNA, gives users access to specific applications they are authorised to use, verified per session by identity, device posture and context. It does not give users broad network-level access. That is the architectural difference from VPN.
VPN grants an encrypted tunnel into a network segment after authentication. ZTNA grants access to a named application after identity, device health and policy are checked. Applications remain invisible to users who are not authorised for them. The result is a remote and hybrid access model that reduces lateral movement, improves contractor control and supports stronger evidence for security reviews, cyber insurance and Essential Eight alignment.
See the deployment sequence and timingWhat ZTNA is and how it differs from Zero Trust; the four enforcement mechanisms; ZTNA vs VPN positioning; where ZTNA sits inside SASE; identity and MFA prerequisites; deployment phases and Australian timing ranges; common deployment failures; and post-deployment operating requirements. For engineers, IT leaders and governance stakeholders assessing whether the access model has outgrown VPN — and what deploying ZTNA properly actually requires.
ZTNA readiness depends on identity, application fit and ownership.
ZTNA depends on clean users, accurate groups, MFA enforcement and identity lifecycle discipline.
MFA exceptions, shared accounts and unmanaged service accounts weaken the access model.
Cloud and web applications usually fit ZTNA more cleanly than legacy protocols.
Device posture checks depend on registration, compliance signals and endpoint management.
ZTNA and VPN usually run in parallel while user groups and applications are validated.
Access policy, group membership, connectors, break-glass procedures and contractor access need ongoing management.
ZTNA is the user-to-application access slice of Zero Trust.
ZTNA is the access control implementation of Zero Trust, not a product category to purchase. NIST SP 800-207 defines Zero Trust Architecture as eliminating implicit trust based on physical or network location, requiring discrete authentication and authorisation before session establishment, with ongoing evaluation of risk and posture. ZTNA is the user-to-application access slice of that architecture: the technology that enforces per-request, least-privilege access rather than broad network-level access granted once at authentication.
The distinction from VPN is architectural, not cosmetic. VPN grants network-level access after a single authentication event. ZTNA grants access to a named application after verifying identity, device posture and context on every session. A compromised credential under VPN can reach everything on the network segment it is permitted to access. A compromised credential under ZTNA can reach only the specific applications that user was explicitly authorised for, and it cannot move laterally.
Zero Trust is a security principle describing how access decisions should be made. ZTNA is how you enforce that principle for remote and hybrid access. What ZTNA changes about the access model:
- Access is granted to named applications, not to network segments
- Every session is independently verified by identity, device posture and context
- Applications are invisible to users who are not authorised to access them
- Lateral movement is architecturally prevented rather than policy-controlled
- Contractors and third parties are scoped to specific applications without network-level access
- Access policy is enforced consistently whether the user is in the office, at a branch or working remotely
ZTNA works when the access foundation is ready.
Not every organisation evaluating ZTNA is ready to deploy it today. The signals below distinguish situations where ZTNA is the right next conversation from situations where preparation work needs to happen first.
- Microsoft Entra ID is clean, MFA is enforced and device registration is in place
- VPN is causing daily performance issues or a security incident has exposed lateral movement risk
- Contractor or third-party access needs to be scoped to specific applications only
- Essential Eight ML2 or cyber insurance is driving stronger MFA and remote access evidence
- Microsoft 365 and Teams performance for remote users is affected by VPN backhaul
- SASE evaluation is underway and the access control layer needs to be established first
- Remote and hybrid work are the standard operating model, and application access should be governed by identity, device posture and role rather than network location
- Identity infrastructure is not mature: stale accounts, MFA exceptions, no device registration or inaccurate group membership
- Application inventory is incomplete, or most applications use non-standard protocols that cannot be cleanly brokered
- The organisation is under 50 staff with a simple single-site environment where VPN complexity is not a real problem
- There is no clear owner for access policy, group membership and connector management after deployment
- A hardened VPN with enforced MFA and split tunnelling is the proportionate answer for the current environment
- The organisation expects ZTNA to remove the need for application discovery or identity remediation
- Break-glass procedures have not been defined before VPN decommission is considered
A ZTNA environment needs a support model: an internal engineer with Microsoft Entra ID depth, or a managed provider with ZTNA deployment and migration experience; defined access policy ownership — who manages application entitlements and group membership ongoing; connector or gateway management for on-premises application access; break-glass procedures defined before VPN is decommissioned for any user group; regular review of contractor, third-party and privileged access; ongoing group membership, stale account and MFA exception review; connector monitoring, redundancy and update management; and audit reporting for insurers, Essential Eight reviews and internal governance.
That is not a reason to shelve ZTNA — it is the work that comes first. A readiness conversation tells you which side you are actually on.
Start with readiness →ZTNA replaces implicit network trust with per-session, per-application verification.
ZTNA is not a single product. It is a set of enforcement mechanisms working together. In NIST's logical model, a policy decision point evaluates identity and context signals and instructs a policy enforcement point to allow or deny the session. The broker or gateway sits near the application, not near the user, which is what makes application invisibility possible. Understanding what each mechanism does operationally matters because the failure modes are different for each one.
Identity-first access
Every access request is evaluated against the user's verified identity, not their network location. A user on the corporate LAN has the same access scope as the same user working remotely. The network provides no implicit trust elevation.
Identity-first access depends on clean users, accurate groups, enforced MFA, correct role assignment and clear ownership of identity lifecycle.
Application-level micro-segmentation
Access is granted to a specific named application, not to a network subnet. Users cannot enumerate other resources on the same network, enumerate file shares or reach systems they have no explicit authorisation for.
This removes lateral movement as an attack path for the ZTNA-protected application set.
Continuous verification
Trust is not established once at login and held for the session duration. Device posture, user behaviour and context signals are evaluated continuously. A device that falls out of compliance during a session can have access revoked without requiring re-authentication from the user.
Continuous verification depends on device registration, device compliance signals and policies that respond to risk, not only identity.
Removal of implicit trust
No network segment is treated as inherently trusted. An internal network, a VPN tunnel or a direct office connection grants no default privileges. Every request is evaluated against policy regardless of where it originates.
This is where ZTNA differs most clearly from legacy remote access.
The difference is not encryption. It is what is trusted and how broadly.
Both VPN and ZTNA encrypt traffic. VPN's core problem is not technical inadequacy. It was designed for a different world: occasional remote access to on-premises applications by a small number of users. The architectural assumption built into VPN is that a user who authenticates successfully is trusted to access the network. That assumption becomes a liability when the workforce is permanently hybrid, applications are cloud-hosted and attackers specifically target VPN credentials to move laterally inside the network perimeter.
ZTNA does not solve VPN's encryption problem. It solves VPN's trust scope problem: the assumption that successful authentication justifies network-level access. VPN still has a place:
- Site-to-site connectivity between offices and data centres
- Access to legacy applications that cannot be fronted by an identity-aware proxy
- Environments where identity infrastructure is not mature enough to support ZTNA properly
- Smaller environments where hardened VPN is proportionate and manageable
ZTNA is a component of SASE, not a competing architecture.
SASE converges network connectivity — primarily SD-WAN — with cloud-delivered security services including ZTNA, Secure Web Gateway, CASB and Firewall as a Service. ZTNA is the user-to-application access layer within that architecture. An organisation can deploy ZTNA standalone as a VPN replacement before committing to full SASE. A fully deployed SASE architecture always includes ZTNA as its access control layer.
For most Australian organisations, the practical progression is: harden VPN first; clean identity and device posture; deploy ZTNA for remote users as a standalone project once identity is ready; retain VPN for legacy applications that cannot be brokered; then expand to full SASE as SD-WAN and cloud security are addressed. Attempting to deploy all SASE components simultaneously consistently produces scope overrun and partial deployments. See SASE deployment and SASE vs VPN vs Zero Trust for the wider architecture.
Fortinet FortiSASE
Best fit where FortiGate is already deployed at the branch. ZTNA enforcement is built into FortiOS, so the access layer extends an existing platform rather than adding a separate product. A natural starting point for SD-WAN-first environments where Fortinet already handles the edge.
Zscaler Private Access
Best fit for cloud-first organisations with no on-premises network dependency. Applications are never exposed to the internet directly. Suited to environments where identity is mature and the application estate is primarily SaaS and cloud-hosted.
Palo Alto Prisma Access
Best fit where Palo Alto is already in use for perimeter or endpoint security. ZTNA and broader SASE capabilities sit within a single management framework. Integration overhead may be higher for environments outside the Palo Alto ecosystem.
ZTNA is overdue when the access model has outgrown VPN.
ZTNA is the right decision when specific operational problems are present, not when a vendor roadmap says it is time to upgrade. These observable situations indicate that ZTNA is overdue, not just desirable.
VPN has become a daily performance and helpdesk problem, not an occasional inconvenience. The access model was designed for occasional remote access, but the operating model has become permanently hybrid.
A security incident, audit or risk review has exposed that VPN credentials could allow access beyond the intended entry point. ZTNA reduces this risk by granting application-level access, not network-level access.
Contractor or third-party access is managed through VPN credentials, shared accounts or accounts that are not tied to named individuals. ZTNA allows contractors to reach only the applications they are authorised to use, with no network-level visibility.
Cyber insurance renewal or Essential Eight assessment has raised stronger MFA, privileged access and remote access evidence as requirements the current VPN setup cannot satisfy cleanly. ZTNA supports these controls when identity hygiene is resolved first.
Remote users experience Teams degradation or Microsoft 365 friction because traffic is backhauled through a central VPN concentrator. ZTNA can reduce access friction for cloud and web applications when deployed alongside appropriate internet access and identity controls.
The organisation is evaluating SASE, and the access control layer needs to be established before branch connectivity and internet traffic policy are addressed. ZTNA can be the first practical step toward SASE without forcing all components into one project.
The identity and application assessment comes before platform selection.
ZTNA deployment in Australian organisations consistently follows the same pattern when it goes well: identity infrastructure is assessed and remediated first; application dependencies are mapped before the platform is chosen; ZTNA is deployed in parallel with VPN rather than cutting over; user groups are migrated progressively; legacy application exceptions are handled explicitly; and VPN is decommissioned by user group only after validation.
Audit Microsoft Entra ID for stale accounts, disable or remediate service accounts without MFA, enforce phishing-resistant MFA for all users, and complete device registration. This phase is required before ZTNA delivers its security model.
List every application remote users access. Confirm whether each application is cloud-hosted or on-premises, identify which applications require a connector or gateway, and flag legacy applications that may need VPN retained in parallel. This step determines what can move to ZTNA, what needs remediation and what should remain on VPN temporarily.
Deploy ZTNA alongside the existing VPN. Migrate one user group first. Validate that all required applications are accessible, that performance is acceptable and that support paths are understood. Confirm break-glass procedures before proceeding.
Migrate user groups systematically. Retain VPN for legacy application access during the overlap period. Do not set a hard VPN decommission date until all user groups have been stable on ZTNA for the required validation period.
Typical deployment timing: where Microsoft Entra ID is clean and MFA is already enforced, ZTNA deployment for remote users typically takes 8 to 14 weeks from decision to first user group migration. Where identity hygiene work is required first, the total timeline extends to 16 to 28 weeks. Full remote-user migration from VPN to ZTNA across all user groups typically takes 12 to 18 months, running both in parallel during the transition to allow for legacy application exceptions and validation before each group is cut over.
Most ZTNA failures are readiness and sequencing failures.
These are not generic warnings. They are the specific situations that create rework, project failure, or a deployment that looks like ZTNA but inherits the same trust problems as the VPN it was meant to replace.
Stale accounts, shared accounts, unmanaged service accounts, MFA exceptions and inaccurate group membership undermine the access model. ZTNA cannot enforce a clean access decision if the identity layer is not clean. Fix: complete identity remediation before any ZTNA platform is selected.
Hard cutover dates create operational risk. VPN should remain available until every user group has been validated on ZTNA and legacy application exceptions have been handled explicitly. Fix: define VPN decommission by user group, not by date.
Licensing before dependency mapping often leads to a platform that does not fit the application estate. Applications using non-standard protocols, legacy authentication or unmanaged dependencies may need connectors, remediation or VPN retention. Fix: complete application dependency mapping before platform selection.
On-premises access through ZTNA requires connector or gateway design. Connector capacity, redundancy, maintenance windows and monitoring need to be planned before production rollout. A single undersized connector can become the new access bottleneck. Fix: design connector capacity, redundancy and monitoring as a deliverable, not an afterthought.
If the identity provider or ZTNA platform is unavailable, protected applications may become inaccessible. Break-glass procedures need to be defined and tested before VPN is removed for any user group. Fix: test break-glass paths before VPN decommission begins.
ZTNA holds only while it is actively maintained.
ZTNA is not a one-time deployment. The security model only holds while access policy, group membership, connector availability and identity hygiene are actively maintained. A ZTNA environment that is deployed correctly but operated without ongoing attention drifts into the same trust problems it was deployed to solve.
Access policy maintenance. Application entitlements are reviewed against role changes and joiner-mover-leaver events. Group membership must reflect current authorisation, not historical access.
Identity lifecycle hygiene. Stale accounts are identified and remediated on a rolling cadence. MFA exceptions are audited. Service accounts are kept current with appropriate controls and phishing-resistant MFA enforced where applicable.
Connector availability. On-premises connectors are monitored for health, with redundancy verified. Connector firmware is kept current. Maintenance windows are planned to avoid access outages.
Break-glass procedure review. Break-glass access for critical systems is tested periodically. Runbooks are updated as the application estate changes. Identity provider failover paths are verified.
Contractor and third-party access review. Agentless access scopes are reviewed against current engagements. Off-boarded contractors are removed promptly. Application entitlements are scoped to current need rather than historical permission.
A ZTNA rollout starts with identity cleanup, not platform selection.
A 180-user organisation across four sites was Microsoft 365-heavy with FortiGate already deployed at each branch. VPN was generating Microsoft Teams quality complaints and a recent external audit had identified contractor accounts with network-level access to systems they had no business reason to reach.
The identity review found 28 stale accounts, MFA disabled for two shared service accounts and no device registration in Microsoft Entra. Identity remediation ran for 5 weeks before ZTNA deployment began. Contractor access was migrated to agentless ZTNA first, then internal remote users by group. VPN was retained for one legacy ERP application that used a non-standard authentication model.
Full remote-user migration completed over 11 weeks from pilot start. The contractor accounts that previously had network-level access were scoped to three specific applications post-migration. This is the practical difference between deploying a ZTNA product and sequencing a secure access transition.
ZTNA delivers on its security promise only when the identity layer is clean.
The technology is the easy part. The identity work is where most deployments slow down or stall.
For organisations with mature Microsoft Entra ID, enforced MFA and a hybrid workforce that has outgrown VPN, ZTNA is a straightforward transition that improves both security posture and application performance. The architecture is well understood, the platforms are proven and the migration path is predictable when identity is in order.
For organisations where identity hygiene has not been maintained, ZTNA becomes a project that spends its first phase cleaning up the foundation rather than deploying the access model. Both outcomes are achievable. The difference is in how honestly the readiness is assessed before the platform is selected.
The failure mode we see repeatedly is deploying a ZTNA platform while MFA exceptions remain in place and stale service accounts are left unaddressed. The access model looks like Zero Trust. The risk profile is still a credential theft problem waiting for a specific target.
ZTNA deployment needs to be designed for the identity environment. Inlight IT helps Australian organisations assess, design and operate ZTNA across Microsoft Entra Private Access, Fortinet FortiSASE, Zscaler Private Access and Palo Alto Prisma Access environments where suited — the recommendation follows the identity foundation, application architecture and operating model, not a vendor relationship. That covers identity readiness assessment (Microsoft Entra ID audit, MFA coverage, device registration and stale account identification before any platform is selected); application dependency mapping (which applications can be brokered, which need connectors and which require VPN to remain in parallel); platform fit recommendation based on identity infrastructure, existing network equipment and operational capability; phased deployment with parallel ZTNA and VPN operation, pilot validation and progressive migration; and ongoing managed operation of access policy, group membership, connector availability and break-glass review. Where the wider network position is unclear, a Network Review can place ZTNA inside the whole operating picture first.
Access model clarity is the benefit. Identity infrastructure debt is the trade-off.
Questions that come up before deploying ZTNA.
Is ZTNA the same as Zero Trust?
No. Zero Trust is an architectural principle: eliminate implicit trust based on network location and require per-request authentication and authorisation. ZTNA is the access control technology that implements that principle for user-to-application access. Zero Trust describes the policy. ZTNA is how you enforce it for remote and hybrid access scenarios.
Does ZTNA replace VPN entirely?
ZTNA replaces user-facing remote access VPN. Site-to-site VPN between offices and data centres is typically replaced by SD-WAN rather than ZTNA. Legacy applications that cannot be fronted by an identity-aware proxy may require VPN to remain in parallel for years. Most organisations run ZTNA and VPN alongside each other for 12 to 24 months during migration, with VPN retained for specific legacy application access throughout.
What is the difference between agent-based and agentless ZTNA?
Agent-based ZTNA requires a client installed on the endpoint. This enables device posture assessment and supports most application types, including non-web applications. Agentless ZTNA works through a browser without a client install. It is useful for third-party and contractor devices, but it cannot assess device posture as deeply and is typically limited to web-based or application-proxied access. Most ZTNA deployments use agent-based access for corporate-managed devices and agentless access for contractors.
How does ZTNA handle on-premises application access?
On-premises application access through ZTNA requires a connector or gateway deployed in the on-premises environment that the ZTNA broker routes sessions through. The connector establishes an outbound tunnel to the ZTNA platform, so the application does not need an inbound firewall opening. Legacy applications using non-standard protocols or Kerberos without modern identity federation may not be viable ZTNA candidates without additional configuration or remediation.
What identity infrastructure is required before deploying ZTNA?
ZTNA requires a functioning identity provider with enforced MFA, clean user account hygiene, no stale or shared accounts, device registration so posture can be assessed at each session, and group membership that accurately reflects role-based access requirements. Microsoft Entra ID is the most common identity provider in Australian deployments. These requirements must be in place and verified before ZTNA deployment begins, not configured as a parallel workstream.
What happens if the identity provider goes down?
If the identity provider is unavailable, ZTNA cannot authenticate new sessions and access to protected applications is blocked. This is the most significant operational risk in a ZTNA deployment. Mitigation requires high-availability configuration for the identity provider, break-glass access procedures for critical systems, and clear operational runbooks covering what to do when authentication is unavailable. Break-glass procedures must be tested before VPN is decommissioned for any user group.
How does ZTNA support Essential Eight compliance?
ZTNA supports several Essential Eight control areas, but it does not make an organisation compliant on its own. ZTNA supports Multi-Factor Authentication by enforcing MFA as part of each access decision. It supports Restrict Administrative Privileges by granting application-specific access rather than broad network access, reducing lateral movement paths for privileged accounts. The identity hygiene work required to make ZTNA function properly also addresses several access-control prerequisites. Architecture alone does not satisfy compliance. ZTNA deployed without remediating identity gaps satisfies the checkbox but not the control.
How long does ZTNA deployment take for an Australian multi-site organisation?
Where Microsoft Entra ID is clean and MFA is already enforced, ZTNA deployment for remote users typically takes 8 to 14 weeks from decision to first user group migration. Where identity hygiene work is required first, the total timeline extends to 16 to 28 weeks. Full remote-user migration from VPN to ZTNA across all user groups typically takes 12 to 18 months, running both ZTNA and VPN in parallel during the transition to allow for legacy application exceptions and validation before each group is cut over.
Check identity readiness before choosing the platform.
One conversation covers Entra ID, MFA coverage, application dependencies and the migration path — before anything is licensed.
Discuss SASE and Zero Trust