Traditional VPNs have a problem: once you’re in, you’re in. Connect to the corporate VPN, and suddenly you have network-level access to everything behind the firewall. That access model made sense when “inside the network” was a meaningful security boundary. It makes less sense when attackers routinely compromise VPN credentials or pivot through VPN connections.
Modern alternatives flip the model. Instead of network access, they provide application access—authenticated, authorized, and audited on every request. Here’s how they compare.
The Traditional VPN Problem
A classic site-to-site or client VPN creates a tunnel that puts remote users on the corporate network. The user’s traffic exits through the corporate network as if they were physically there.
This works, but the failure modes are concerning:
- Stolen credentials = full access. VPN credentials (especially without MFA) are a common target. Once compromised, attackers get network access.
- Lateral movement is easy. Inside the VPN, there’s often little segmentation. Compromising one device can lead to accessing everything.
- Split tunneling dilemmas. Route all traffic through VPN (slow, privacy concerns) or only corporate traffic (security inspection gaps)?
- Performance bottlenecks. All remote traffic backhauling through corporate data centers adds latency.
- Client complexity. VPN clients are often clunky, require admin rights, and create support tickets.
Zero-trust network access (ZTNA) products address these issues by authenticating users to applications rather than networks.
Tailscale: The Developer-Friendly Mesh
Tailscale builds a mesh VPN using WireGuard under the hood. But unlike traditional VPNs, there’s no central concentrator. Devices communicate directly (peer-to-peer) when possible, with fallback through Tailscale’s relay servers when NAT traversal fails.
How Tailscale works:
You install the Tailscale client on devices you want to connect. Each device gets an address on your Tailscale network (the “tailnet”). Devices can reach each other directly by these addresses. Authentication happens through your identity provider (Google, Okta, Azure AD, etc.).
What Tailscale does well:
- Dead-simple setup. Install, authenticate, connected. No server to run, no firewall rules to configure.
- Works through NAT. WireGuard + NAT traversal means it works from coffee shops, hotel WiFi, mobile networks.
- Peer-to-peer performance. Direct connections between devices without backhauling through a central point.
- ACLs. Control which devices can reach which others. The developer’s laptop can reach dev servers but not production.
- MagicDNS. Devices get DNS names (device.tailnet-name.ts.net) that just work.
Tailscale trade-offs:
- It’s still network access. You’re connecting networks, not individual applications. Within what Tailscale allows, it’s traditional L3/L4 access.
- Control plane dependency. Tailscale’s coordination service is essential. If it’s down, you can’t add devices or change ACLs (existing connections keep working).
- Not designed for consumer-facing apps. Tailscale is for internal/team access, not general user authentication.
Best for: Teams that want simple, secure connectivity between servers, developer machines, and internal services. The sweet spot is 10–500 devices.
Cloudflare Access: Application-Level Zero Trust
Cloudflare Access is a ZTNA product that authenticates users to specific applications without network-level access. It’s part of Cloudflare’s broader Zero Trust platform (which also includes Gateway for DNS filtering, Browser Isolation, and more).
How Cloudflare Access works:
Applications are accessed through Cloudflare’s edge. Users authenticate (via your identity provider), and Cloudflare proxies requests to your origin servers. The origin can be anywhere—cloud, on-prem, even behind NAT if you use Cloudflare Tunnel.
What Cloudflare Access does well:
- Application-level access. Users get access to specific apps, not networks. No lateral movement because there’s no network access.
- No client required for web apps. For browser-based applications, users just authenticate. No software to install.
- Cloudflare Tunnel. Expose internal applications without opening inbound firewall ports. The tunnel connects outbound from your network.
- Identity-aware access policies. Combine identity (user, group), device posture, and context (location, time) into access rules.
- Global edge. Users connect to nearby Cloudflare PoPs, then traffic is optimized to your origin. Can improve performance.
Cloudflare Access trade-offs:
- Web/HTTP focus. Works great for web applications. For non-HTTP protocols (SSH, RDP, databases), you need the WARP client plus additional configuration.
- Client needed for full protection. To route arbitrary traffic through Cloudflare (not just web apps), users need the WARP client.
- Cloudflare in the data path. All traffic flows through Cloudflare. Some organizations have privacy or sovereignty concerns.
- Complexity at scale. Managing policies across many applications requires planning.
Best for: Organizations with many web applications that need authenticated access. Particularly good when you want to expose internal apps externally without traditional VPN or DMZ complexity.
Google BeyondCorp (and the Philosophy)
BeyondCorp is Google’s internal zero-trust architecture, implemented after the 2009 Operation Aurora breach. Google productized aspects of it as BeyondCorp Enterprise (now part of Chrome Enterprise).
The philosophy: access decisions should be based on who you are, what device you’re using, and what you’re trying to access—not which network you’re on.
BeyondCorp principles:
- Access from any network is treated the same (corporate office or coffee shop)
- Access is granted per-application, per-request
- Device trust (managed, patched, encrypted) factors into access decisions
- Continuous verification, not one-time authentication
BeyondCorp Enterprise (the product):
- Integrates with Chrome to provide identity-aware access to web apps
- Works with Cloud Identity or other IdPs
- Endpoint verification checks device posture
- Can integrate with existing infrastructure or Cloudflare/Zscaler-style proxies
Considerations:
- Heavily Chrome-focused (as you’d expect from Google)
- Works best for organizations already in Google Workspace/Cloud ecosystem
- The “full BeyondCorp” implementation requires significant architectural changes
Best for: Google Workspace shops that want zero-trust web access with tight Chrome integration. The philosophy applies broadly; the product is Google-ecosystem-specific.
Other Notable Options
Zscaler Private Access (ZPA): Enterprise ZTNA with application segmentation. Heavier solution, more suited to large enterprise deployments with compliance requirements.
Palo Alto Prisma Access: SASE platform that includes ZTNA capabilities. For organizations already in the Palo Alto ecosystem.
Twingate: ZTNA focused on simplicity, positioning between Tailscale (mesh network) and Cloudflare Access (application proxy). Worth evaluating if others don’t quite fit.
WireGuard directly: If you want VPN-like network access but better than OpenVPN/IPsec, running WireGuard servers yourself is an option. You lose the orchestration and management that Tailscale adds.
When You Still Need Traditional VPN
These alternatives don’t fit every scenario:
Legacy protocols. If you need network-level access to legacy applications that can’t be fronted by proxies, traditional VPN may be unavoidable.
Site-to-site connections. Connecting entire networks (office to data center, multi-cloud networking) is different from user access. Tools like Tailscale subnet routers or cloud provider VPNs handle this.
Full network integration. Some use cases genuinely need the remote user to be “on the network”—multicast applications, network scanning, certain admin tasks.
Air-gapped or high-security environments. Environments with strict data sovereignty, no external connectivity, or classified workloads may require self-hosted solutions without external control planes.
Making the Choice
For developer and team access to internal services: Tailscale is often the fastest path to secure, usable remote access. Setup is trivial, it works through terrible NAT, and developers can be productive in minutes.
For exposing web applications to authenticated users: Cloudflare Access (or Zscaler ZPA) provides application-level access without network exposure. Great for internal tools, admin panels, or exposing services to partners.
For enterprise-wide zero trust: Larger organizations with compliance requirements may need full SASE/ZTNA platforms. Evaluate based on your existing vendor relationships and requirements.
For tight budgets or simple needs: WireGuard servers, SSH tunnels, or even traditional VPN with strong MFA can work. Don’t over-engineer if the problem is simple.
Our Recommendation
Most organizations can significantly improve their remote access posture by:
Adding MFA to whatever you have today. This is table stakes. If your VPN is password-only, fix that first.
Evaluating Tailscale or similar for internal access. The developer experience improvement alone often justifies the switch.
Moving web applications behind ZTNA. Cloudflare Access or similar for internal web apps removes VPN dependency for most daily work.
Keeping VPN for edge cases. Full network access becomes the exception rather than the default—used only when specific tasks require it.
The goal isn’t eliminating VPNs for the sake of it. It’s reducing the blast radius of credential compromise and improving user experience. These tools help with both.