Zero Trust Network Access vs Traditional VPN: A Practical Migration Guide

For years, the Virtual Private Network (VPN) has been the default way to give remote staff access to internal systems. But as Kiwi businesses embrace hybrid work, cloud apps, and contractor-heavy teams, the cracks in VPN architecture are starting to show. Zero Trust Network Access (ZTNA) is rapidly replacing legacy VPNs — and for good reason.

This guide explains the practical differences between ZTNA and traditional VPNs, why the shift matters for New Zealand organisations, and how to plan a sensible migration without disrupting your team.

What's Wrong With Traditional VPNs?

Traditional VPNs were designed for a world where most of your apps and data sat in a single office data centre. When a user connects, they're typically dropped onto the corporate network with broad access — a model often described as "castle and moat".

The problems with this approach include:

  • Over-broad access: Once authenticated, users can often reach far more than they need.

  • Lateral movement risk: If credentials are stolen (a common outcome of phishing), attackers can roam freely.

  • Performance issues: Backhauling cloud traffic through a VPN concentrator in Auckland or Sydney adds latency.

  • Poor user experience: Reconnecting, dropped tunnels, and slow speeds frustrate staff.

  • Limited visibility: Most VPNs don't log application-level activity.

For New Zealand SMEs running Microsoft 365, Xero, Hubdoc, or sector-specific SaaS, forcing all traffic through a VPN tunnel rarely makes sense anymore.

What is Zero Trust Network Access?

ZTNA is built on a simple principle: never trust, always verify. Instead of giving authenticated users access to a network, ZTNA grants access to specific applications, based on continuous evaluation of identity, device posture, and context.

Key differences at a glance

CapabilityTraditional VPNZTNATrust modelNetwork-levelPer-applicationDefault accessBroadLeast privilegeDevice checksOne-timeContinuousCloud-friendlyNoYesLateral movement riskHighLowUser experienceOften poorSeamless

Why NZ Businesses Are Making the Move

A few local drivers are accelerating ZTNA adoption:

  • NZISM and Privacy Act 2020 alignment: Stronger access controls help demonstrate reasonable security safeguards.

  • Cyber insurance: Insurers increasingly expect MFA, conditional access, and least-privilege models.

  • Hybrid teams: Staff working between Wellington, Christchurch, and home offices need consistent, low-friction access.

  • Contractor sprawl: Many Kiwi firms rely on contractors who only need access to one or two systems.

A Practical Migration Path

Migrating from VPN to ZTNA doesn't need to be a big-bang project. Here's a phased approach that works well for most mid-sized NZ organisations.

1. Inventory your applications and users

Start by listing every application currently accessed via VPN. Categorise them:

  • Cloud-native (Microsoft 365, Xero, Salesforce) — these shouldn't need a VPN at all.

  • Internal web apps — ideal first ZTNA candidates.

  • Legacy thick-client apps — may need more planning.

  • Admin/infrastructure access (RDP, SSH) — high priority for ZTNA due to risk.

2. Choose an identity provider as your anchor

ZTNA only works if identity is solid. For most Kiwi businesses, that means Microsoft Entra ID (formerly Azure AD) or Google Workspace. Make sure you have:

  • MFA enforced for all users (ideally phishing-resistant methods like passkeys).

  • Conditional access policies based on device compliance.

  • Clear group structures that reflect job roles.

3. Pilot ZTNA with a low-risk application

Pick one internal web app and a small group of users — perhaps your IT team or a single department. Common options include Cloudflare Access, Zscaler Private Access, Microsoft Entra Private Access, or Tailscale for smaller teams.

You'll typically need to add a DNS record pointing your internal app to the ZTNA provider. For example, with Cloudflare Access you might create:

intranet.yourcompany.co.nz   CNAME   yourcompany.cloudflareaccess.com

Or for a Tailscale-hosted service:

files.internal.yourcompany.co.nz   CNAME   files.tailnet-xxxx.ts.net

Validate that access works only for the right users, on compliant devices, with MFA.

4. Expand application by application

Roll out ZTNA in waves. For each application, define:

  • Who can access it (groups, not individuals).

  • From which device types (managed only? BYOD allowed?).

  • Any geographic restrictions (e.g. NZ and Australia only).

  • Session duration and re-authentication frequency.

Document these policies — your auditors and cyber insurer will thank you.

5. Address legacy and admin access

For RDP, SSH, and legacy protocols, most ZTNA platforms offer connector or proxy components that can broker access without exposing ports to the internet. Prioritise these — exposed RDP remains one of the top ransomware entry points seen by CERT NZ.

6. Decommission the VPN

Once all critical apps are behind ZTNA, run the VPN in parallel for a defined cutover period (typically 30–60 days). Monitor for any users still depending on it, then switch it off. Removing the VPN concentrator reduces your attack surface and ongoing licensing costs.

Common Pitfalls to Avoid

  • Treating ZTNA as a network project: It's an identity and access project first.

  • Skipping device posture checks: Without them, ZTNA is just a fancier login screen.

  • Forgetting contractors: Build guest/partner access into your policies from day one.

  • Neglecting email security: Most breaches still start with a phishing email — ZTNA can't help if credentials are already stolen and MFA is bypassed.

Don't Forget the Email Layer

Zero Trust on the network is only half the picture. Attackers overwhelmingly target inboxes — and weak email authentication makes spoofing your domain trivial. Before, during, and after your ZTNA migration, make sure SPF, DKIM, and DMARC are properly configured for every domain you own.

Check your domain in seconds

Xteam's free MailCheck tool gives you an instant view of your SPF, DKIM, DMARC, and BIMI records, flags common misconfigurations, and provides clear remediation steps — tailored for New Zealand businesses.

👉 Try MailCheck free at xteam.co.nz and lock down your email perimeter as you modernise your network access.