The core difference: publish an application or join a network
A traditional remote-access VPN gives the user's device routes into a private network. Security then depends on network segmentation, firewall policy and the device. Cloudflare Tunnel gives the origin an outbound path; Cloudflare Access can place identity policy in front of a specific application.
For browser applications, that application-level model often reduces lateral movement and removes a VPN client step. For protocols that require private IP reachability, Cloudflare Zero Trust may still use WARP, so the experience is closer to a modern private network than a purely clientless tunnel.
Internal web applications usually favor Tunnel + Access
Admin panels, dashboards, wikis and self-hosted business tools have a clear hostname and user audience. They can be protected by an identity policy without exposing the origin or granting a route to the rest of the subnet.
Contractor access is easier to reason about when the contract maps to one application and an expiring policy rather than a reusable VPN profile with broad routes.
- ▸ Per-application login and session rules
- ▸ No inbound origin ports
- ▸ Clientless browser access for many HTTP applications
- ▸ Cleaner external collaborator scope
Network-heavy and legacy workflows may still need a VPN
Applications that discover peers by broadcast, expect a full local subnet, use unusual protocols or move large volumes between many hosts may fit a VPN or site-to-site design better. A legacy client that cannot work through a supported private routing path should be tested before any replacement promise is made.
Cloudflare WARP and private network routes cover many non-browser needs, but they still require endpoint enrollment, routing and policy. That is not the same as saying every old VPN workflow will work unchanged.
SSH and RDP depend on the operator experience you want
For occasional administration, an identity-gated SSH or RDP path can remove public management ports and provide a focused workflow. For administrators who constantly reach many private hosts, WARP or a well-segmented VPN may be more efficient.
Consider session logging, emergency access, automation and what happens when the identity provider is unavailable. The most secure design on paper is not useful if operators bypass it during every incident.
A practical selection checklist
Choose Tunnel + Access first when the resource has a stable hostname, users need a small set of applications, contractors must be scoped tightly, or the origin should have no public inbound ports.
Keep or redesign the VPN when users need broad network connectivity, protocols depend on local network behavior, site-to-site routing is central, or an existing operational team already manages segmentation and device posture well. A hybrid is common during migration.
- ▸ List applications and protocols before discussing products
- ▸ Separate employee, contractor and machine access
- ▸ Pilot one low-risk application
- ▸ Test offboarding and emergency administrator recovery
- ▸ Remove the old route only after real user workflows pass
Migrate application by application
Do not replace the entire VPN in one switch. Put one internal web application behind Tunnel and Access, run a user pilot, then compare reliability and support load. Add WARP routes only for workflows that truly need private network connectivity.
The migration is complete when unused VPN routes and accounts are removed, not when the new login page appears.