VPN vs zero trust network access: what remote businesses should use

Short answer: For most small and mid-sized businesses with a remote or hybrid workforce, zero trust network access (ZTNA) is the better direction than a traditional VPN. VPNs give a remote device full network-level access once connected, which is a broad blast radius if the device or account is compromised. ZTNA grants identity-verified, per-application access instead, which fits how cloud-first businesses actually operate. VPN is still reasonable for small teams with simple needs, on-premises resources, or existing hardware investments – but for growing remote teams, ZTNA is where the industry is heading.

VPN vs ZTNA at a glance

	Traditional VPN	Zero Trust Network Access (ZTNA)
Trust model	Network-based: once connected, the device is trusted on the network	Identity-based: every request is verified, nothing is trusted by default
Access granularity	Broad – full network or large segments	Narrow – specific applications only
Blast radius if compromised	Wide: compromised device can see internal network	Limited: compromised account only reaches authorized apps
Works best for	On-prem resources, small teams, simple architectures	Cloud-first or hybrid teams, distributed workforces
Setup complexity	Moderate (hardware or software appliance)	Moderate to higher (identity integration, app-by-app config)
Ongoing management	VPN client updates, certificate rotation, capacity planning	Policy tuning, integration maintenance, monitoring
Typical cost model	Per-appliance or per-user license	Per-user subscription
Visibility into activity	Limited – sees traffic but not app-level context	Rich – per-user, per-app, per-request logging
Performance at scale	Degrades as users grow	Generally better – no single choke point
Best examples	OpenVPN, Fortinet, Cisco AnyConnect, SonicWall	Cloudflare Zero Trust, Zscaler Private Access, Twingate, Tailscale

How a traditional VPN works

A VPN (Virtual Private Network) creates an encrypted tunnel between the remote employee’s device and your office network. Once the tunnel is established, the device behaves as if it were physically plugged into a network port in the office. It gets an IP address from your network, it can see internal servers, it can access file shares and line-of-business applications just like an on-site employee would.

This model was designed in an era when the network was the security boundary. Everything inside the office network was trusted. Everything outside was not. The VPN extended “inside” to remote employees so they could work from home the same way they worked at a desk.

For decades, this was the right answer. The problem is that the assumptions underneath it are no longer true.

Where VPN falls short for modern remote teams

VPN still works. It is not a broken technology. But the environment has changed, and several weaknesses have become serious enough that many businesses are moving away from it.

All-or-nothing access

When a user connects to the VPN, they typically get broad network access. Depending on how segmentation is configured, they may be able to reach every server on the network, or at least a large chunk of it. This is a problem because a compromised device or account now has equivalent access.

In practice, most small business VPNs are configured with minimal segmentation, because setting up fine-grained firewall rules between VPN users and internal resources is tedious. The default state is “VPN users can see everything an office user can see.” That is a big blast radius.

Performance issues as the team grows

VPN traffic routes through a central appliance – either a hardware box in your office or a software server in the cloud. Every remote connection, every file download, every application request goes through that chokepoint. As the remote team grows, the appliance becomes a bottleneck. Users complain about slowness, video calls drop, file syncs take forever.

Scaling the VPN means buying bigger hardware or more licenses, which is an expensive way to solve a problem that ZTNA does not have in the first place.

Hard to manage at scale

VPN clients need to be installed, configured, and kept up to date on every device. Certificates expire and need to be rotated. Split tunneling needs to be tuned so not every Zoom call goes through the office. MFA integration needs to be layered on top because the VPN alone is just username and password.

For a five-person team, this is manageable. For a 50-person distributed team, it is a constant source of friction.

Doesn’t match how cloud-first businesses work

The whole premise of a VPN is that resources live inside the corporate network. For a business whose day-to-day work happens in Microsoft 365, Salesforce, Slack, Dropbox, QuickBooks Online, and GitHub, the VPN provides no benefit for any of those. The only things still on the internal network might be a handful of legacy applications, a file server that should have been migrated to SharePoint three years ago, and maybe a domain controller.

If 90% of the work happens in SaaS and 10% of the work happens on internal resources, routing everything through a VPN to protect that 10% is the wrong shape.

Not what attackers are defeating anymore

Most modern breaches do not involve “attacker breaks VPN encryption.” They involve phishing that steals credentials, then the attacker logs in through the VPN like a normal user. Once in, VPN trust model assumes the session is legitimate, and the attacker has broad internal access.

VPN was designed to stop eavesdropping and unauthorized network access. It was not designed to stop authenticated sessions from going rogue. That is what ZTNA does.

How zero trust network access works

Zero trust network access flips the model. Instead of trusting the network, it verifies every request based on identity, device state, and context. Nothing is trusted by default – every connection is evaluated.

