AADSTS50126: Invalid Username or Password — Typo or Password Spray?

What it means

AADSTS50126 is a first-factor failure: the request reached Entra ID with a username and a password, and the password check failed. Nothing after that step ran — no MFA prompt and no Conditional Access decision — which is why these entries normally show conditionalAccessStatus: notApplied. The failureReason text in a Graph export reads “Invalid username or password or Invalid on-premises username or password.”

A single 50126 tells you about an attempt, not about access. The value comes from grouping: by source IP, by account and by client.

Is it an attack?

Pattern	What it usually is
One user, a few failures, then a success from the same IP	A typo
One user, failures on a fixed interval from their usual IP	A stale password saved in a mail app or device
One IP, failures across many accounts, one to three attempts each	Password spraying
Many accounts and IPs, mixed with AADSTS50034 for names that do not exist	Credential stuffing from a leaked list
One account, many attempts in minutes, ending in AADSTS50053	Brute force that hit smart lockout

Signals that move a cluster from “noise” to “attack”: legacy client apps (Exchange ActiveSync, IMAP4, POP3, Authenticated SMTP, Other clients), scripted user agents such as python-requests or BAV2ROPC, source IPs in hosting, VPN or Tor ranges, and attempts outside the users’ working hours. The LogTriage rule for legacy-auth sign-ins that bypass MFA covers the protocol side of the same campaigns.

How to investigate

Start with the sources, not the users. This finds IPs that failed for five or more accounts in the last day, across interactive and non-interactive sign-ins (scripted and legacy attempts often land in the non-interactive table):

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50126"
| summarize Failures = count(), Accounts = dcount(UserPrincipalName),
            SampleAccounts = make_set(UserPrincipalName, 10),
            ClientApps = make_set(ClientAppUsed, 5)
    by IPAddress
| where Accounts >= 5
| order by Accounts desc

The question that decides severity is whether any of those sources also succeeded. A spray that never succeeds is an attempt; one success turns it into an incident:

let sprayIPs = union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(1d) and ResultType == "50126"
    | summarize Accounts = dcount(UserPrincipalName) by IPAddress
    | where Accounts >= 5
    | project IPAddress;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where IPAddress in (sprayIPs) and ResultType == "0"
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed

Also look for AADSTS50074 or AADSTS50076 from the same IPs: those codes mean the password worked and only MFA stopped the attacker.

If there is no success, block the sources with a named location, confirm legacy authentication is blocked by Conditional Access, and keep watching the accounts that were targeted. If any account succeeded, treat it as compromised: reset the password, revoke its sessions, review its registered MFA methods and check for new inbox rules or app consents. Without Sentinel, the same grouping works on a portal CSV export — filter on Sign-in error code 50126 and pivot on IP address, or drop the export into the free browser analyzer.