Beyond the VPN: How Cloudflare Moved to Phishing-Resistant Logins
For years, Cloudflare protected its internal systems with a classic VPN architecture. Employees connected through the VPN to reach applications and servers, and login security relied on time-based one-time passcodes (TOTP) from authenticator apps. The problem: only a handful of internal applications required that second factor, and the perimeter-based model left the door open for phishing that could bypass TOTP entirely. The fix was a phased migration to FIDO2/WebAuthn hardware keys combined with Cloudflare’s own Zero Trust access layer.
Why FIDO2 Beats TOTP
FIDO2 is the umbrella term for a set of open authentication standards — WebAuthn on the web side and CTAP1 (U2F) and CTAP2 on the client-to-authenticator side. The important detail is that the protocol binds authentication to a specific domain. A security key produces a different response when a user is tricked into logging into a lookalike site, making phishing attacks that proxy credentials useless.
Cloudflare issues two FIPS-validated YubiKeys to every employee. One model (the 5 Nano or 5C Nano) is meant to live permanently in a laptop's USB slot; the other (the 5 NFC or 5C NFC) works with desktops and mobile devices over NFC or USB-C. The rollout began at a company-wide event in late 2018, where employees enrolled their keys during a workshop. But many internal applications did not yet support WebAuthn, so full enforcement was off the table.
Selective Enforcement First
Cloudflare migrated its internal applications to its own Zero Trust access proxy — Cloudflare Access — in parallel with issuing keys. Access gave the security team a way to enforce hardware keys on a few select applications before requiring them everywhere.
The enforcement mechanism relies on the identity provider passing a signal — specifically, the swk value in the OAuth2 flow — indicating proof of possession of a security key. If a user logged in without a hardware key, they'd see an error instructing them to try again and press the key when prompted. The first service enforced this way went live on July 29, 2020. Within two months, security key usage jumped dramatically as employees got comfortable with the new flow.
This migration also solved an access-control problem. A VPN authenticates network traffic but doesn't tell applications who is behind it. Each legacy app had to invent its own permission model. Moving services behind Cloudflare Access allowed the team to create role-based access control (RBAC) groups defining each person's permission level. More than 600 internal sites now use this pattern, all requiring a security key at login.
Dropping TOTP Entirely
In February 2021, employees reported receiving phone calls from someone impersonating IT. The social engineering attempts pushed Cloudflare to accelerate the final step: disabling all multi-factor methods except WebAuthn. SMS and TOTP were turned off across the board.
A small fraction of logins still appears as "soft token" in the numbers because of the offline recovery process. Employees who lose their keys need a fallback to regain access, reached through a separate, secure channel. Issuing a backup key to every employee is the recommended way to minimize this edge case.
Extending Keys to SSH
HTTP-based apps were covered, but SSH and other non-HTTP protocols still relied on the old model. Cloudflare deployed Cloudflare Tunnel to all production infrastructure, pairing the cloudflared client with Access policies that require a security key. Each server runs a systemd-managed tunnel with its own configuration file. That means a single place to manage access control lists, rather than maintaining separate SSH key infrastructure per machine.
Operators connect by using the ProxyCommand SSH directive to invoke cloudflared, authenticate through Access, and forward the connection over the tunnel. OpenSSH has supported FIDO2 natively since version 8.2, but the unified policy model is the reason Cloudflare chose the tunnel approach: all access lists stay in one system, regardless of protocol.
Lessons for a Hardware Key Rollout
The full transition took a few years. The takeaway for other organizations is that selective enforcement for at least a month — enough time for people on vacation to catch up — is a critical step. It gives users a chance to learn the new hardware before it becomes mandatory, and gives security teams a data point on real-world adoption before the hard cutover.



