Your threat intelligence feed shows adversary-in-the-middle attacks bypassing TOTP and SMS codes in real time. Session tokens are harvested mid-login—no password compromise required. Traditional MFA stops credential stuffing. It does not stop a reverse-proxy phishing kit. Phishing-resistant MFA—FIDO2 passkeys, hardware security keys, certificate-based authentication—does. Deploying it across an enterprise takes planning. This checklist covers what to decide before, during, and after rollout.
What "phishing-resistant" actually means
Phishing-resistant authentication binds the credential to a specific origin. When a user completes a FIDO2 challenge on app.company.com, the browser or device signs a challenge that includes the origin in the cryptographic material. A reverse-proxy phishing kit that intercepts the login flow on app.company.com.evil.com receives nothing replayable—the signature is mathematically invalid for any origin other than the enrolled one.
Compare that to TOTP and SMS codes. Those are valid tokens a phishing proxy captures in real time and replays within their short validity window. Session-token theft via a reverse-proxy phishing kit requires no malware and no credential compromise—just a convincing fake site and a willing victim.
FIDO2 and WebAuthn-based methods fall into three workable categories: platform authenticators (device biometrics such as Touch ID and Windows Hello), roaming hardware keys (FIDO2 security keys), and certificate-based authentication via PIV or smart cards. Any of them block the session-harvesting class of attack that TOTP cannot. [source: https://www.sentinelone.com/cybersecurity-101/identity-security/phishing-resistant-mfa/]
Number-approval push MFA does not qualify. Neither does SMS OTP. If your compliance framework references NIST SP 800-63B AAL3, those requirements point directly at hardware-bound or platform-bound authenticators.
Pre-deployment: map your authentication surface
Before buying hardware or changing identity provider policies, map every authentication path in your environment.
Identity provider integrations. List every application federated through your IdP—Okta, Entra ID, Google Workspace, Ping Identity. These apps move together. Enforce phishing-resistant MFA at the IdP policy level and all federated apps inherit it simultaneously. Legacy protocols. SMTP AUTH, POP/IMAP, Exchange ActiveSync, and service accounts using basic authentication do not support FIDO2. You need a plan for each: disable the protocol, migrate the workload, or accept the residual risk with compensating controls documented in your risk register. Do not enforce phishing-resistant MFA org-wide until legacy protocols are cataloged. Unmanaged devices. Platform authenticators (Touch ID, Windows Hello) only work on enrolled, managed devices. A contractor on an unmanaged laptop cannot use your managed platform authenticator. They need a hardware key or a separate enforcement tier with its own policy. Service-to-service flows. Automated pipelines, CI/CD runners, and RPA bots are not human users. They need service principals with short-lived tokens or workload identity federation—not phishing-resistant MFA—but they surface as scope questions the moment you start writing enforcement policies.Rollout sequence: phase by risk tier
Enforce phishing-resistant MFA in risk order, not org-chart order.
Tier 1 — privileged access first. Administrators of your IdP, cloud consoles (AWS IAM, Azure AD global admin, GCP org admin), and security tooling carry the highest blast radius on compromise. These accounts belong on hardware keys or a phishing-resistant policy before any general rollout begins. Privileged account takeover is the most common entry point to infrastructure-wide incidents. [source: https://cybersecuritytime.com/phishing-resistant-mfa-checklist/] Tier 2 — developer and infrastructure access. Code repositories (GitHub, GitLab), production infrastructure consoles, and systems with direct access to customer data. Developers with SSH access to production environments should move to FIDO2 security keys or certificate-based SSH. Tier 3 — all-employee SaaS. Email, Slack, HR systems, and internal tooling. Platform authenticators work well here because most employees are on managed devices. Hardware key distribution at this scale adds meaningful cost; evaluate whether your device estate uniformly supports platform authenticators before committing to a hardware-key rollout for the full employee base. Tier 4 — customer-facing product admin. If your product exposes admin or power-user roles, passkeys are a credible authentication method to offer as a first-class option. [source: https://www.cloudflare.com/sase/use-cases/phishing-resistant-mfa/]Run enforcement policies in report-only mode first. Count the accounts that would fail, resolve each exception, then flip to hard enforcement.
Hardware key logistics
If you are deploying roaming hardware keys for privileged accounts or exception populations, procurement and distribution is a project in its own right.
Key selection. Evaluate keys against your OS and browser matrix. Most managed device fleets support platform authenticators for the general population; hardware keys are typically reserved for privileged roles and unmanaged-device exceptions. Two-key registration. Users must register a primary key and a backup at enrollment time. A lost primary with no backup generates a lockout ticket. Enforce the two-key rule at registration, not after the first loss. Inventory and revocation. Track issued key serial numbers against user accounts the same way you track physical access badges. Maintain a documented revocation and replacement process with defined response times. Lost key recovery. Define the fallback authentication path for a user who has lost all enrolled keys. The answer should be a supervised, identity-verified reset by IT—not a self-service email link, which reintroduces the phishing risk the hardware key was meant to remove.Enforcement policy and monitoring
Enforcement without monitoring creates blind spots your auditor will find before you do.
Conditional access scope. In Entra ID and Okta, scope phishing-resistant MFA requirements by application, device compliance state, and user role. Start narrow, expand progressively. A single blanket policy applied to all applications on day one breaks edge cases in production. Sign-in log analysis. Filter your IdP logs for authentications that satisfied phishing-resistant MFA versus those that satisfied weaker MFA methods. The gap is your residual risk surface until it closes. Exception tracking. Every account on a legacy-protocol exemption or an alternative MFA policy is a compensating control in name only. Log each exception in your risk register with a review date and a named owner. Alert on step-down. Some identity providers allow authentication to fall back from phishing-resistant to TOTP under specific device conditions. Alert on those step-downs—an attacker engineering a forced fallback is a documented technique.Persistent exceptions are the routine finding that extends audit windows. Getting them tracked, time-bounded, and owned is as important as getting privileged accounts enrolled on day one.
Phishing-resistant MFA enforcement is not a single policy change—it is a sequenced project that touches identity inventory, device management, legacy protocol remediation, and exception handling. CloudAnzen maps your identity and access controls to SOC 2 and ISO 27001 requirements continuously so the evidence is ready when the auditor is, not assembled the week before. Talk to us.