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.