The classic VPN solves a 2005 problem: how do I bring an employee "into the network"? The right question in 2026 is a different one — why should anyone have to be on the network to open an application?
How each one works
A classic VPN opens a port to the internet — usually on the firewall — and, after authentication, puts the user inside the network. From there, unless the network is rigorously segmented, they see everything any office workstation sees.
Cloudflare Tunnel reverses the direction. An agent installed on your network opens an outbound connection to Cloudflare. No inbound port is opened. Users reach the application through a public address, and authentication happens before traffic touches your server.
The key difference: with a VPN, authentication gives you access to the network. With Tunnel, it gives you access to an application. If someone compromises an employee's account, in the first case they have a network to explore; in the second, they have one application.
Comparison
| Aspect | Classic VPN | Cloudflare Tunnel |
|---|---|---|
| Ports open to the internet | Yes — a permanent attack surface | None. The connection starts from inside |
| What you get after authentication | Network access, often unsegmented | Access to a specific application |
| Installation on the user's device | VPN client, with configuration | Nothing — works from the browser |
| Two-factor authentication | Possible, but has to be built | Built in, with Google, Microsoft or an email code |
| Access for outsiders (accountant, auditor) | Clunky — a network account, an installed client | A link and an authorised email address |
| What you see in the logs | Who connected to the network | Who accessed which application and when |
| Non-web protocols (RDP, SSH, SMB) | Native, simple | Possible, but with a dedicated client or extra configuration |
| Cost for a small team | Included in the firewall | Free up to a number of users |
Where Tunnel clearly wins
Internal web applications. An ERP, an invoicing system, an admin interface, a Grafana dashboard. These are the ideal case: publish the application, add an access policy, done. No client, no open port.
Third-party access. The external accountant who needs the invoicing application once a month shouldn't get an account on your network. You authorise their email address for a single application, with an expiry date.
Devices you don't own. A collaborator's personal laptop should never end up on the company VPN. Through the browser, with authentication, the risk is completely different.
Traceability. The logs tell you who opened which application. In an audit, "John connected to the VPN on Tuesday" is worth far less than "John accessed the invoicing application on Tuesday at 14:32".
Where the VPN is still better
It isn't a universal solution, and we don't claim it is.
When you really need the network, not applications. An administrator working on network devices, or someone using SMB file shares and dozens of different resources, has a better experience over a VPN.
When you don't want to depend on an external provider. With Tunnel, access goes through Cloudflare's infrastructure. For most companies that's a reasonable trade-off; for some, it's not acceptable at all.
Site-to-site links. For a permanent tunnel between two offices, a site-to-site VPN on the firewall remains the natural choice.
What we do in practice
Most often, both — but with clear roles.
- Tunnel for applications. Everything web-based that needs to be reached from outside goes through it. That covers most day-to-day needs.
- VPN for administration. Restricted to the two or three people who genuinely need network access, with mandatory two-factor authentication.
The practical effect: the number of people with access to the network itself drops from "every employee" to "two administrators". That's the risk reduction that matters, not the technology itself.
What neither solution fixes: if the published application has a vulnerability, it stays vulnerable to whoever gets past authentication. Tunnel reduces who can reach it, not what can be done once they're there. Updates remain mandatory.
What the transition looks like
- Take inventory: what people access from outside the office, and how often.
- Separate the web applications from the rest. Those move first.
- Publish a single application through Tunnel to a small group of users. Run it for two weeks.
- Expand gradually, one application at a time.
- Finally, restrict the VPN to the people who really need the network — usually far fewer than you first thought.
It's not a weekend migration, and it doesn't need to be. Every application moved is a reduction in attack surface that stays won.
Need a second opinion on your infrastructure? We look at your actual situation and tell you what makes sense — including when the answer is "don't change anything right now".
Book a call arrow_forward