Why Cloudflare Eats Its Own Security Dogfood

When the next Log4j-style emergency hits, Cloudflare’s Security team doesn’t start from scratch. The team’s default response to a new threat — whether a publicly exploited vulnerability, a shift to remote work, or an emerging attacker — is to look first at Cloudflare’s own product portfolio. The company treats itself as just another customer, applying the same Zero Trust tools used by its enterprise clients.

This dogfooding culture is embedded in the Security team’s workflow. It has already replaced its corporate VPN with Cloudflare Access, deployed Purpose Justification for granular access controls, and used Magic + Gateway to block lateral movement from inside the network. Those are not one-off experiments; they reflect a standing policy: when a security problem appears, the first question is which Cloudflare product solves it.

Mapping Internal Threats to Product Responses

Several recurring security challenges map directly to Cloudflare’s own offerings:

  • Remote work blind spots. Connecting corporate devices to Gateway through the WARP application restores visibility into security threats regardless of device or network. These Zero Trust products block malware, phishing, and shadow IT, and let the Security team block threats instantly or stop sensitive data from leaving the organization — without adding latency for employees.
  • Growing internal tooling complexity. Access and Purpose Justification give administrators granular, context-aware application controls. The Identity and Access Management team builds policies that minimize data access, so employees only reach what they actually need. Policies apply instantly and scale as teams and tools evolve. Purpose Justification Capture also requires employees to state why they are visiting sensitive domains, which helps Cloudflare meet data policy requirements like GDPR.
  • Fast-moving engineering teams. Manual review of every pull request does not scale, so the Product Security Engineering team built a code review assist framework on Cloudflare Workers. The tool scans PRs for secrets, vulnerable dependencies, and binary security flags. Because it runs on Workers, the team can adapt it as new threats emerge and scale it to the hundreds of PRs generated weekly.

Enforcing FIDO2 with Access Policies

Not all second factors are equal. TOTP apps like Google Authenticator are strong, but they remain vulnerable to man-in-the-middle phishing attacks. For an organization where one phished privileged employee is a serious risk, that is unacceptable. FIDO2 security keys eliminate that phishing vector entirely, but support is not yet universal across every system.

Cloudflare’s answer was to enforce FIDO2 as the only acceptable second factor for any application protected by Cloudflare Access. Access policies are managed as Terraform code, with each one checked into source control. Group-based access control is enforced across all applications.

resource "cloudflare_access_policy" "prod_cloudflare_users" {
  application_id = cloudflare_access_application.prod_sandbox_access_application.id
  zone_id        = cloudflare_zone.prod_sandbox.id
  name           = "Allow "
  decision       = "allow"

  include {
    email_domain = ["cloudflare.com"]
    okta {
      # Require membership in Sandbox group
      name                 = ["ACL-ACCESS-sandbox"]
      identity_provider_id = cloudflare_access_identity_provider.okta_prod.id
    }
  }

  # Require a security key
  require {
    auth_method = "swk"
  }
}

The require block forces employees to authenticate with FIDO2 keys for all internal and external applications behind Access. Per RFC8176, the auth_method field specifies which values must come back from the OIDC provider in the amr field during login. The enforced swk value — "Proof of possession of a software-secured key" — corresponds to security key logins.

The impact was immediate. Before this change, many internal services accepted both soft tokens like TOTP and WebAuthn because a few systems did not yet support FIDO2. After enforcement, soft token usage dropped to near zero.

This image shows webauthn and "soft token" (totp) usage as a second factor, with soft token reaching zero usage when we enforced webauthn only.

A Permanent Testing Ground

The Security team does not just deploy Cloudflare products — it also gets first crack at testing them. Working directly with the Product team, internal teams dogfood features before launch. The goal is to build a better Internet, which means validating products internally and feeding feedback back into development before customers ever see them. As the company’s largest product consumer, the Security team both hardens its own defenses and improves the tools that enterprise customers rely on.