MFA (Multi-Factor Authentication)

MFA (Multi-Factor Authentication) requires two or more independent credentials to verify identity. The factors come from three categories: something you know (password, PIN), something you have (phone, hardware token, smart card), and something you are (fingerprint, face, voice). True MFA combines factors from at least two different categories.

Why MFA matters

Passwords alone are broken. Credential stuffing attacks, phishing kits, and database breaches mean any password not protected by MFA should be considered compromised. Microsoft's security data shows MFA blocks 99.9% of automated attacks.

For cloud accounts, MFA on the root or break-glass identity is non- negotiable. The 2019 Capital One breach, the 2020 Twitter Bitcoin scam, and dozens of smaller cloud breaches share a common root cause: no MFA on the privileged account that was compromised.

MFA factor types ranked by strength

Not all MFA is equal. From weakest to strongest:

1. SMS one-time codes: vulnerable to SIM-swap attacks. Better than nothing, but discouraged for high-value accounts.
2. TOTP authenticator apps (Google Authenticator, Authy, Microsoft Authenticator): time-based codes generated locally. Phishing- resistant against most attacks but still vulnerable to real-time relay phishing.
3. Push notifications (Microsoft Authenticator, Duo): approve from trusted device. Easier UX than TOTP. Vulnerable to MFA fatigue attacks if users blindly approve.
4. Hardware security keys (YubiKey, Google Titan): FIDO2 / WebAuthn protocol. Phishing-resistant by design - the key cryptographically binds to the legitimate domain.
5. Passkeys (FIDO2 with platform authenticator): the newest pattern. Cryptographic credential bound to the device's secure enclave. Resistant to phishing AND eliminates the password.

MFA exam topics

• CompTIA Security+: the three factors, MFA vs 2FA, push fatigue attacks, conditional MFA, FIDO2/WebAuthn standards.
• AZ-900 / AZ-500: Conditional Access in Microsoft Entra ID, per-user MFA vs Conditional Access policies, security defaults.
• AWS Cloud Practitioner / SAA: MFA on root account, IAM user MFA, MFA-protected API actions.
• CISSP: the broader authentication taxonomy - knowledge factors, possession factors, inherence factors, location factors, time factors.

Common MFA implementation mistakes

• Allowing SMS as the only second factor.
• Not requiring MFA for break-glass or emergency access accounts.
• Allowing MFA registration over an unauthenticated channel (an attacker with a stolen password can register their own phone).
• Failing to require MFA reauthentication for sensitive actions like changing passwords or modifying IAM policies.
• Sharing MFA tokens across team members instead of using individual hardware keys.

For any production cloud workload, the baseline is hardware keys for administrators and TOTP or push for regular users. SMS should be a fallback only, never the primary factor.