AADSTS50076: MFA required to access the resource

What does AADSTS50076 mean?

UserStrongAuthClientAuthNRequired: Due to a configuration change made by the admin such as a Conditional Access policy, per-user enforcement, or because you moved to a new location, the user must use multifactor authentication to access the resource. Retry with a new authorize request for the resource.

The first factor passed. Entra ID stopped the sign-in to ask for a second factor. In an interactive browser sign-in the user normally sees the MFA prompt and a follow-up request completes. That is why most 50076 rows are not failures in any practical sense.

Is it an attack?

Usually not. Every MFA prompt in your tenant can produce one. The value of 50076 is that it proves the password was correct.

Pattern	Likely meaning
50076, then 0 (success) from the same IP and device within minutes	The user completed MFA. Benign.
50076 from an IP that produced many 50126 failures	The spray found a working password. MFA is now the only barrier.
50076 followed by repeated 50074 or 500121 for the same user	Someone with the password is pushing MFA prompts the user is not approving. See 50074.
50076 in AADNonInteractiveUserSignInLogs from an IP the user never signed in from	A refresh token being used where a new MFA requirement applies. Could be a user on a new network, could be a replayed token. This reading is reasoning from the mechanism, not a Microsoft statement.

Microsoft’s password spray playbook tells responders to “record successful passwords but failed MFA responses, as this activity indicates that the attacker is getting the password but not passing MFA.” A 50076 from an attacker IP is that record.

On these rows AuthenticationRequirement is multiFactorAuthentication. Microsoft documents that a sign-in where primary authentication succeeds and MFA is required carries that value.

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

Users who hit the MFA step from an IP that was failing passwords for them earlier the same day:

let failedPw =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50126"
    | summarize Failures = count(), FirstFail = min(TimeGenerated)
              by UserPrincipalName, IPAddress;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50076"
| join kind=inner failedPw on UserPrincipalName, IPAddress
| where TimeGenerated > FirstFail
| project TimeGenerated, UserPrincipalName, IPAddress, Failures,
          AppDisplayName, ClientAppUsed, AuthenticationRequirement, UserAgent
| sort by TimeGenerated asc

Non-interactive 50076 from IPs the user has had no successful sign-in from, in either table, in the last 14 days. Mobile devices change IPs often, so expect benign rows and check the country and user agent before escalating:

let knownIPs =
    union
        (SigninLogs | project TimeGenerated, UserPrincipalName, IPAddress, ResultType),
        (AADNonInteractiveUserSignInLogs | project TimeGenerated, UserPrincipalName, IPAddress, ResultType)
    | where TimeGenerated > ago(14d)
    | where ResultType == "0"
    | distinct UserPrincipalName, IPAddress;
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50076"
| join kind=leftanti knownIPs on UserPrincipalName, IPAddress
| summarize Events = count(), Apps = make_set(AppDisplayName, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by UserPrincipalName, IPAddress
| sort by Events desc

ResultType is a string column, so compare it with "50076". Non-interactive rows are aggregated by Microsoft when application, user, IP, status and resource match, so Events counts log rows, not individual token requests.

How do Conditional Access and MFA affect it?

• 50076 is what a Conditional Access MFA grant, per-user MFA or a location change looks like at the moment it fires. The control is working.
• Microsoft’s interactive sign-ins documentation says an interrupted sign-in “appears on the logs but shows Not applied for Conditional Access.” Don’t read notApplied on a 50076 row as proof that no policy targets the user. Look at the follow-up sign-in.
• If MFA is satisfied by push approval, the password alone gets an attacker to the point where they can generate prompts. Number matching (enforced for Microsoft Authenticator since 2023) and phishing-resistant methods reduce what they can do from there. See the MFA fatigue guide.

How do I fix AADSTS50076?

For the user: complete the MFA prompt. If the app keeps failing silently, sign out and sign in again so it makes a new interactive request, which is what Microsoft’s text asks for (“Retry with a new authorize request”).

For admins:

1. If the 50076 came from an IP you associate with a spray, treat the password as compromised. Reset it and revoke sessions (Revoke-MgUserSignInSession, or Revoke sessions on the user in the admin center).
2. Check whether the same IP later produced a 0 for that user. If it did, this is a compromised account, not an attempt.
3. For developers: a daemon or background token refresh can’t satisfy MFA. Request the token interactively.