AADSTS50133: Session invalid after password change or expiry

What does AADSTS50133 mean?

SsoArtifactRevoked: The session isn’t valid due to password expiration or recent password change.

A client presented a session that existed before the password changed or expired. Microsoft no longer accepts it. The user has to sign in again.

Two close relatives in the reference table:

• 50132 SsoArtifactInvalidOrExpired carries the same description text: “The session isn’t valid due to password expiration or recent password change.”
• 50089: “Authentication failed due to flow token expired. Expected - auth codes, refresh tokens, and sessions expire over time or are revoked by the user or an admin.”

Is it an attack?

Almost never on its own. 50133 is the normal consequence of a password change or expiry. It is the session counterpart of 50173, which is the same idea for refresh tokens. The session revocation guide shows how both codes prove a response worked.

Pattern	Likely meaning
A few 50133 rows for one user right after their password change, from their usual IPs and devices, then a success	The user’s own sessions being reset. Benign.
50133 after you reset a compromised user’s password, from an IP or device you can’t tie to the user	A session you didn’t know about was still being used. Treat it as an attacker indicator and pivot on the IP.
50133 for many users at once	A batch of password expiries or a bulk reset. Check your password policy and change history before investigating further.

This is reasoning from Microsoft’s description, not a documented detection: the code tells you a pre-change session was presented, and the row tells you from where. Whether that location is suspicious is your call.

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

After a password reset on a user you suspect was compromised, list every place an old session was presented. DeviceDetail and LocationDetails are dynamic in SigninLogs and strings in AADNonInteractiveUserSignInLogs, so each side is normalised before the union.

let targetUser = "[email protected]";
let resetAt = datetime(2026-10-11T09:00:00Z);
union
    (SigninLogs
     | extend Device = DeviceDetail, Location = LocationDetails, Table = "Interactive"),
    (AADNonInteractiveUserSignInLogs
     | extend Device = parse_json(DeviceDetail), Location = parse_json(LocationDetails), Table = "NonInteractive")
| where TimeGenerated > resetAt
| where UserPrincipalName =~ targetUser
| where ResultType in ("50133", "50132")
| summarize FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Apps = make_set(AppDisplayName, 10)
          by Table, ResultType, IPAddress,
             Country = tostring(Location.countryOrRegion),
             OS = tostring(Device.operatingSystem),
             Browser = tostring(Device.browser),
             DeviceId = tostring(Device.deviceId),
             UserAgent
| sort by FirstSeen asc

Tenant-wide baseline, so you know what normal looks like before an incident:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50133"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc

ResultType is a string column, so compare it with "50133", not 50133. The JSON field names inside Device and Location follow the Microsoft Graph signIn resource; check them against a row in your own workspace.

How do Conditional Access and MFA affect it?

• No Conditional Access policy causes 50133. The password change does.
• The fresh sign-in that follows goes through the password check, MFA and Conditional Access again. An old session no longer skips those checks.
• If the attacker may have registered their own MFA method on the account, a password reset alone is not the whole response. Review the user’s registered methods as part of the same incident.

How do I fix AADSTS50133?

For the user: sign in again with the new password.

For admins:

1. If this follows a suspected compromise, also revoke sessions explicitly (Revoke-MgUserSignInSession -UserId $User.Id or Revoke sessions). That is Microsoft’s documented response step. Refresh tokens that fail after a revocation or password change show up as 50173.
2. Run the first query for the time after the reset and block any IP that isn’t the user’s.
3. If you see 50133 for many users unexpectedly, check for a password expiry wave before treating it as an incident.