Leaked passwords are close to unavoidable: phishing sites, password reuse and credential stuffing all hand attackers working credentials. Multi-factor authentication (MFA) requires a second, different type of factor (something you know, something you have, something you are), so a stolen password alone is not enough to sign in[1]. CISA has consistently urged organizations to enable MFA for all users and all services, but it also warns that not all MFA is equally secure: some forms can still be defeated by phishing, push bombing, SS7 protocol weaknesses or SIM swapping[1].

This guide is for IT staff and managers planning or reviewing an MFA rollout. It compares the strength of each method, explains how attackers get around MFA, and covers where to start, plus the account recovery and exception handling that make or break a deployment.

MFA methods, weakest to strongest

CISA ranks MFA methods by how well they withstand phishing, push bombing, SS7 attacks and SIM swapping[1]. From weakest to strongest:

  1. SMS or voice codes: can be phished, and can be intercepted through SS7 weaknesses or SIM swapping; CISA says they should only be a last resort or a temporary step while moving to something stronger[1]. NIST SP 800-63B-4 classifies out-of-band authentication over the public switched telephone network (PSTN) as "restricted", and verifiers that use it must make alternative authenticator types available[2].
  2. Approve-only push notifications: not exposed to SS7 or SIM swapping, but vulnerable to push bombing and simple user error[1]. NIST SP 800-63B-4 states that asking users to compare a code and then tap approve is no longer acceptable, because fatigue leads people to approve without really comparing; it instead requires the code to be transferred between the two channels, for example by typing the number shown on the sign-in screen into the app[2].
  3. One-time passwords (OTP) from an authenticator app or hardware token, and push with number matching: resistant to push bombing but still vulnerable to phishing sites that relay codes in real time[1]. CISA considers these the best options for small and medium-sized businesses that cannot yet deploy phishing-resistant MFA[1].
  4. Phishing-resistant MFA, meaning FIDO2/WebAuthn (including passkeys) and PKI smart cards: what CISA calls the "gold standard" of MFA[1].

Why FIDO2 resists phishing

NIST defines phishing resistance as the ability of the authentication protocol to prevent disclosure of authentication secrets to an impostor verifier[2]. Any method that relies on the user manually entering a value, such as OTP or SMS codes, is not phishing-resistant, because the typed value is not bound to the session being authenticated and a fake site can simply relay it to the real one[2]. FIDO2/WebAuthn uses verifier name binding: the credential only responds to the site it was registered with, so a pixel-perfect phishing page still cannot obtain a response that works on the real site[2].

Passkeys

A passkey is a FIDO-based sign-in credential that can live on a phone, a computer or a hardware security key, and is unlocked the same way the user unlocks the device (fingerprint, face or PIN)[3]. Passkeys come as synced passkeys, which are shared across a user's devices, and device-bound passkeys, which stay on a single device; the FIDO Alliance notes that device-bound passkeys on hardware security keys offer the highest assurance[3]. Under NIST's rules, syncable authenticators cannot be used at the highest assurance level, AAL3, because their private keys are exportable[2]. In practice, synced passkeys are a large improvement for most staff, while domain administrators, cloud super-admins and other privileged accounts are better served by hardware security keys.

How attackers get around MFA

Push bombing (MFA fatigue)

With a stolen password, the attacker triggers sign-in after sign-in so the user's phone fills with push prompts, until the user approves one by accident or out of annoyance[4]. MITRE ATT&CK tracks this as technique T1621, Multi-Factor Authentication Request Generation, and lists mitigations including methods that require entering a code from the sign-in screen, limits on the number of MFA requests within a period of time, and training users to approve only requests they initiated and to report unexpected ones[5]. Number matching makes the user type the number displayed on the sign-in screen into the app before approving; an attacker who is not sitting in front of that screen cannot get the user to approve "just to make it stop"[4]. NIST also recommends that verifiers limit the rate or total number of push notifications[2].

Adversary-in-the-middle (AiTM) phishing

The other common bypass does not bother the user at all. A phishing site relays traffic between the user and the real sign-in page; the user types the password and code, or approves the push, and the attacker steals the session cookie issued after sign-in, taking over a session that has already passed MFA[6]. In the cases Microsoft investigated, attackers started payment fraud as little as five minutes after stealing the session[6]. The countermeasures are phishing-resistant MFA plus conditional access (device compliance, location, IP and similar signals) and monitoring for suspicious sign-ins[6]. See phishing and business email compromise for how this feeds into BEC.

Going through account recovery

If a "lost phone" can be fixed with a single call to the help desk, an attacker posing as the employee can make the same call. MFA is only as strong as the weakest sign-in or recovery path, so recovery needs the same rigor as sign-in (see below).

Where to start

CISA suggests prioritizing with two questions: which resources most need protecting, and which users are high-value targets[1]? Attackers often go after email, file servers, remote access systems and identity servers such as Active Directory; system administrators, attorneys with e-discovery rights over mailboxes, and HR staff with access to personnel records are typical high-value accounts[1]. That gives a sensible order:

  1. Email and SSO/identity platforms: the mailbox is the hub for BEC and password resets, and most hosted mail and SSO services already support FIDO, which makes them good starting points[1].
  2. VPN and all remote access: SSL VPN, remote desktop gateways and vendor remote-support accounts. For the rest of the hardening work on these devices, see the edge device hardening checklist.
  3. Administrator and privileged accounts: domain admins, firewall and virtualization management interfaces, backup systems. CISA and partner agencies recommend prioritizing phishing-resistant MFA for administrator and privileged accounts[7].
  4. Cloud consoles and SaaS admin portals: a stolen cloud super-admin account usually exposes the entire tenant.
  5. High-value users: finance, HR, legal, executives and their assistants.
  6. Everyone and everything else.

Start with a pilot group such as the help desk and IT system administrators, then expand using what you learn[1]. For systems that cannot support MFA, CISA recommends planning an upgrade or migration and escalating the risk to senior leadership[1].

Account recovery and exceptions

  • Register at least two authenticators per person: for example a passkey on the phone plus a backup hardware key, so a new or lost phone does not lock anyone out.
  • Design recovery deliberately: NIST recognizes saved recovery codes, issued recovery codes, pre-registered recovery contacts and repeated identity proofing as account recovery methods, and every recovery event must trigger a notification to the user so misuse is caught early[2].
  • Make help-desk MFA resets verify identity properly: for example a video check against ID or confirmation by the user's manager, with notification to the user and the security team and a record of the reset.
  • Give exceptions an expiry date and compensating controls: where legacy systems, shared accounts or production equipment cannot do MFA, use network segmentation, jump hosts or source-IP restrictions, keep a register, and review it regularly.
  • Monitor and alert: review MFA lockout and alert settings, track denied MFA attempts[7], and watch for bursts of push prompts, sign-ins from unusual locations and newly registered authenticators.

Action checklist

  • Inventory every external sign-in point (email, SSO, VPN, remote desktop, cloud consoles, SaaS admin portals) and the MFA method each uses today.
  • Turn on MFA anywhere it is missing; even OTP is far better than nothing while you plan the next step.
  • Disable approve-only push in favor of number matching, and set limits and alerts on push volume.
  • Move administrators and privileged accounts to FIDO2 hardware keys or passkeys first; keep SMS codes only as a transition.
  • Use conditional access to restrict where management interfaces can be reached from and to require compliant devices.
  • Write down the MFA reset and account recovery procedure, and rehearse a "lost phone" scenario at least once.
  • Review the exception register and accounts without MFA every quarter and report progress to management.
  • Follow account-takeover cases in advisories and incidents and use them in awareness training.