What Is Multi-Factor Authentication (MFA)?

How MFA Works: The Three Factors

Authentication systems verify identity by requiring proof in one or more of three categories: something you know (a password, PIN, or security question answer), something you have (a phone, hardware token, or smart card), and something you are (a fingerprint, face scan, or retina pattern). Single-factor authentication — the standard password login — relies entirely on something you know. Multi-factor authentication requires at least two factors from at least two different categories.

The security logic is straightforward: an attacker who steals your password has acquired one factor. If accessing your account also requires a code sent to your phone, the attacker needs both your password and physical access to your phone. The combination of two independent factors is dramatically harder to compromise than either factor alone.

MFA Methods: Not All Are Equal

SMS-based MFA sends a one-time code to a registered phone number via text message. It is the most widely deployed MFA method and the weakest. SIM swapping — convincing a mobile carrier to transfer a victim's phone number to an attacker-controlled SIM — allows attackers to receive SMS codes without physical access to the victim's device. SIM swapping attacks have been used against executives, cryptocurrency holders, and corporate accounts with increasing frequency.

Authenticator app MFA generates time-based one-time passwords (TOTP) using an app like Microsoft Authenticator or Google Authenticator. The codes rotate every 30 seconds and are generated locally on the device without network transmission, eliminating the SIM swapping risk. This is a meaningful improvement over SMS MFA and represents the minimum acceptable standard for most business applications.

Push notification MFA sends an approval request to a registered device, which the user approves with a tap. This is the most convenient method for users and the method most vulnerable to MFA fatigue attacks — a technique where attackers send repeated push notifications hoping the user will eventually approve one to stop the interruption. The 0ktapus campaign and the Uber breach both used MFA fatigue as the initial access vector.

Phishing-resistant MFA — FIDO2 hardware security keys or passkeys — is the only MFA method that defeats adversary-in-the-middle phishing. The cryptographic protocol binds authentication to the specific domain being accessed, making it technically impossible to relay credentials to a spoofed site. This is the standard that CISA and the NSA recommend for high-value accounts.

What Adversary-in-the-Middle Phishing Actually Does to MFA

The most important concept for executives evaluating MFA is adversary-in-the-middle (AiTM) phishing — the technique that defeated MFA at MGM, Caesars, and dozens of other organizations. Understanding it requires understanding what MFA actually protects against.

Traditional MFA protects against credential stuffing and password-based attacks: an attacker who has your password cannot log in because they do not have your second factor. AiTM phishing does not steal your credentials and attempt to use them later. It proxies your authentication session in real time.

In an AiTM attack, the victim receives a phishing email and clicks a link to what appears to be a legitimate Microsoft 365 or Okta login page. The page is real — it is proxied through an attacker-controlled server using tools like Evilginx2 or Modlishka. When the victim enters their username and password, those credentials are relayed to the real authentication server in real time. When the real server sends an MFA challenge, the proxy relays it to the victim. When the victim approves the push notification or enters the TOTP code, the proxy relays that to the real server. Authentication succeeds. The attacker's proxy captures the authenticated session cookie and uses it to access the account directly — no credentials or MFA codes needed going forward.

From the victim's perspective, they logged into what appeared to be a normal page and everything seemed to work. From the MFA system's perspective, authentication was completed successfully with valid credentials and a valid second factor. The attack defeats all MFA methods except phishing-resistant hardware keys, because only hardware keys bind the cryptographic authentication to the legitimate domain and cannot be proxied.

MFA Implementation for PE Portfolio Companies

Conditional Access: The Force Multiplier

MFA alone is a binary control — you authenticated or you did not. Conditional access policies add context to authentication decisions, requiring MFA only under certain conditions and blocking access entirely under others. A conditional access policy might require MFA for all access from unmanaged devices, block access from known malicious IP ranges regardless of MFA status, require a compliant managed device for access to sensitive data, and apply step-up authentication for privileged administrative actions. Conditional access transforms MFA from a single gate into a layered access control system. It is available natively in Microsoft Entra ID (formerly Azure AD) and is the standard that enterprise-grade Microsoft 365 deployments should be operating against.

MFA Coverage Gaps

In Cloudskope's M&A due diligence work, MFA coverage gaps are among the most common findings. Organizations that believe they have enforced MFA across their environment frequently have unprotected legacy authentication protocols — SMTP, IMAP, POP3, and older Exchange protocols that do not support modern authentication and therefore cannot enforce MFA. Attackers specifically target these legacy authentication endpoints because they bypass MFA entirely. A single service account using basic authentication against Exchange Online can provide persistent access to email regardless of the MFA policies applied to the main user accounts.

The Recommendation Framework

