Deploying phishing-resistant MFA across the org

MFA dramatically reduces account takeover, but attackers have adapted: real-time phishing proxies (adversary-in-the-middle) relay one-time codes and push approvals, and MFA-fatigue attacks spam users until someone taps approve. CISA's guidance is unambiguous: the goal is phishing-resistant MFA, which those attacks cannot defeat.

Rank your factors honestly

• FIDO2 / WebAuthn security keys and passkeys (strongest). Origin-bound public-key cryptography; the credential only works on the genuine domain, so AiTM phishing fails outright.
• PIV / smart cards. Certificate-based, phishing-resistant; common in government and high-assurance estates.
• Authenticator app (TOTP) / number-matching push (interim). Better than SMS, but phishable via AiTM proxies. Number matching mitigates fatigue but not real-time relay.
• SMS / voice OTP (deprecate). Vulnerable to SIM-swap and interception; NIST discourages it as a primary factor. Keep only as a last-resort fallback where nothing else is possible.

Sequence the rollout

• Administrators and privileged accounts first: highest blast radius, smallest population, fastest win.
• Then internet-facing and high-risk roles (finance, executives, IT, developers with production access).
• Then the general population, in waves aligned to teams so support can absorb enrollment questions.
• Provision two authenticators per user (e.g. a security key plus a platform passkey) so a lost factor doesn't lock people out.

Close the bypasses

MFA you can route around is MFA you don't have. The most common escapes:

• Legacy authentication protocols (IMAP/POP/SMTP basic auth, legacy sign-in) that never prompt for MFA: disable them via conditional access.
• MFA-exempt accounts and "break-glass" logins: inventory them, protect break-glass with strong physical controls and monitoring.
• Session/token theft: enforce reasonable session lifetimes, token binding where available, and reauthentication for sensitive actions.
• Weak recovery: an SMS-based reset undermines a FIDO2 login; see below.

Enrollment and recovery are part of the threat model

Attackers target the weakest step. If enrollment or recovery falls back to a phishable factor, the whole scheme degrades to that factor's strength.

• Bind first-time enrollment to a trusted context (managed device, in-person / supervised, or an existing strong factor) rather than emailing a self-enroll link.
• For recovery, require another registered strong authenticator or a verified helpdesk process with identity proofing, not SMS or security questions.
• Harden the helpdesk against social engineering: callers requesting MFA resets are a primary attack vector, so require out-of-band identity verification and log every reset.
• Issue and register backup security keys for critical staff.