Turning on MFA is still the single best thing most businesses can do for account security. Microsoft’s research found that MFA cuts the risk of an account being compromised by more than 99.2% (Microsoft Research, “How effective is multifactor authentication at deterring cyberattacks?”).
But “we have MFA” no longer means “we’re safe”. Attackers now plan for it. They intercept text codes, flood people with push prompts, and relay sign-ins through fake pages that pass MFA along in real time. Whether MFA stops them depends on which kind you use.
Here’s how the common methods compare, how each one gets beaten, and what to move to first.
The short answer
| MFA method | How it’s usually beaten | Stops phishing? |
|---|---|---|
| Text message (SMS) or voice code | SIM swap, or the person types the code into a fake page | No |
| Code from an authenticator app | The person types the code into a fake page | No |
| Push approval (“Approve / Deny”) | Prompt flooding until someone taps Approve | No |
| Push with number matching | A fake page that relays the sign-in in real time | Partly |
| Passkey or FIDO2 security key | Very hard: it won’t sign in on a fake site | Yes |
CISA describes FIDO/WebAuthn as the only widely available phishing-resistant authentication, and calls SMS and voice codes a last resort (CISA, “More than a Password” and its phishing-resistant MFA fact sheet).
Why text codes and push approvals get bypassed
Text message codes have two weak points. The phone number can be moved to an attacker’s SIM (a SIM swap), and nothing stops a person typing the code into a convincing fake page. CISA’s December 2025 mobile guidance says plainly that SMS MFA is not phishing-resistant.
Push approvals fail because people approve things. In an MFA fatigue attack, the attacker already has the password and sends prompt after prompt, often late at night, until someone taps Approve to make it stop. CISA calls this “push bombing”.
Number matching fixes most of that. The sign-in screen shows a number and the person has to type it into the app, so a random prompt can’t be approved by accident. CISA calls it one of the best stopgaps for organisations that can’t yet move to phishing-resistant MFA. Microsoft Authenticator now uses number matching by default.
Codes and number matching still lose to relay pages. In an AiTM phishing attack, the person signs in on a fake page that passes everything to the real Microsoft page, including the MFA step. The attacker walks away with the signed-in session. The MFA worked; it just worked for the wrong person.
Why passkeys and security keys hold up
A passkey or FIDO2 security key is tied to the real website’s address. On a fake page, it simply won’t sign in. There is no code to type and nothing to approve by mistake, so the relay trick and prompt flooding both fail. That’s what phishing-resistant MFA means.
What MFA can’t stop on its own
Even strong MFA protects the sign-in. It doesn’t protect what happens after:
- Stolen sessions. If malware or a relay page steals the session token, the attacker skips sign-in entirely. See token theft in Microsoft 365.
- Device code sign-ins. In device code phishing, the person completes MFA on the real Microsoft page for the attacker.
- Weak recovery. If a help desk will reset MFA for anyone who calls with a good story, the method doesn’t matter.
That’s why MFA needs something watching the accounts after sign-in too.
A rollout order that works for a small business
- Turn MFA on for everyone. Any MFA beats none. In Microsoft 365, security defaults or Conditional Access do this.
- Retire text and voice codes wherever the app can be used instead.
- Make sure number matching is on for push approvals.
- Give passkeys or security keys to admins and finance staff first. They’re the accounts attackers want most.
- Lock down MFA resets. Call the person back on a known number before resetting their MFA.
- Watch for the signs MFA is being attacked: a burst of denied prompts, a new MFA method added out of the blue, a sign-in that passed MFA from an unusual place.
How Centeye Gatewatch helps
Centeye Gatewatch watches sign-ins across Microsoft 365 and Google Workspace for the attacks that get around MFA. It recognises floods of sign-in prompts and treats an approval that follows one as suspect. It spots stolen sessions replayed from someone else’s machine, and a new sign-in method added without anyone asking. When it finds a takeover, it ends the sessions and resets sign-in at the setting you choose.
New to these terms? See MFA fatigue, phishing-resistant MFA, or the full security glossary.