For PE operating partners evaluating portco MFA posture: confirm that MFA is enforced through conditional access policies, not just enabled as an option. Verify that legacy authentication protocols are blocked, not just monitored. Assess whether high-privilege accounts — global administrators, domain admins, finance system administrators — use phishing-resistant hardware keys rather than push notification MFA. And validate that MFA coverage includes all identity providers in use, including any federated identity systems that might have independent authentication paths.

Related Reading

• Identity and Access Management (IAM)
• Zero Trust Security
• Password Spraying

Frequently Asked Questions

Why does MFA fail against adversary-in-the-middle phishing?

Traditional MFA verifies that the user has both a password and a second factor at the time of authentication. AiTM phishing relays both in real time through an attacker-controlled proxy. The legitimate authentication server sees a valid login. The user sees what looks like a normal login page. The attacker captures the authenticated session cookie and uses it to access the account directly. Only phishing-resistant MFA — FIDO2 hardware keys or platform passkeys — defeats AiTM, because the cryptographic protocol binds authentication to the legitimate domain and cannot be proxied.

What is phishing-resistant MFA?

Phishing-resistant MFA uses public key cryptography to bind authentication to a specific domain. The FIDO2 standard, implemented as hardware security keys (YubiKey, Google Titan) or platform passkeys (Apple Touch ID, Windows Hello), is the dominant phishing-resistant standard. CISA and the NSA both recommend phishing-resistant MFA for high-value accounts and any account with administrative privileges. It is the only MFA method that cannot be defeated by an AiTM proxy.

Are passkeys the same as hardware keys?

Both use the FIDO2 protocol and are phishing-resistant. Hardware keys are physical devices — a separate object the user carries. Passkeys are software credentials stored on a device (phone, laptop) and synced across the user's devices through a platform provider like Apple iCloud Keychain, Google Password Manager, or 1Password. Passkeys are more convenient for end users and provide the same cryptographic phishing resistance as hardware keys. For most consumer and business use cases, passkeys are now the preferred option. Hardware keys remain the standard for the highest-privilege administrative accounts.

What is MFA fatigue and how do we prevent it?

MFA fatigue (or MFA bombing) is a social engineering technique where an attacker who has the user's password sends repeated push notifications hoping the user will eventually approve one to stop the interruption. The Uber breach was an MFA fatigue attack. Prevention requires switching from push approvals to number matching (the user must enter a number displayed on the login screen, not just approve a notification), enforcing rate limits on MFA attempts, and educating users that legitimate IT support will never ask them to approve unexpected MFA prompts.

Should we require MFA for all accounts or just admins?

All accounts. The 99.9% reduction in automated credential attack success that Microsoft cites applies to all user accounts, not just privileged accounts. Compromised standard user accounts are the most common initial access vector for ransomware and business email compromise. Privileged accounts should additionally use phishing-resistant MFA, but the baseline MFA requirement should apply universally. The remaining 0.1% of attacks that bypass MFA are not the right reason to leave any account on password-only authentication.

Does MFA replace the need for strong passwords?

No. MFA assumes the password is one of two factors and that an attacker who has the password still needs the second factor. Weak passwords increase the rate at which attackers acquire the first factor through credential stuffing, password spraying, or database breaches. The strongest authentication posture combines a unique, complex password (typically managed through an enterprise password manager) with phishing-resistant MFA.

Real-World Example: The Uber Breach — MFA Fatigue Against a Security-Conscious Company

In September 2022, Uber suffered a breach that gave the attacker near-complete access to internal systems — Slack, AWS, Google Workspace, HackerOne bug reports, and internal dashboards. The attacker was an 18-year-old using a technique that required no technical sophistication: MFA fatigue. The attacker purchased Uber credentials from a criminal marketplace and began attempting to log in, triggering push MFA notifications to the legitimate employee's phone. After the employee declined repeated notifications, the attacker sent a WhatsApp message claiming to be from Uber IT support and explaining that the MFA notifications would stop once the employee approved one. The employee approved. The attacker was in. Uber had MFA deployed. The MFA worked as designed. The attack succeeded anyway through social engineering that exploited user behavior rather than technical controls.

Related Breach Analysis

Both incidents below are rooted in identity failures that modern MFA architecture would have constrained — credential brute-forcing in T-Mobile's case, and undetected credential abuse in Yahoo's.

• T-Mobile Data Breach: 9 Breaches, $531M in Penalties — the August 2021 breach was enabled by SSH brute-force against an unprotected GPRS gateway with no rate limiting. The FCC's 2024 settlement specifically mandated phishing-resistant MFA across T-Mobile's internal network.
• Yahoo Data Breach: 3 Billion Accounts, $500M+ Total Impact — Russian FSB officers used spear-phishing and forged authentication cookies; weak MD5 password hashing and unhashed security questions compounded the exposure to all 3 billion Yahoo accounts.