The first impression of WARP is misleading. The icon in the macOS menu, the on and off interface, the "connected" indicator — it all looks like a corporate VPN client from another era. But the underlying model is sufficiently different that treating it as a direct replacement for a Cisco AnyConnect leads to poor design decisions. WARP does not create a private network between the device and the office. It routes traffic through Cloudflare's global edge, and what it enables — device posture, DNS and HTTP filtering, access to private networks without public IPs — is a consequence of the architecture, not the traditional VPN mode of operation.
WARP operating modes
WARP exists in three configurations with distinct behaviors. Consumer mode — the free "1.1.1.1" app — only applies DNS over HTTPS, routing queries through Cloudflare's resolver without creating a tunnel for data traffic. The "WARP" mode activated in the free app goes further: it routes all device traffic via WireGuard through the Cloudflare edge, with protection similar to a VPN, but without organizational ties.
The relevant mode for corporate environments is Zero Trust. In it, WARP is registered in the organization via Cloudflare for Teams, and the difference is substantive: the administrator defines split tunneling policies, device posture checks, DNS and HTTP filtering through the Gateway, and can condition access to applications protected by Access to the state of WARP on the device. The user cannot uninstall or unregister WARP without administrator action — control is organizational.
When WARP is necessary and when it is not
The most common confusion in Zero Trust projects is assuming that all users need WARP. For web applications accessed through the browser and protected by Cloudflare Access, WARP does not come into play. The authentication flow happens completely through the browser — redirection to the IdP, authentication, session JWT — without WARP needing to be installed or active.
WARP becomes necessary in three scenarios: when access is to non-HTTP protocols routed through the Tunnel — SSH, RDP, database access — and Cloudflare needs a client on the device to route this traffic; when Access policies include device posture checks as an access condition; and when access is to private IP ranges routed through Cloudflare Tunnel in private network mode.
This distinction has practical implications for rollout: if the organization primarily uses internal web applications and SSH access to servers is restricted to a subset of the engineering team, WARP can be deployed only to that subset, reducing the scope of rollout via MDM.
Device posture: what WARP enables
Device posture checks are one of WARP's most important differentiators. With the client installed and registered with the organization, Cloudflare can check, before allowing access to an application, whether the device has disk encryption enabled, whether the OS version meets the configured minimum, whether a specific security agent is running — CrowdStrike, Carbon Black, SentinelOne — and whether the device is joined to a managed domain.
These checks are integrated directly into Access policies. An access policy for the production environment may require: user belongs to the engineering group, authentication with MFA, device with active CrowdStrike and updated OS. If any condition fails, access is denied — and the audit log records which condition failed, not just that access was denied. With VPN, the only gate is authentication; Once inside, the device state is no longer checked.
Split tunneling: include vs. exclude
Split tunneling in WARP operates in two modes with opposite semantics. Exclude mode — the default in many initial configurations — defines what doesn't go through WARP: everything except the listed routes goes through Cloudflare. The include mode defines what goes through: only the listed routes, the rest goes directly via the device's internet.
Include mode is the safest for corporate environments. Only traffic to the organization's domains and IP ranges passes through WARP; Traffic to external services goes straight through, without additional latency. The user has better performance for general use; the organization maintains control over corporate traffic. Exclude mode is easier to configure initially, but each new external service that needs to be excluded requires updating the list — which becomes operational debt over time.
WARP performance typically outperforms traditional IPsec-based VPNs for geographically distributed users. WireGuard has lower handshake overhead, and traffic routes to the closest Cloudflare edge location — not the VPN hub in the customer's data center, which can be hundreds of milliseconds away for remote collaborators.
Deployment at scale and disconnected behavior
WARP supports managed deployment via MDM — Jamf Pro, Intune, Mosyle. The organization distributes the configuration profile that automatically registers WARP to the company account without manual user intervention. For 100 devices with consolidated MDM, rollout typically takes less than a week of actual work — most of the time is testing and communication, not technical configuration.
Behavior when WARP is disconnected requires explicit planning. If an Access policy conditions access to active WARP, the user with WARP disconnected — due to network failure, OS reinstallation or exit from MDM — loses access to applications that depend on this condition. The responsible team needs to document the remediation path: how the user reconnects, what to do if the device is deleted from the organization, how to operate in emergencies where access is critical and WARP is not available.
The WARP Scope Decision
Deploying WARP to all users, with split tunnel in include mode, turns Cloudflare Gateway into a DNS and HTTP filter for all corporate traffic — additional protection against malware, phishing and exfiltration that goes beyond controlling access to internal applications. The Gateway can block categories of websites, inspect HTTPS traffic inline, and generate logs of all browsing activity — with privacy implications that need to be explicitly communicated to the team.
WARP limited to the subset that needs non-HTTP access is technically sufficient for Zero Trust. Organization-wide WARP adds network filtering capability in its own right — but requires documented acceptable use policy and clear communication about what is monitored.