Remote SupportThe Short Version
ZTNA gives users access to specific applications based on identity and device posture, never to the underlying network. There is no broad tunnel into the corporate LAN. A compromised endpoint cannot pivot to other systems, because there is no network to pivot across.
For most Australian SMBs, ZTNA is the practical answer to remote access in 2026. It is also a prerequisite for serious progress on zero trust architecture.
Why Legacy VPN Fails in 2026
Flat network access by default
Once a VPN client connects, it often has routable access to large swathes of the corporate network. Attackers love this.
No device posture checks
A compromised home laptop with a valid VPN cert gets the same access as a fully managed corporate device.
Credential theft is trivial
Stolen VPN credentials without MFA plus legacy protocols equals a ransomware rehearsal.
Split tunnelling confusion
Either performance is bad because everything tunnels, or security is bad because nothing does.
No application-level visibility
VPN logs show IP-to-IP traffic. They do not show which user accessed which app, when, from which device.
Scaling pain
Remote workforce spikes exceeded VPN concentrator capacity during COVID. The hardware is still expensive.
What ZTNA Actually Is
ZTNA enforces access decisions per application, based on continuous verification of identity and device posture. No implicit trust from network location. No broad network access.
- Identity-aware: the user is authenticated against your identity provider (usually Entra ID) with MFA, every session.
- Device-verified: the device must be compliant in Intune (or equivalent MDM) with patching, encryption, and EDR healthy.
- Application-specific: access is granted to an app, not a network. The user can reach the HR system but not the accounting server.
- Continuously evaluated: signals are rechecked throughout the session. If posture drops, access is withdrawn.
- Invisible to the internet: on-premises apps do not need a public IP. The ZTNA connector reaches out to the cloud broker.
How It Works
1. Connector deployed in your environment
Small connector VM or container runs inside your network, reaches out to the ZTNA cloud. No inbound firewall rules needed.
2. Apps published through the connector
You define each application. RDP host, internal web app, SSH target, SMB share, line-of-business system.
3. User authenticates via the ZTNA client or browser
Identity provider (usually Entra ID) authenticates the user, enforces Conditional Access, performs MFA.
4. Device posture evaluated
Is Intune compliance green? Is EDR healthy? Is the OS patched? If not, access denied or limited.
5. Traffic brokered per application
The ZTNA broker stitches the user session to the app. No routable network access to anything else.
6. Session continuously re-evaluated
Identity, device, and risk signals are rechecked. If anything degrades, the session is terminated.
Vendor Landscape
Microsoft Entra Private Access
Best fit for M365 tenants already running Entra ID P1 or P2. Tight Conditional Access integration. Licensed via Microsoft Entra Suite.
Cloudflare Access / Cloudflare One
Strong for web apps and SSH. Excellent Australian edge coverage. Per-user pricing is competitive for SMBs.
Zscaler Private Access
Enterprise-grade with the deepest posture signals. Higher cost, geared toward larger deployments.
Cisco Secure Access (Duo Network Gateway)
Good fit if already invested in Duo and Cisco. Strong identity integration.
Fortinet ZTNA (via FortiClient)
Sensible if you already run FortiGate. Policy lives on the firewall. Works best for existing Fortinet shops.
Tailscale / Twingate
Developer-friendly, WireGuard-based. Great for technical teams and smaller deployments. Less mature for compliance-heavy environments.
Migration Plan
- Inventory what uses the VPN. Applications, hosts, RDP sessions, file shares, line-of-business systems.
- Pick the pilot app. Something important but not mission-critical. Usually an internal web app or RDP to a jump host.
- Deploy the ZTNA connector. Small VM or container in each location that hosts apps.
- Publish the pilot app. Onboard a friendly group of users. Measure performance, authentication experience, and support tickets.
- Phase the rollout. Apps in order of risk and complexity. SaaS-delivered apps stay on direct access with Conditional Access.
- Retire VPN access by user group. As each group moves, their VPN access is revoked. No parallel access for long.
- Decommission VPN concentrators. Once all users are on ZTNA, the VPN goes.
Common Pitfalls
Treating ZTNA as a like-for-like VPN replacement
If you publish "the entire subnet" as one app, you have rebuilt a VPN with extra steps. Publish per application.
Skipping device compliance
ZTNA without device posture is just MFA in a trench coat. Intune compliance is the backbone.
Running ZTNA and VPN in parallel forever
Users will pick the path of least resistance. Set a hard VPN decommission date.
No monitoring or logging plan
ZTNA logs are gold for incident response. Pipe them into your SIEM from day one.
Forgetting third parties and contractors
External identities need ZTNA too. Entitlement management in Entra ID helps.
Retire Your Legacy VPN
We design and deploy ZTNA rollouts with Entra Private Access, Cloudflare, Zscaler, or Cisco Secure Access. Start with the highest-risk app and phase from there.