AADSTS50074: Strong authentication required, MFA not passed

What does AADSTS50074 mean?

UserStrongAuthClientAuthNRequiredInterrupt: Strong authentication is required and the user did not pass the MFA challenge.

Microsoft’s password spray playbook lists it as “50074 - MFA required”. Either way the order of events is the same: the password was accepted, then the MFA step did not complete.

Is it an attack?

A single 50074 is usually a user who dismissed a prompt, picked up the wrong phone, or let it time out. The signal is repetition, and where it comes from.

Pattern	Likely meaning
One 50074, then 0 from the same IP and device	The user retried and passed MFA. Benign.
Several 50074 for one user in minutes, from an IP or country the user doesn’t use	MFA fatigue (T1621). The attacker has the password and is generating prompts.
50074 burst followed by 0 from the same unfamiliar IP	The user approved a prompt they didn’t start. Treat as account takeover.
50074 from an IP that also produced many 50126 failures	The spray found a correct password and is now stuck at MFA.
50074 alongside 500121 for the same user	Same picture. See 500121.

The playbook’s instruction applies directly: “record successful passwords but failed MFA responses, as this activity indicates that the attacker is getting the password but not passing MFA.”

How do I find it in my logs (KQL)?

Users with repeated 50074 from one IP within an hour:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50074"
| summarize Prompts = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Apps = make_set(AppDisplayName, 5)
          by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where Prompts >= 3
| sort by Prompts desc

The threshold of 3 is a starting point, not a Microsoft number. Tune it against your own baseline.

What happened at the MFA step. AuthenticationDetails is a string column holding a JSON array, so parse it first:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50074"
| mv-expand Step = parse_json(AuthenticationDetails)
| extend Method = tostring(Step.authenticationMethod),
         StepResult = tostring(Step.authenticationStepResultDetail),
         Succeeded = tobool(Step.succeeded)
| summarize Steps = count() by UserPrincipalName, IPAddress, Method, StepResult, Succeeded
| sort by Steps desc

The field names inside AuthenticationDetails follow the Microsoft Graph authenticationDetail object. Check them against a row in your own workspace before relying on this query. Don’t use MfaDetail; Microsoft marks that column as deprecated.

How do Conditional Access and MFA affect it?

• 50074 is the MFA requirement doing its job. Whatever required MFA (a Conditional Access grant, per-user MFA, security defaults) stopped a sign-in that had a correct password.
• Microsoft documents that an interrupted sign-in “appears on the logs but shows Not applied for Conditional Access.” Don’t conclude from that column that no policy applied.
• Push approval without context is what fatigue attacks rely on. Microsoft enforced number matching for Microsoft Authenticator push in 2023, so the plain “tap Approve” path mostly remains in third-party or NPS-extension MFA. Phishing-resistant methods (FIDO2, passkeys, Windows Hello for Business) remove the push entirely. The MFA fatigue guide walks through the investigation.

How do I fix AADSTS50074?

For the user: if you didn’t start the sign-in, deny the prompt and report it. That prompt means someone has your password.

For admins:

1. If the 50074 burst came from an IP the user doesn’t use, reset the password. The attacker already has it.
2. Check for a later 0 from the same IP. If there is one, revoke sessions (Revoke-MgUserSignInSession) and review what the session accessed.
3. Move users off plain push approval toward phishing-resistant methods.