What is MFA?

Two proofs of the same kind are not MFA. A password plus a security question is still one factor, because both are things you know. NIST's current authentication guideline, SP 800-63B-4, does not count a biometric as an authenticator on its own either: the fingerprint unlocks a physical device, and the device is the "something you have".

MFA works against every attack that only needs the password. Microsoft researchers who studied Azure AD (now Entra ID) accounts showing suspicious activity found that MFA cut the risk of compromise by 99.22% across the population and by 98.56% for accounts whose credentials had leaked, and that the Authenticator app did better than SMS. That covers password spraying and credential stuffing. It does not cover an attacker who gets the user to complete the second factor for them, and that is where the methods start to differ.

MFA vs 2FA

Two-factor authentication (2FA) is MFA with exactly two factors. Nearly every deployment people call MFA is 2FA in practice: a password followed by a code, a push prompt or a security key. The count matters less than whether the two factors come from different categories, and less than how the second one can be beaten.

Types of MFA and which ones resist phishing

SP 800-63B-4 defines phishing resistance as the protocol's ability to keep secrets and valid authenticator outputs away from an impostor site "without relying on the vigilance of the claimant". Anything the user reads and types, or approves on a phone, can be passed on to a fake page, so NIST rules out one-time codes and out-of-band methods. Only cryptographic authenticators bound to the real site qualify.

The guideline grades sign-ins by authenticator assurance level (AAL):

• AAL2 needs two distinct factors, and the service must offer at least one phishing-resistant option. US federal agencies must require phishing-resistant authentication from their staff, contractors and partners.
• AAL3 needs a cryptographic authenticator with a private key that cannot be exported. Synced passkeys stop at AAL2, because NIST allows syncable authenticators only up to that level. A key generated inside a hardware security key qualifies.

SP 800-63B-4 was published in July 2025 and supersedes SP 800-63B. The revision also drops the approval-only push. Its reason is authentication fatigue: users approve one of many requests just to make them stop. For SMS, it tells services to check for a SIM change, number port or device swap before sending a code to the phone.

CISA strongly urges every organization to move to phishing-resistant MFA. For those still on push notifications, it recommends number matching as an interim mitigation for MFA fatigue and says plainly that it is not as strong. Microsoft has number matching on for all Microsoft Authenticator push notifications, so an Entra ID tenant no longer has a tap-to-approve prompt, except on wearables, which do not support number matching and send the user to the phone.

How attackers get past MFA

Most bypasses leave the cryptography alone and go after the person or the session. An adversary-in-the-middle phishing kit proxies the real login page, relays the password and the code, and keeps the session cookie issued after MFA. MFA fatigue sends prompt after prompt until the user gives in, or a caller posing as IT talks them into it; ATT&CK v20 tracks it as T1621, Multi-Factor Authentication Request Generation, under Credential Access, and the MFA fatigue investigation playbook works the case end to end. Device code phishing gets the victim to complete real MFA on Microsoft's own page for a session the attacker started. SIM swapping takes over the number SMS codes go to, and a convincing call to the help desk can get the factor reset outright, a route covered under social engineering. Phishing-resistant methods close the relay and prompt routes. Session theft and weak recovery processes stay open whichever factor you deploy.

What MFA looks like in Entra ID sign-in logs

In Microsoft Sentinel or a Log Analytics workspace, the SigninLogs table holds the MFA record across several columns:

Two values of authenticationMethod, Previously satisfied and Satisfied by token, mean the MFA requirement was met by a claim the session already carried, with no prompt at all. That is normal for a user who signed in an hour ago, and it is also what a replayed session cookie looks like.

A simulated case: six failed prompts, then an approval

Simulated example generated by SOCSimulator Research. The tenant, user, IP addresses, times and correlation IDs are invented; the column names, result codes and reason text are Microsoft's.

