Why do scripts and old mail clients produce AADSTS50076?

They authenticate with a username and password in a single request and have no way to show an MFA prompt. When a policy requires MFA, Entra ID accepts the password and then fails the request with 50076. An attacker replaying a stolen password through the ROPC flow or a legacy protocol gets exactly the same result, which is why 50076 from python-requests, BAV2ROPC or IMAP-style client apps deserves attention.

Is AADSTS50076 harmless if MFA blocked the attacker?

It means the control worked this time. The password, however, is now confirmed to the attacker, who can try it against anything that does not require MFA: applications excluded from the policy, on-premises systems, or other services where the user reused it. Reset the password and look for successful sign-ins from the same IP.

Does AADSTS50076 appear for legitimate users?

Yes, often. A desktop app or browser session is asked for MFA after a policy change or when the user signs in from a new location, and the next request completes it. Pair each 50076 with what follows from the same IP and device; an MFA completion and a successful sign-in within minutes is routine.

How is AADSTS50076 different from AADSTS50079?

50076 means MFA is required and the user can satisfy it with methods already registered. Microsoft's description of 50079 says the user must first register security information. A 50079 for an account that should already be registered, or for a dormant account, can mean an attacker with the password is trying to enroll their own MFA method.

AADSTS50076: MFA Required After a Correct Password

AADSTS50076: MFA Required After a Correct Password — What It Reveals

Published October 6, 2026

Entra ID accepted the username and password, then required multifactor authentication that this request did not provide. From scripts or legacy mail clients it is strong evidence that whoever sent it knows the password.

Did the attacker have the password? Yes — the password was accepted; the sign-in failed at a later step. Treat the credential as known to whoever attempted it.

Microsoft's definition

UserStrongAuthClientAuthNRequired

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.

Source: Microsoft Entra authentication and authorization error codes · checked against the published table on every build

Where it appears

Microsoft Sentinel / Log Analytics: the ResultType column of SigninLogs and AADNonInteractiveUserSignInLogs
Microsoft Graph signIns API and JSON exports: status.errorCode, with the text in status.failureReason
Entra admin center sign-in log download (CSV): the Sign-in error code column

What it means

AADSTS50076 is returned when the username and password were accepted but a policy requires multifactor authentication and the request did not satisfy it — because of Conditional Access, per-user MFA enforcement, or because the sign-in comes from a location that triggers MFA. The client is expected to start a new, interactive request that can show the MFA prompt.

Clients that cannot do that — scripts, the resource-owner password credentials (ROPC) flow, legacy protocols such as IMAP, POP3 and SMTP AUTH — simply fail here. So do attackers replaying stolen passwords through those clients.

Is it an attack?

The client tells you most of what you need:

Client and source	Reading
Browser or Office desktop app, the user’s usual IP, success shortly after	Routine MFA prompt
Mobile mail app on a user’s phone after a policy change	Configuration catch-up; fix the client
`python-requests`, `BAV2ROPC`, IMAP4, POP3, Authenticated SMTP, Other clients	Password confirmed through a non-MFA path — likely an attacker
Same IP, 50076 for several accounts	Spray that found working passwords
Hosting, VPN or Tor IP with no later success	Attacker stopped by MFA, credential exposed

These are the same campaigns the legacy-auth MFA bypass rule is built for: when a protocol cannot do MFA, a correct password is all the attacker needs wherever MFA is not enforced.

How to investigate

Group 50076 by source and client to separate configuration noise from credential testing:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50076"
| summarize Attempts = count(), Accounts = dcount(UserPrincipalName),
            SampleAccounts = make_set(UserPrincipalName, 10)
    by IPAddress, ClientAppUsed, UserAgent
| order by Accounts desc

Rows with scripted user agents, legacy client apps or several accounts per IP come first. For each affected account: reset the password, revoke sessions, confirm no MFA method was added that the user does not recognise, and search for any successful sign-in from the same IP to an application that MFA does not cover. To stop the pattern rather than chase it, block legacy authentication with Conditional Access and review policy exclusions. The pages for AADSTS50074 and AADSTS53003 cover the related “first factor passed” codes.

Related codes

AADSTS50074 UserStrongAuthClientAuthNRequiredInterrupt The password was correct and Entra ID asked for multifactor authentication, which this request did not complete. Followed by a success it is routine; alone, from an unfamiliar place, it means someone else knows the password.
AADSTS50079 UserStrongAuthEnrollmentRequired
AADSTS50072 UserStrongAuthEnrollmentRequiredInterrupt
AADSTS53003 BlockedByConditionalAccess A Conditional Access policy blocked the sign-in. Conditional Access is enforced after first-factor authentication completes, so for an interactive sign-in an unexpected 53003 usually means the password was right.
AADSTS50126 InvalidUserNameOrPassword Entra ID rejected the password (or the username) for this sign-in. One failure is a typo; the same failure across many accounts from one IP is password spraying.

Frequently Asked Questions

Why do scripts and old mail clients produce AADSTS50076?: They authenticate with a username and password in a single request and have no way to show an MFA prompt. When a policy requires MFA, Entra ID accepts the password and then fails the request with 50076. An attacker replaying a stolen password through the ROPC flow or a legacy protocol gets exactly the same result, which is why 50076 from python-requests, BAV2ROPC or IMAP-style client apps deserves attention.
Is AADSTS50076 harmless if MFA blocked the attacker?: It means the control worked this time. The password, however, is now confirmed to the attacker, who can try it against anything that does not require MFA: applications excluded from the policy, on-premises systems, or other services where the user reused it. Reset the password and look for successful sign-ins from the same IP.
Does AADSTS50076 appear for legitimate users?: Yes, often. A desktop app or browser session is asked for MFA after a policy change or when the user signs in from a new location, and the next request completes it. Pair each 50076 with what follows from the same IP and device; an MFA completion and a successful sign-in within minutes is routine.
How is AADSTS50076 different from AADSTS50079?: 50076 means MFA is required and the user can satisfy it with methods already registered. Microsoft's description of 50079 says the user must first register security information. A 50079 for an account that should already be registered, or for a dormant account, can mean an attacker with the password is trying to enroll their own MFA method.

Find AADSTS50076 in your own logs

Drop an Entra ID sign-in export into the free browser analyzer to see which users and IPs hit this code (nothing is uploaded), or run it through LogTriage for threat-intel enrichment and an AI-written incident report.

Open the free analyzer → Analyze Your Own Logs