Microsoft's own security telemetry has repeatedly found that MFA blocks the large majority of account-compromise attempts — yet MFA rollouts are still one of the most commonly incomplete security controls at small and mid-sized organizations, usually because of an unplanned rollout that generated support tickets and pushback rather than a bad initial decision. This guide compares the available MFA methods and covers how to roll MFA out in a way that actually sticks.
MFA methods compared
| Method | Phishing Resistance | Deployment Friction | Notes |
|---|---|---|---|
| SMS / text message code | Low | Very low | Vulnerable to SIM-swapping and interception; acceptable fallback only, not a primary method |
| Voice call code | Low | Very low | Same weaknesses as SMS |
| Authenticator app (TOTP code) | Medium | Low | Widely supported; still phishable via a fake login page that relays the code in real time |
| Push notification approval | Medium | Low | Convenient; vulnerable to MFA fatigue attacks unless number-matching is enabled — see Authentication Attacks |
| Hardware security key (FIDO2/WebAuthn) | High | Medium | Cryptographically bound to the real destination — resists phishing by design, not just by user vigilance |
| Platform authenticator / passkey | High | Low once enrolled | Built into modern devices (Windows Hello, Touch ID); see Passwordless Authentication and Passkeys |
Why phishing resistance varies so much between methods
A code-based method (SMS, authenticator app) transmits a value that a phishing page can relay to the real login page in real time — this is exactly how adversary-in-the-middle phishing kits defeat "regular" MFA. A phishing-resistant method (hardware key, passkey) instead performs a cryptographic exchange bound to the actual domain being authenticated to; a fake domain simply cannot complete that exchange, regardless of how convincing the fake page looks to a human. This is the single most important distinction in this table, and it's why current guidance increasingly recommends hardware-backed methods for high-value accounts specifically — see Authentication Attacks for how adversary-in-the-middle and MFA fatigue attacks actually work.
'We have MFA' is not one security posture
An organization where every account uses SMS-only MFA and an organization where every account uses hardware keys have both technically "enabled MFA" — but face very different real-world risk from a targeted phishing campaign. When reporting MFA coverage internally or to an auditor, method strength matters as much as coverage percentage.
A practical rollout sequence
- Start with the highest-value accounts, not the largest group. Administrative and executive accounts should get MFA — ideally hardware-key or platform-authenticator MFA — before a broad rollout to general staff begins.
- Choose one primary method for general staff, with a documented fallback. Standardizing reduces support burden; an authenticator app is the most common practical default, with SMS as a documented (not default) fallback for staff without a suitable device.
- Communicate before enforcing, not during. A rollout that surprises staff with a mandatory enrollment prompt generates far more support tickets than one preceded by short advance notice and a self-enrollment window.
- Enable number-matching on push notifications if using push-based MFA, specifically to defend against MFA fatigue attacks (see Authentication Attacks) — a bare "approve/deny" push is the weakest form of push MFA.
- Eliminate legacy authentication protocols that bypass MFA entirely — this is frequently the actual gap behind an "MFA is enabled but accounts still got compromised" incident, not a weakness in MFA itself.
- Plan for lost-device and lockout scenarios before they happen — a documented, verified recovery process prevents both a security gap (weak recovery process) and a support crisis (no defined process at all).
- Migrate high-value accounts to hardware-key or passkey methods over time, treating SMS/voice as a transitional method to retire, not a permanent fallback.
Common mistakes
- Rolling out MFA to everyone at once without staged communication, producing a support-desk spike that damages appetite for future security initiatives.
- Leaving legacy authentication protocols enabled "for compatibility," which lets attackers bypass MFA entirely for any application still using them.
- Using bare push-notification approval without number-matching, leaving the door open to MFA fatigue attacks.
- Treating MFA enrollment as optional or exception-prone, leaving exactly the highest-risk accounts (an executive who found MFA setup inconvenient) without protection.
- No tested recovery process for lost devices, which either creates a security bypass (an easy support-desk override) or a real business disruption when someone is locked out.
FAQ
Is SMS-based MFA still worth enabling if it's the weakest method? Yes — SMS MFA is still dramatically better than no MFA against the most common, unsophisticated attacks (credential stuffing, basic password guessing). It should not be the primary method for high-value accounts, but as a broad baseline over no MFA, it remains a meaningful improvement.
How is a hardware security key different from an authenticator app? Both are "something you have," but a hardware key performs a cryptographic challenge-response bound to the actual website domain, which a phishing page cannot successfully replicate — an authenticator app's time-based code has no such binding and can be relayed by a sophisticated phishing kit in real time.
Does enabling MFA replace the need for a strong password? No — MFA and password strength are complementary, not substitutes for each other. See NIST Password Guidelines for why length-based password policy still matters even with MFA enforced.
What's the fastest way to get meaningful risk reduction from a limited MFA budget? Prioritize administrative and financially sensitive accounts for the strongest available method (hardware key or platform authenticator) before broadening standard MFA to the full organization — see Privileged Identity Management and Privileged Access.
Related reading
- Authentication Fundamentals
- Passwordless Authentication and Passkeys
- Microsoft Entra Conditional Access: A Practical Guide
- Authentication Attacks
- Cyber Insurance Requirements — why MFA coverage is now directly verified by insurance underwriters
- Download: MFA Rollout Checklist