TimeGenerated  UserPrincipalName          ResultType  AuthenticationRequirement  IPAddress      CorrelationId  Status.additionalDetails
02:14:07       l.moreno@contoso.example   50074       multiFactorAuthentication  198.51.100.23  3f2a9c10
02:14:52       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  3f2a9c10       MFA denied; user declined the authentication
02:16:41       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  81c74e02       MFA denied; user did not respond to mobile app notification
02:18:12       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  c05e1b77       MFA denied; user declined the authentication
02:20:30       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  9d3b06aa       MFA denied; user did not respond to mobile app notification
02:22:58       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  47f0c3d1       MFA denied; user declined the authentication
02:25:16       l.moreno@contoso.example   500121      multiFactorAuthentication  198.51.100.23  b2e8915f       MFA denied; user did not respond to mobile app notification
02:31:05       l.moreno@contoso.example   0           multiFactorAuthentication  198.51.100.23  e94d2a68

Only the first attempt is shown with its 50074 row; each of the others starts the same way. Read the AuthenticationRequirement column before anything else. Every row says multiFactorAuthentication, so the password step passed on every attempt: whoever is at 198.51.100.23 has the password, whatever the user did with the prompts. Three failures carry the explicit decline. The other three carry MFA denied; user did not respond to mobile app notification: prompts that timed out, a case 500121 also covers. In this case each attempt has its own CorrelationId (repeated prompts can also share one), so a rule that counts failures per correlation ID sees one failure per sign-in and stays quiet. At 02:29, the user later says, someone from "IT support" phoned about the prompts and read out a number to type into the app. The 02:31 success comes from the same IP as the six failures. Treat it as a compromised account: revoke the sessions, reset the password, look for an MFA method registered in the following minutes, and search 198.51.100.23 across every other user.

This query finds the same pattern in a tenant: a successful MFA sign-in with five or more failed MFA prompts for the same user in the 30 minutes before it. It joins on the user, not on CorrelationId, for the reason above.

// Successful MFA sign-in preceded by 5+ failed MFA prompts (500121) in 30 minutes
let lookback = 1d;
let failed = SigninLogs
| where TimeGenerated > ago(lookback) and ResultType == "500121"
| project FailTime = TimeGenerated, UserPrincipalName, FailIP = IPAddress,
    CorrelationId, Detail = tostring(Status.additionalDetails);
SigninLogs
| where TimeGenerated > ago(lookback) and ResultType == "0"
| where AuthenticationRequirement == "multiFactorAuthentication"
| project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress,
    AutonomousSystemNumber, AppDisplayName
| join kind=inner failed on UserPrincipalName
| where FailTime between ((SuccessTime - 30m) .. SuccessTime)
| summarize Failures = count(), Attempts = dcount(CorrelationId), FirstFail = min(FailTime),
    FailIPs = make_set(FailIP, 10), Details = make_set(Detail, 5)
    by UserPrincipalName, SuccessTime, IPAddress, AutonomousSystemNumber, AppDisplayName
| where Failures >= 5
| extend SuccessFromFailIP = set_has_element(FailIPs, IPAddress)
| order by SuccessTime desc

SuccessFromFailIP true is the case above. False with failures from a hosting ASN and a success from the user's usual network is the other common shape: the user pressed approve on their own phone to end the noise. The second query counts which methods actually satisfied MFA in your tenant over the last 30 days, which no single alert tells you.

// Methods that completed a successful MFA sign-in, last 30 days
SigninLogs
| where TimeGenerated > ago(30d) and ResultType == "0"
| where AuthenticationRequirement == "multiFactorAuthentication"
| mv-expand Step = todynamic(AuthenticationDetails)
| where tobool(Step.succeeded)
| summarize SignIns = dcount(CorrelationId), Users = dcount(UserPrincipalName)
    by Method = tostring(Step.authenticationMethod)
| order by SignIns desc

Password rows are the first factor, and Previously satisfied or Satisfied by token rows are sessions reusing an earlier MFA. Map the rest onto the table above. Every sign-in completed by SMS, a push or a code is one an AiTM kit could have relayed. Both queries are written against Microsoft's documented SigninLogs schema and have not been run against a live workspace by SOCSimulator; check the exact method names your tenant returns before you build a report on them.