The corporate VPN didn't fail because it was poorly implemented. It failed because it was built on a premise that is no longer true: that being within the company's network is enough to trust someone. When an employee connects from home, a hotel network or a cafe with the same VPN as the office team, the network perimeter as a security concept no longer exists. What remains is an illusion of control sustained by operational inertia.
Cloudflare Zero Trust starts from a different premise: identity, device, and request context determine access — not the originating IP address. The concrete implementation of this involves three components that have distinct roles and are often confused even by those who have already put them into production.
Access, Tunnel and WARP: what each one does
Cloudflare Access is an identity gateway for applications. When a request arrives at the internal domain published via Cloudflare, Access intercepts it before the request reaches the origin. The user authenticates with the configured identity provider — Okta, Azure AD, Google Workspace, or any SAML 2.0 and OIDC provider. Only after authentication and policy evaluation does traffic proceed to the origin. The application never receives an unauthenticated request.
Cloudflare Tunnel, run by the cloudflared daemon, operates on the server side. It creates an encrypted outbound connection from the server to the Cloudflare edge, without opening inbound firewall ports. The complete flow: user authenticates through Access → Cloudflare edge validates → traffic arrives through the Tunnel to the internal service. The internal server does not need a public IP, does not need a security group entry rule, and is not directly exposed to the internet.
WARP is the device client. In Zero Trust mode, it routes device traffic through the Cloudflare edge via the WireGuard protocol. This enables posture checks — disk encryption, OS version, installed security agent — and allows Access policies to include device state as a condition. For web applications accessed through the browser, WARP is often not necessary. For non-HTTP protocols like SSH and RDP routed through the Tunnel, it is mandatory.
How the authentication flow works
The concrete sequence for a developer accessing an internal service: the user accesses app.empresa.com. Access detects that there is no valid session and redirects to the identity provider. User authenticates — with MFA if policy requires it. The IdP returns to Access with confirmed identity and group attributes. Access evaluates the policy: Does this user belong to the group with permissions for this app? If approved, it issues a session JWT and the request goes to the edge, going down the Tunnel to the service on the internal network.
For non-HTTP protocols — SSH, for example — the stream goes through WARP. The customer establishes the WireGuard tunnel, the posture policy is checked, and SSH traffic routes through Cloudflare to the destination via the Tunnel.
Identity and supported providers
Access supports multiple identity providers simultaneously in the same organization. An application can allow authentication via Google Workspace for employees and via GitHub for external collaborators. Another might exclusively require Okta with mandatory MFA. Synchronized IdP groups — engineering teams, specific squads, departments — feed Access policies directly, without manual synchronization of lists.
In addition to humans, Access manages machine-to-machine access via service tokens. A CI/CD pipeline that needs to reach an authenticated internal endpoint is assigned a client ID and secret, which replace the human SSO flow. Every access, human or automated, generates an audit event with identity, timestamp, IP, device and decision made — exportable via Logpush to SIEM, Splunk or Datadog.
What Zero Trust doesn't do
Cloudflare Zero Trust controls who gets to what, but it is not a solution for encrypting data in transit within the application — this remains the responsibility of the application itself via HTTPS. Access also does not replace a firewall for east-west traffic between services within the data center or VPC. For internal communication between microservices, mTLS or service mesh remains the appropriate mechanism.
A point that is missed in initial implementations: the Tunnel protects the path between the Cloudflare edge and the origin server, but the server still only needs to trust connections coming through cloudflared. If port 443 is open to the internet outside the Tunnel, Access can be bypassed. The correct practice is to block all incoming traffic to the server except that generated by the local Tunnel daemon.
What adoption changes operationally
The most significant change is not technical — it is the mental model of whoever manages access. With VPN, the network team configures routes and split tunnels; With Zero Trust, the identity team configures policies per application. Access management leaves the network level and enters the identity level. For organizations with separate network and security teams, this involves negotiating responsibility.
The free tier — up to 50 users with Access, Tunnel, WARP and basic Gateway — is sufficient for production validation. The Team plan costs $7 per user per month and adds audit logs and Gateway with HTTP filtering. Enterprise adds Browser Isolation, DLP and email security, with negotiated pricing. For teams with more than 50 users that already have Okta or Azure AD consolidated, the deployment effort rarely exceeds four weeks of actual work.
What to evaluate before migrating
The decision to move to Zero Trust isn't about technology — it's about where the biggest security risk lies today. If your current VPN grants wide network access after authentication, a compromised credential exposes the entire internal network. Zero Trust limits the blast radius: compromised access reaches only the set of applications explicitly allowed for that identity, with device posture as additional control.
Start with the application with the highest risk of exposure and highest cost in the event of a leak. Migrating it first, with group-restricted policy and mandatory device posture, validates the complete model in production with controllable impact. The pattern tested there is replicated for the rest of the portfolio.