Comparison · Network security
Traditional VPN vs zero trust network access for remote staff
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
A traditional remote-access VPN places a user's device on the internal network, so a compromised laptop can reach much more than it needs. Zero trust network access verifies user and device for each application and grants only that access. The second model limits lateral movement but needs good identity, device inventory and application mapping, so many organisations adopt it in stages.
Who this is for: An IT decision-maker whose remote access relies on a gateway VPN and who is weighing a move to per-application, identity-aware access.
What to evaluate
Blast radius of a compromised device
Network-level access exposes many systems from one stolen credential, whereas per-application access narrows it.
How to check: Map what a connected user can reach today and how many systems they never use.
Identity and device signals
Zero trust decisions depend on reliable identity, strong authentication and device health information.
How to check: Assess whether you have a central identity provider, multi-factor authentication and device inventory.
Application mix
Modern web applications fit per-application access easily, while legacy protocols and thick clients may not.
How to check: List applications by protocol and ownership, and identify those needing special handling.
User experience
Slow or awkward access prompts workarounds that undermine security.
How to check: Pilot with a representative group and gather feedback on speed and reliability.
Operational and skills fit
Granular policy requires someone to define and maintain it.
How to check: Decide who owns access policy and how application owners approve entitlements.
Comparison
| Aspect | Gateway VPN | Zero trust network access |
|---|---|---|
| Access granted | Network-level reach to internal ranges | Specific applications for specific users |
| Device checks | Often limited to a basic client check | Continuous posture and identity signals can be evaluated |
| Lateral movement risk | Higher once connected | Lower by design if policies are tight |
| Legacy application support | Broad and simple | May need connectors or exceptions |
| Setup effort | Familiar and quick | Requires application inventory and policy design |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 5 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Blast radius of a compromised device | |||
| Identity and device signals | |||
| Application mix | |||
| User experience | |||
| Operational and skills fit | |||
| Total (max 15) | 0 | 0 | 0 |
Questions to ask before you commit
- Which applications can be published through per-application access and which cannot?
- How does the service evaluate device health and what happens when a device fails checks?
- Where do connectors run and what outbound connectivity do they need?
- How are policies expressed, reviewed and audited?
- What happens to access if the provider has an outage?
- Can we run both models in parallel during migration?
- How are logs delivered to our monitoring tools?
Typical trade-offs
Familiar VPN versus a policy-heavy new model
- Upside
- A VPN is simple to explain and supports almost any protocol.
- Downside
- It grants broad network visibility, magnifying the consequences of one compromise.
Cloud-delivered access broker versus self-hosted gateway
- Upside
- A cloud service reduces exposed inbound services you must patch.
- Downside
- Adds dependency on the provider and its availability.
Strict device posture checks versus ease of access
- Upside
- Checks stop unmanaged or unhealthy devices from reaching sensitive systems.
- Downside
- Can lock out legitimate users and needs a support route for quick resolution.
Common mistakes
- Treating zero trust as a product to buy rather than a design approach. It depends on identity, device and policy work.
- Migrating everything at once. Start with high-value or web-based applications and move gradually.
- Leaving the old VPN open alongside the new access method indefinitely, which preserves the weaker path.
- Skipping authentication hardening. Strong multi-factor sign-in is the foundation for either model.
- Not planning for legacy applications that cannot be placed behind identity-aware access.
Related questions
Is zero trust just a rebrand of VPN?
No, though marketing blurs it. Zero trust is an architectural principle: do not grant trust because something sits inside a network, verify each request using identity, device state and context, and give the least access needed. Products implement that in different ways. Government reference material describes the concept independently of any vendor. Evaluate whether a product enforces per-request decisions and narrow access rather than simply tunnelling traffic.
Can a small organisation use zero trust approaches?
Yes, in practical steps. Enforce strong authentication, keep an accurate inventory of devices and accounts, limit administrative access, restrict network reach to what each role needs and expose applications through identity-aware access where feasible. You need not adopt a full architecture at once. Prioritise protections that reduce the effect of one stolen credential, which is the most common problem small teams face.
What happens to legacy applications?
They are often the hardest part. Options include publishing them through a connector that brokers access, placing them in a restricted network segment with tight rules, wrapping them with a remote desktop or application gateway, or replacing them over time. Document every legacy application, its protocol and its owner. Treat these as a risk register item until a fix is in place, and keep monitoring them closely.
How do we measure whether the change improved security?
Track qualitative indicators: how many systems each user can reach compared to what they need, whether unmanaged devices are blocked from sensitive applications, how quickly access is revoked at departure and whether access decisions are logged and reviewed. Run an exercise where a test account is treated as compromised and see how far it can move. Improvement shows up as a smaller, observable reach and faster containment.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Zero Trust Architecture (SP 800-207) — National Institute of Standards and Technology, retrieved 27 October 2026
- Zero trust architecture design principles — National Cyber Security Centre (UK), retrieved 27 October 2026
Related guides
How to choose · Network security
How to choose a business firewall
Choose a firewall by matching throughput under your real security features, management model and update commitments to your environment. Inspect how much traffic it can handle with inspection enabled, what remote access it supports, how policy is managed and logged, and how long the maker supplies security updates. Support lifetime and management effort matter more than the feature list.
Requirements · Network security
Network segmentation and remote access requirements for a small office
A small office should separate staff devices, guests, servers and untrusted internet-of-things equipment into distinct network zones, with a firewall controlling traffic between them. Secure administration, change default credentials, update router and access point firmware, require strong authentication for remote access and keep logs. Simple, consistently applied rules beat elaborate designs nobody maintains.
Problems & fixes · Network security
Why firewall rules become unmanageable and how to fix them
Rule sprawl happens when temporary exceptions are never removed, rules lack owners and several people edit without records. It causes hidden exposure, outages when something is changed and slow audits. Fix it by documenting what exists, using hit counters and logs to identify unused rules, consolidating through objects and groups, and putting a change process in place.
Problems & fixes · Identity and access
Why former employees keep access and how to close the gaps
Orphaned access usually survives because accounts are created outside central identity, ownership is unclear, and offboarding depends on manual steps across many tools. Fix it with a single authoritative trigger from HR, central sign-in for as many apps as possible, regular access reviews, and a reconciled list of accounts that bypass single sign-on, such as shared logins, API keys and personal-email registrations.
Comparison · Identity and access
Passkeys, authenticator apps, hardware keys and text message codes compared
Methods differ mainly in how resistant they are to phishing and in how easy they are to deploy and recover. Passkeys and hardware security keys bind sign-in to the genuine site and resist phishing. Authenticator app codes are a solid, widely supported middle option. Text message codes are better than a password alone but are exposed to interception and number takeover, so reserve them as a fallback.
Suitability · Privacy tools
Do you actually need a consumer VPN?
A consumer VPN helps in specific situations: untrusted public networks, hiding your address from sites, accessing a work network or choosing a different apparent location where legal. It does little against phishing, malware or account tracking. For many people, device updates, strong unique passwords, second-factor sign-in and HTTPS provide more protection than a VPN subscription.
How to choose · Identity and access
How to choose a single sign-on and identity provider
Choose an identity provider by checking which of your applications support standard federation, how provisioning and deprovisioning work, what authentication methods and policies are available, and how the provider behaves when it fails. The directory you already run, the number of unsupported legacy apps, and your admin capacity shape the best fit more than feature lists do.