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.

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.