Multi-Factor Authentication: Methods and Best Practices

Microsoft's own security guidance reports 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

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 — the property NIST SP 800-63B defines as "verifier impersonation resistance"; 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.

A practical rollout sequence

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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).
7. 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 — consistent with CISA's guidance recommending phishing-resistant MFA as the strongest available implementation.

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