Phishing-Resistant MFA for Internal Tools

Cloudflare has extended its zero-trust access platform to let administrators require physical hard keys for authentication to internal applications. The move follows a well-known Twitter breach in which attackers used spear phishing to steal an employee’s credentials and gain access to an administrative panel, allowing them to reset passwords for high-profile accounts.

The new capability directly addresses the weakness that made that attack possible: even when organizations issue hardware security keys, users often have the option to fall back to less secure multifactor authentication methods. Those fallbacks—SMS codes, app-based one-time passcodes—can be intercepted or socially engineered. A hard key, by contrast, requires possession of a physical device and cannot be shared remotely.

Cloudflare’s own administrative panel is protected by this requirement now, and the feature is available to all Cloudflare Access customers at no additional cost.

The Problem With Fallback MFA

Cloudflare’s internal admin panel lets support and engineering staff manage customer accounts, toggle features, and troubleshoot issues. The tool has its own permission tiers, inactivity timeouts, and audit reviews, but the security perimeter around it was historically a VPN.

That VPN model had two major drawbacks:

  • Poor segmentation: Anyone on the VPN could reach the login page, regardless of whether they needed access to the panel.
  • Limited signal: Authentication was limited to a password and an MFA code, with no way to factor in device health or other context.

Cloudflare migrated the panel to Cloudflare Access about two years ago, replacing the VPN with identity-based checks on every request. Access allowed administrators to restrict specific tools to named users and offered a full audit log of authenticated requests, exportable to a SIEM.

But the identity provider integrated with Access supported multiple MFA methods, and users could choose a weaker option at login. That undermined the security of the hardware keys Cloudflare issued to every employee—there was no way to enforce their use on an app-by-app basis.

Enforcing Hard Keys at the Edge

The solution came from an existing part of the WebAuthn and FIDO2 ecosystem: the Authentication Method Reference Values standard, or amr, defined in RFC 8176. When a user authenticates through an identity provider, that provider can pass along a field describing which MFA method was used—hwk for hardware keys, otp for one-time passcodes, and so on.

Cloudflare Access already receives this information during the login flow and normally stores it in a JSON Web Token (JWT) it issues to the user’s browser. That token is checked on every request to the protected application. The new feature lets administrators inspect the amr value and enforce a rule on it, just as they would on user identity or any other attribute.

In practical terms, an admin can now add a "Require MFA" rule to any Access policy that specifies which authentication factors are acceptable. In Cloudflare’s own configuration, the rule blocks TOTP codes and only allows methods such as:

  • Hard keys that support WebAuthn or FIDO2
  • Platform authenticators tied to physical devices, such as Apple Touch ID or Windows Hello

If a user (or an attacker) authenticates to the identity provider with a weaker method, Access rejects the attempt even though the identity provider allowed the login. The access decision happens at Cloudflare’s edge, so no changes to the application’s server code are required.

What You Need to Get Started

To use the feature, you need an identity provider that supports the RFC 8176 amr setting. Today that means Okta or Azure Active Directory, according to Cloudflare. The platform’s documentation will be updated as other providers add support.

For existing Cloudflare Access applications, the configuration steps are straightforward. Navigate to the application and the rules that define who can reach it, then add a new rule in the "Require" section. Select "MFA" from the dropdown and choose which authentication options should be mandatory.

The feature is included with Cloudflare Access, which offers a free tier covering 50 seats. Formal documentation is available on the Cloudflare developers site.