In a ZTNA deployment, there is no broad network tunnel. When the employee wants to reach an internal application, the ZTNA client talks to an identity-aware proxy that checks:

• Who is the user? (Identity verified against Entra, Okta, Google Workspace, etc.)
• Is the device in a compliant state? (Up-to-date OS, encryption enabled, EDR running, enrolled in MDM)
• Is the request coming from an expected location and time?
• Is the user authorized for this specific application?

If all the checks pass, the proxy connects the user to that one application. The user does not get an IP address on your network. They do not see other servers. They do not have a tunnel. They have a verified connection to the one resource they are allowed to access, and nothing else.

This is what zero trust security looks like applied to network access specifically. The broader zero trust framework covers identity, devices, data, and applications in a similar way.

What ZTNA solves that VPN does not

Narrow blast radius

If a ZTNA user’s account is compromised, the attacker can only reach the applications that specific user is authorized for. A compromised marketing team account cannot pivot to the accounting server, because the marketing team account was never authorized for it. A compromised device that fails a compliance check is denied access entirely, even with valid credentials.

This is the single biggest practical improvement ZTNA makes over VPN.

Device compliance is enforced

ZTNA can refuse access if the device does not meet your requirements – encryption not enabled, OS out of date, EDR not running, not enrolled in management. A VPN cannot do this natively; it connects anyone with valid credentials regardless of device state.

Combined with Microsoft Intune or another MDM, ZTNA becomes “only compliant devices can access company resources,” which is a significantly stronger posture than “anyone with the password can get on the network.”

Better performance

ZTNA providers run globally distributed edge networks. The employee connects to the nearest node, the node authenticates them, and then connects them to the target app through an optimized path. There is no central appliance to bottleneck. Video calls, file transfers, and SaaS apps work at native speed.

Cleaner offboarding

When an employee leaves, removing them from the identity provider revokes access to everything at once. With a VPN, you might have to separately disable the VPN account, which is one of the most commonly missed offboarding steps.

Rich visibility

Every ZTNA request is logged with user, app, action, and outcome. This is dramatically more useful than VPN logs, which typically show “user connected at X, disconnected at Y” with little about what they did in between.

Scales naturally

Adding a new user is an identity provisioning task and a policy adjustment. No new hardware. No capacity planning. No bigger appliance.

When VPN still makes sense

ZTNA is not universally better. There are situations where a VPN is the right choice, or at least the more practical one for now.

You have heavy on-premises infrastructure

If most of your business still runs on servers in your office – a domain controller, a file server, an on-prem ERP, a local database – a VPN is the simpler way to give remote workers access. ZTNA can publish on-prem applications too, but the configuration work per app adds up.

Your team is very small

For a five-person team with a simple setup, a VPN is a working solution today. The operational overhead of moving to ZTNA may not be worth it if the current VPN is not actively causing problems.

You have existing hardware investment

If you recently bought a hardware VPN appliance, ripping it out to move to ZTNA is a sunk cost conversation. Letting the hardware age out over two or three years and then transitioning is often the more reasonable plan.

Your compliance framework specifies VPN

Some older compliance frameworks, and some contracts with larger customers, still explicitly reference VPN as the expected remote access control. Moving to ZTNA is possible but requires documenting the equivalent controls, which is more work. If the contract is up for renewal soon, this is usually negotiable. If not, stick with VPN until the next cycle.

You need simple, known-good for a small use case

Contractors who need occasional access to one legacy app? A VPN with narrow firewall rules is often faster to set up than spinning up a ZTNA deployment for one edge case.

When ZTNA is clearly the right move

• Your team is distributed and growing. Every new hire is one more VPN client to install and one more bottleneck on the appliance. ZTNA adds users without operational overhead.
• Your work is mostly in cloud applications. There is not much on your internal network to VPN into.
• You want device compliance enforced. ZTNA enforces it natively. VPN cannot.
• You are building up toward a zero trust security posture overall. ZTNA is the network piece of that broader architecture.
• You need better visibility for compliance or incident response. ZTNA logs every request with context. VPN does not.
• You are planning a security architecture refresh anyway. Going straight to ZTNA is usually cheaper than replacing VPN gear first and then migrating again.

What ZTNA products look like in practice

For SMBs, the recognizable options today include:

