How Cloudflare Security Runs on Its Own Zero Trust Stack
Cloudflare’s security team doesn’t just build Zero Trust products—it uses them internally. The company’s journey from a hardware VPN to a fully cloud-delivered security stack mirrors what many enterprises face, and the internal rollout has shaped how the products themselves evolved. Here’s how Cloudflare Security implemented Zero Trust for its own workforce, and what it learned along the way.
Retiring the VPN with Cloudflare Access
Before 2015, reaching internally-hosted applications required a hardware-based VPN. On-call engineers had to launch a client, connect, and then log in to tools like Grafana—a process that was slow and frustrating at the worst moments. Cloudflare Access started as an internal project to fix that exact pain point.
The initial deployment was deliberately small: one application behind Access, with the goal of improving incident response. Engineers who got a page could tap a link, authenticate through their browser, and get to work immediately. The new flow spread organically—teams asked for it before any security mandate required them to adopt it.
Because authentication happens at the network edge, Access supports a globally-distributed workforce without the latency penalty of a traditional VPN. More importantly, it let the team enforce strong two-factor authentication. Not all second factors are equal; some remain vulnerable to man-in-the-middle attacks that steal one-time passwords via phishing. Cloudflare chose FIDO2-compliant hardware security keys to eliminate that risk entirely.
FIDO2 brought some compatibility challenges, but the payoff was substantial: Access can restrict access to internal systems to FIDO2 keys only, and all employees are now required to use their hardware keys. The result was both a major usability win and a massive security improvement.
DNS Filtering on the Same Network as 1.1.1.1
In 2020, Cloudflare Gateway launched to give customers protection against malware, ransomware, phishing, command-and-control traffic, shadow IT, and other internet-based risks across all ports and protocols. Gateway filters traffic according to customer-defined policies, and it runs on the same network as 1.1.1.1, the company’s DNS resolver.
The security team started with Gateway for DNS filtering across all offices. Since Gateway inherits the 1.1.1.1 network’s performance characteristics, any Cloudflare office—current or future—gets DNS filtering with no additional latency. Each office connects to its nearest data center and is protected from there.
For remote users, Cloudflare extended the same protection via the WARP client, which is also built on the 1.1.1.1 resolver. Deployed to the company’s endpoint fleet, WARP connects each device to the nearest Cloudflare data center and routes it through Gateway. This sits between the device and the internet, encrypting DNS traffic over DNS over HTTPS (DoH) for privacy, while Gateway uses Cloudflare Radar’s threat intelligence to categorize domains and block high-risk or suspicious ones globally.
Adding HTTP Filtering and Browser Isolation
DNS filtering blocks entire domains, which is a blunt instrument. The team wanted to block specific malicious URLs without cutting off access to the whole domain. Because Cloudflare One is an integrated platform, the deployment path was short: add the Cloudflare Root CA to endpoints and enable HTTP filtering in the Zero Trust dashboard.
HTTP filtering also enabled tenant control. With this feature, Gateway policies inspect custom HTTP headers to regulate access to corporate SaaS applications. If a request carries the header and targets an organizational account, access is granted. If the same header points to a personal or non-organizational account, the request can be blocked or opened in an isolated browser instead.
With DNS and HTTP layers covered, Cloudflare implemented Browser Isolation. All browser code executes in the cloud on Cloudflare’s network, which keeps malicious code and common data exfiltration techniques away from endpoints. Unlike some remote browser isolation products that introduce noticeable latency, Cloudflare’s version is designed to be seamless—allowing the security team to improve its posture without degrading the employee experience.
Email Security with Area 1
In early 2020, Cloudflare’s security team saw an increase in employee-reported phishing attempts. The company’s cloud email provider had solid spam filtering but fell short on blocking malicious threats and advanced attacks. With phishing volume and frequency on the rise, the team began evaluating purpose-built email security vendors.
Their requirements were clear: scan email attachments, analyze suspicious links, detect business email compromise, and integrate deeply with cloud-native email providers via APIs. After testing, Cloudflare chose Area 1’s solution internally in early 2020. The results were strong enough that Cloudflare acquired Area 1 in April 2022, bringing the same email protection it relied on to customers.
On the Horizon: CASB for SaaS Security
Following the acquisition of Vectrix in February 2022, Cloudflare is preparing to roll out its CASB product internally. SaaS applications now hold significant amounts of sensitive corporate data, making misconfigurations and overly permissive external access serious threats. Manual reviews for those issues are time-consuming, so automated scanning is a clear win.
CASB promises to reduce that burden by scanning SaaS instances for misconfigurations and identifying vulnerabilities in a few clicks. The security team has many SaaS applications to manage, and like customers, it’s looking for efficiency without compromising security standards.
Dogfooding as a Product Strategy
Cloudflare’s security team works directly with product teams to test new tools before they reach customers. Being the first consumer of its own products means the company gets real feedback from internal use, which improves both security posture and product quality. The Zero Trust rollout was an exercise in that philosophy—starting with a faster way to reach internal apps, and expanding one cloud-native security layer at a time.
