🔑 Authentication Factors
Authentication proves identity. Multi-Factor Authentication (MFA) requires a user to present two or more independent verification factors before access is granted. The combination of factors makes credential compromise far harder for attackers — knowing a password is not enough if a second factor is required.
Something You Know
Knowledge factors: passwords, PINs, security questions. This is the weakest category because knowledge can be stolen, guessed, phished, or brute-forced.
- Passwords — most common, most abused
- PIN numbers — typically 4–8 digits
- Security questions — often guessable from social media
- Knowledge-based authentication (KBA) — increasingly deprecated
Something You Have
Possession factors: physical or virtual tokens that generate or store cryptographic credentials. Far stronger than knowledge factors because an attacker must physically or logically steal the device.
- TOTP authenticator apps (Google Authenticator, Authy)
- SMS one-time passwords (weakest possession factor)
- Hardware security keys (YubiKey, Titan Key)
- Smart cards and PIV credentials
- Push notification apps (Duo, Okta Verify)
Something You Are
Inherence factors: biometric characteristics unique to the individual. Increasingly deployed as the primary factor in passkey flows where the biometric unlocks the device-stored cryptographic key.
- Fingerprint — Touch ID, Windows Hello
- Face recognition — Face ID, Windows Hello
- Iris scanning — high-security environments
- Voice recognition — limited adoption
- Behavioral biometrics — typing cadence, mouse dynamics
Why Passwords Alone Fail
Credential stuffing attacks use billions of leaked username/password pairs from prior breaches against new targets. Password reuse across sites means one breach compromises many accounts. Phishing harvests credentials directly. Brute-force and password spraying exploit weak or default passwords. Microsoft's telemetry indicates that over 99.9% of account takeover attacks on their platform are stopped by MFA. No other single control has comparable impact at this cost.
MFA vs 2FA: Two-Factor Authentication (2FA) is a subset of MFA requiring exactly two factors. MFA requires two or more. In practice the terms are often used interchangeably. The important distinction is that using two forms of the same factor category (e.g., two passwords) does not constitute MFA — the factors must come from different categories.
📱 MFA Methods Comparison
Not all MFA is created equal. The spectrum ranges from SMS OTP (convenient but phishable and SIM-swappable) to FIDO2 hardware keys (phishing-resistant by cryptographic design). Choosing the right method depends on threat model, user population, and compliance requirements.
| Method | Phishing Resistant | SIM-Swap Resistant | Cost | User Friction | Notes |
|---|---|---|---|---|---|
| SMS OTP | No | No | Low / Free | Low | SIM-swap, SS7 interception, real-time phishing all bypass SMS |
| TOTP App | No | Yes | Free | Low–Medium | Google Authenticator, Authy, Microsoft Authenticator. Still phishable in real-time (AiTM) |
| Push Notification | No | Yes | Medium | Very Low | Duo, Okta. Number matching mitigates push fatigue. Still AiTM-phishable |
| FIDO2 / Hardware Key | Yes | Yes | $25–$60/key | Low–Medium | YubiKey, Google Titan Key. Cryptographically bound to origin — phishing is impossible |
| Passkeys (Platform) | Yes | Yes | Free | Very Low | Apple, Google, Microsoft. Synced across devices. No additional hardware required |
| Smart Card / PIV | Yes | Yes | High | Medium | Government/enterprise use. Requires card reader infrastructure. NIST 800-73 |
TOTP / HOTP — How It Works
Time-based OTP (TOTP, RFC 6238) generates a 6-digit code by combining a shared secret with the current Unix timestamp (30-second window). HMAC-based OTP (HOTP, RFC 4226) uses a counter instead of time. The server and client both compute the code independently — no transmission of the secret occurs at authentication time.
- Shared secret seeded during enrollment (QR code)
- TOTP: HMAC-SHA1(secret, floor(time/30))
- 30-second validity window (TOTP)
- Authy offers encrypted cloud backup of TOTP secrets
Push Notification MFA
The user receives a push notification to an enrolled mobile app (Duo, Okta Verify, Microsoft Authenticator) and approves by tapping. More user-friendly than TOTP but vulnerable to push bombing (MFA fatigue) attacks where attackers spam requests hoping the user accidentally approves.
- Number matching: app displays a number that must match the login screen
- Geographic context: shows login location in the notification
- Rate limiting: block after N failed push attempts
- Consider requiring number matching or geo-context display
🔐 FIDO2 & Passkeys
FIDO2 is the umbrella standard from the FIDO Alliance covering WebAuthn (W3C) and CTAP2 (Client-to-Authenticator Protocol). It enables strong, phishing-resistant authentication using public-key cryptography. Passkeys are discoverable FIDO2 credentials that replace passwords entirely.
How WebAuthn Works
During registration, the authenticator generates a public/private key pair bound to the relying party's origin (domain). The public key is stored on the server. During authentication, the server sends a challenge; the authenticator signs it with the private key. The private key never leaves the device — there is nothing to steal from the server.
- Origin-bound: key pair tied to exact domain (no cross-domain phishing)
- Challenge-response: replay attacks are impossible
- User verification: PIN or biometric unlocks the private key
- No shared secret: server stores only a public key
Passkeys vs Roaming Authenticators
Passkeys (discoverable credentials) are synced across devices via platform cloud accounts — they are convenient and no hardware is required. Roaming authenticators (hardware keys like YubiKey) are physically separate devices that work across any computer via USB/NFC.
- Platform passkeys: iOS Keychain, Google Password Manager, Windows Hello
- Synced passkeys: available on all signed-in devices automatically
- Hardware keys (YubiKey, Titan): not synced, require physical possession
- Hardware keys preferred for highest-security accounts
- Platform passkeys excellent for consumer / broad-deployment scenarios
Passkey Ecosystem Support
Major websites and platforms have deployed passkey support, making password-free login accessible to billions of users without additional hardware.
- Google: passkeys for all Google accounts
- Apple: passkeys in iCloud Keychain (iOS 16+, macOS 13+)
- Microsoft: Windows Hello for Business + Microsoft accounts
- GitHub: passkeys for developer accounts
- 1Password, Dashlane: cross-platform passkey management
Why Passkeys Are Phishing-Resistant
Traditional phishing works by redirecting users to a fake site that harvests their password (and TOTP code in real-time AiTM attacks). Passkeys cannot be phished because the cryptographic key pair is mathematically bound to the exact origin (https://accounts.google.com is different from https://accounts.g00gle.com). When the user is on the attacker's site, the passkey challenge for the legitimate site cannot be signed — authentication fails. No amount of social engineering can trick the cryptographic binding.
🏢 MFA for Enterprise
Enterprise MFA goes beyond simple enrollment — it involves Conditional Access policies, risk-based adaptive authentication, step-up requirements for sensitive operations, and defense against sophisticated bypass techniques.
Conditional Access
Policy-based access control that evaluates signals (user identity, device compliance, location, risk score) to determine whether to grant access, require MFA, block, or trigger a session restriction. The "policy engine" of Zero Trust.
- Azure Entra Conditional Access: industry standard for Microsoft shops
- Okta FastPass + Adaptive MFA: behavior-based risk scoring
- Signals: device compliance, IP risk, sign-in frequency, user risk level
- Require MFA for all cloud app access from unmanaged devices
- Block legacy auth protocols (IMAP, SMTP AUTH, Basic Auth)
Risk-Based Adaptive MFA
Rather than always requiring MFA, adaptive systems evaluate risk per authentication event. Low-risk requests (managed device, familiar location, normal hours) may pass with password only; high-risk requests trigger step-up challenges.
- Impossible travel detection: user can't be in NYC and London simultaneously
- Unfamiliar location: new country or anonymous IP proxy
- Leaked credential detection: integrate with breach databases
- Behavioral baseline: abnormal access patterns trigger challenge
- Step-up: extra MFA required before sensitive actions (wire transfer, admin console)
MFA Fatigue Attacks
Adversaries who have obtained valid credentials use automated tools to bombard the victim with MFA push notifications — counting on the user to accidentally approve or become frustrated and approve to stop the notifications. High-profile victim: Uber (2022) — engineer approved a push after social engineering confirmed the request.
- Mitigations: require number matching in push notification
- Add location/device context to notification
- Rate-limit consecutive MFA failures
- Alert security team on repeated failures
- Migrate high-privilege users to FIDO2 / passkeys
Adversary-in-the-Middle (AiTM) Phishing
Tools like Evilginx2 and Modlishka act as transparent reverse proxies between the victim and legitimate site. They harvest the session cookie after MFA completes — bypassing MFA entirely because they steal the authenticated session, not credentials alone.
- Evilginx2: reverse proxy phishing framework used in real attacks
- Modlishka: similar tool, also widely used
- Defeated by: FIDO2 / WebAuthn (origin binding defeats AiTM)
- Detection: impossible travel, abnormal session characteristics
- Mitigation: Entra ID token binding, continuous access evaluation
🚀 Deploying MFA
Successful MFA deployment requires careful sequencing, user communication, recovery planning, and selecting the right method for each user population. NIST SP 800-63B provides authoritative guidance on authenticator assurance levels (AAL1, AAL2, AAL3).
Deployment Prioritization
- Tier 1: Privileged accounts (domain admins, cloud admins, security team)
- Tier 2: Users with access to sensitive data (HR, finance, legal)
- Tier 3: All employees — universal MFA deployment
- Tier 4: Contractors, partners, and third-party accounts
- Customers/consumers: offer MFA, consider making mandatory for sensitive actions
Self-Service Enrollment
- Provide enrollment portal with guided setup wizard
- Require enrollment before next login deadline
- Support multiple methods for user preference
- Enroll backup method during primary enrollment
- Generate and securely store recovery codes
Recovery & Backup Methods
- Recovery codes: generate 8–12 single-use codes at enrollment
- Backup authenticator app or hardware key
- Manager verification + IT helpdesk re-enrollment process
- Never use SMS as recovery method for privileged accounts
- Store recovery codes in a personal password manager, not in email
NIST SP 800-63B Authenticator Assurance Levels
| AAL Level | Requirements | Permitted Authenticators | Use Cases |
|---|---|---|---|
| AAL1 | Single factor or weak MFA | Memorized secret (password), software OTP | Low-risk applications |
| AAL2 | Two factors, one cryptographic | TOTP + password, hardware OTP + password, FIDO2 with user verification | Most enterprise applications |
| AAL3 | Hardware cryptographic authenticator + verifier impersonation resistance | FIDO2 hardware key, PIV smart card | Privileged access, government, financial transactions |
Disable SMS OTP for Privileged Accounts
SMS OTP is phishable (real-time AiTM), SIM-swappable (social engineering a mobile carrier), and subject to SS7 protocol vulnerabilities (interception by nation-state actors). For privileged accounts — domain admins, cloud console admins, executive accounts, security team members — SMS MFA provides a false sense of security. Replace SMS with FIDO2 hardware keys or passkeys for all high-privilege users. CISA's advisory AA22-074A specifically calls out SIM-swapping as a critical threat vector for bypassing SMS MFA.