• Cloudflare Zero Trust (formerly Cloudflare for Teams). Cloudflare’s ZTNA product. Strong pricing at the SMB tier, includes Access, Gateway (DNS filtering), and Tunnel (for publishing internal apps). Good fit for businesses already using Cloudflare for other things.
• Zscaler Private Access (ZPA). Enterprise-grade ZTNA with a long track record. More features and more complexity than SMBs typically need, but strong if you will grow into it.
• Twingate. Focused specifically on ZTNA, designed with SMBs and technical teams in mind. Simpler to deploy than the enterprise options.
• Tailscale. Mesh VPN with zero-trust characteristics. Technically not ZTNA in the strict sense, but it solves many of the same problems for technical teams with minimal overhead. Very popular with developers and small engineering teams.
• Microsoft Entra Private Access. Microsoft’s own ZTNA product, integrated into the Entra identity platform. Relevant if you are already all-in on Microsoft.
• Perimeter 81 / Check Point Harmony Connect. Another mid-market option, often bundled with broader secure access service edge (SASE) features.

Pricing and feature sets vary. For a 10-50 person business, expect ZTNA to cost somewhere in the range of $5-15 per user per month depending on features.

How to plan a VPN-to-ZTNA migration

If you decide ZTNA is the right direction, here is a practical path to get there without breaking things:

1. Inventory what your VPN is actually being used for. List every internal application, file share, and resource that remote users reach through the VPN. For a surprising number of SMBs, this list is shorter than expected.
2. Categorize each resource. For each item, decide: is this still needed (or can it be migrated to SaaS)? Is it something ZTNA can publish directly? Does it need to stay on the VPN for technical reasons?
3. Pick a ZTNA product and deploy it alongside the VPN. Do not cut over all at once. Run ZTNA in parallel for the first few applications while the VPN continues to serve everything else.
4. Migrate applications one at a time. Start with the lowest-risk, most commonly used apps. Validate that each works correctly through ZTNA before moving on.
5. Roll out ZTNA to users in phases. Start with IT, then early adopters, then the rest of the team.
6. Retire the VPN when its resources are all migrated. Do not keep the VPN running as a fallback indefinitely – it becomes security debt. Set a sunset date and stick to it.
7. Layer on conditional access policies. Once ZTNA is the primary access method, tighten the policies: require compliant devices, block risky sign-ins, require phishing-resistant MFA.

The whole migration typically takes a few months for an SMB. Most of the time is spent on the inventory and testing steps, not on the technical rollout.

Common mistakes in the VPN to ZTNA transition

• Treating ZTNA as a drop-in VPN replacement. It is not. The configuration model is different, the access model is different, and trying to recreate “everyone gets full network access” in ZTNA defeats the purpose. Design the access model intentionally.
• Not fixing device compliance first. ZTNA’s compliance enforcement is only as good as the compliance policies it checks against. If you do not have Intune or another MDM deployed with meaningful policies, ZTNA is just identity-based access, not full zero trust.
• Ignoring the offboarding story. Make sure removing a user from the identity provider actually removes their ZTNA access. Test it.
• Keeping the VPN “just in case.” Dual-running forever is a security risk, because the VPN’s broad access undercuts everything ZTNA is doing. Commit to the migration and complete it.
• Buying the wrong tier. ZTNA products have different SKUs for different capabilities. The “cheap” tier may not include the features you actually need (device compliance, full logging, app connector counts). Read the pricing pages carefully before committing.

How this fits into broader remote work security

ZTNA is one piece of securing a remote workforce, not the whole picture. Even with perfect ZTNA, you still need MFA, EDR on endpoints, patching, email security, user training, and backup and recovery. ZTNA solves the “how do remote users reach company resources safely” question cleanly. It does not solve the phishing email that steals the credentials in the first place, or the unpatched laptop that gets infected.

It also does not solve the deeper architectural problem behind most VPN frustrations: that the apps and files remote workers need are still behind the office network in the first place. ZTNA in front of an on-prem app is a more expensive VPN. The bigger move is to retire the dependency, not just the tunnel – see cloud migration for remote teams for the priority order when remote access is the primary migration driver.

The businesses that get the most out of ZTNA are the ones that treat it as part of a layered security architecture, not as a silver bullet. Identity, device, network, and application controls all have to move in the same direction.

How Sequentur handles this for clients

For clients on our managed IT support for remote and hybrid teams service moving to remote or hybrid work, we assess the existing access setup (usually a VPN of some kind), inventory the resources in play, and design a migration path that matches the business’s actual needs. In many cases the right answer is ZTNA with Intune compliance enforcement. In some cases it is a tighter VPN configuration plus conditional access. In some cases it is both for a while, with a clear retirement plan for the VPN.

The decision is less about the product and more about the workflow: who needs access to what, how frequently, from what kinds of devices. Getting that mapped correctly is what makes the eventual technology choice obvious.

If you are staring at a VPN that has gotten out of hand, or standing up remote access for the first time, schedule a call and we will walk through the options with you.