Multi-Factor Authentication (MFA)

A password proves only that someone knows a secret -- it says nothing about whether that someone is the legitimate account owner. Passwords are phished, stuffed from breach dumps, sprayed, and guessed at scale (see Passwords). MFA closes that gap by requiring proof of a second, independent factor before authentication succeeds. But not all MFA is equal: some factors stop real-time phishing attacks completely, while others -- SMS OTP in particular -- are routinely defeated by attackers today. This article ranks MFA options by real-world strength and aligns the guidance to NIST SP 800-63B (Digital Identity Guidelines) and the ACSC Essential Eight Maturity Model, the two reference frameworks most commonly required in security assessments.

Why Factor Choice Matters

MFA is not a single control -- it is a category of controls with very different failure modes. The attacks that matter most:

Real-Time (Adversary-in-the-Middle) Phishing

Tooling such as Evilginx and Modlishka sits a reverse proxy between the victim and the real login page. The victim enters their password and OTP/push approval into what looks like the real site; the proxy relays it to the real site in real time and steals the resulting session cookie. This defeats SMS OTP, authenticator app OTP (TOTP), and plain push notifications -- the user is doing everything "right" and still loses the account, because none of these factors are bound to the origin the user is actually talking to.

MFA Fatigue / Push Bombing

Attackers who already hold a valid password trigger repeated push notifications until the user approves one out of frustration or confusion (the technique used in the 2022 Uber and Cisco breaches). Plain "approve/deny" push is highly susceptible; number matching (the user must type a number shown on the login screen into the push prompt) substantially reduces this risk but does not eliminate phishing risk.

SIM Swapping and SS7 Interception

SMS-based OTP depends on the security of the mobile carrier and the telephone network, neither of which the relying party controls. SIM swaps (social-engineering a carrier into porting a number) and SS7 protocol attacks (intercepting SMS in transit) allow an attacker to receive the victim's OTP without touching the victim's device.

Malware and Session Token Theft

Infostealer malware increasingly targets browser session cookies and locally stored TOTP seeds directly, bypassing the authentication step entirely once a device is compromised. This is a defense-in-depth argument for hardware-backed factors (private keys that never leave a secure element) over software-based ones.

The only factor class that resists adversary-in-the-middle phishing is one that cryptographically binds the authentication response to the specific origin (domain) being authenticated against. This is what NIST calls "verifier impersonation resistance" and what is commonly called phishing-resistant MFA: FIDO2/WebAuthn and PKI-based certificates. Everything else -- OTP, push, SMS -- can be phished or relayed by a sufficiently motivated attacker regardless of how "strong" the underlying code generation is.

Recommended Order of Strength

Ranked strongest to weakest, based on resistance to phishing, SIM/network attacks, and fatigue-style social engineering:

Practical takeaway: default new deployments to rank 1-3 (FIDO2/passkeys/smart cards) for anything privileged or sensitive. Use rank 5-6 as a realistic minimum baseline for general workforce and consumer accounts where hardware keys aren't yet feasible. Treat SMS and email OTP (ranks 9-10) as a last-resort fallback only, never the primary or only factor.

Alignment with NIST SP 800-63B

NIST SP 800-63B defines three Authenticator Assurance Levels (AAL), each requiring progressively stronger proof of factor possession:

Two details from SP 800-63B that materially change common practice:

• SMS is a "restricted authenticator." NIST does not ban it outright, but requires the organization to document additional risk mitigations (e.g. verifying the OTP isn't delivered over VoIP, providing an alternate phishing-resistant path) and to have a migration plan away from it. Treat any continued use of SMS OTP as a documented, time-limited exception, not a steady-state control.
• AAL3 is defined by verifier impersonation resistance, not merely "two factors." An organization can have "MFA everywhere" and still sit at AAL2 if every factor in use is OTP- or push-based. Reaching AAL3 requires phishing-resistant hardware authenticators specifically.

Alignment with the ACSC Essential Eight

Multi-factor authentication is one of the eight mitigation strategies in the Australian Cyber Security Centre's Essential Eight, and its Maturity Model (as updated November 2023) is explicitly built on NIST SP 800-63B's authenticator types. The Essential Eight is scored across three maturity levels, and the bar for MFA rises significantly between ML1 and ML2:

At every maturity level, successful and unsuccessful MFA events must be centrally logged, and those logs must be protected from unauthorized modification or deletion (a requirement from ML2 onward in most implementation guidance).

Authenticator types explicitly excluded from ML1 upward: SMS sign-in and email OTP are not permitted authenticators at any Essential Eight maturity level. From ML2 onward, this exclusion extends to essentially every non-phishing-resistant method: authenticator app push (with or without number matching), authenticator app OTP, OATH hardware/software tokens, and password-plus-device-compliance checks. The only authenticator category permitted at ML2 and ML3 is "multi-factor crypto hardware" -- FIDO2 security keys, hardware-backed passkeys, smart cards, and Windows Hello for Business backed by a hardware TPM.

Practical implication: an organization that has deployed authenticator-app push or TOTP everywhere has satisfied ML1, but is capped there. Reaching ML2 or ML3 -- required by many Australian government and regulated-sector contracts -- requires a genuine migration to hardware-backed, phishing-resistant authenticators, not just "turning MFA on."

Implementation Guidance by Use Case

Common Pitfalls

• Legacy authentication protocols left enabled. IMAP, POP3, and legacy SMTP AUTH frequently bypass MFA entirely because they predate conditional access frameworks. Disable legacy auth protocols organization-wide before claiming MFA coverage.
• No number matching on push notifications. Plain approve/deny push is the leading cause of successful MFA-fatigue compromises. Enable number matching as an immediate, low-cost mitigation while planning a phishing-resistant migration.
• Conditional access exclusions for "trusted" locations. Excluding MFA for users on the corporate LAN or a known IP range undermines the control -- Essential Eight ML1 explicitly requires MFA regardless of sign-in location.
• Single registered factor with no backup. Users who lose their only MFA device generate helpdesk load and pressure to create insecure workarounds. Require at least two independent registered factors per user.
• Recovery/backup codes stored insecurely. Backup codes are a bearer secret equivalent to a password -- if stored in plaintext notes or shared inboxes, they undermine the entire control.
• Treating "MFA enabled" as binary. An organization can have 100% MFA coverage and still be trivially phishable if every factor in use is OTP- or push-based. Track which factors are deployed, not just whether MFA is on.

Hardening Checklist

References

• NIST SP 800-63B -- Digital Identity Guidelines: Authentication and Lifecycle Management
• ACSC Essential Eight Maturity Model
• ACSC -- Implementing Multi-Factor Authentication
• CISA -- Implementing Phishing-Resistant MFA
• OWASP Multifactor Authentication Cheat Sheet
• FIDO Alliance -- FIDO2 and WebAuthn Overview
• Passwords