AADSTS50055 Entra ID sign-in error Triage: medium

AADSTS50055 (InvalidPasswordExpiredPassword): The Password Has Expired

Published · Updated

The account's password has expired, so Entra ID ended the sign-in and offered a password reset — routine for a user, a broken job for a service account, and a concern when the sign-in came from somewhere the user has never been.

Did the attacker have the password? Cannot tell from this code alone — correlate with the events around it.

Microsoft's definition

InvalidPasswordExpiredPassword

InvalidPasswordExpiredPassword - The password is expired. The user's password is expired, and therefore their login or session was ended. They will be offered the opportunity to reset it, or can ask an admin to reset it via Reset a user's password using Microsoft Entra ID.

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

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
Where AADSTS50055 stops an Entra ID sign-in
  1. 1

    Account

    Exists, is enabled, is not locked out or blocked

  2. 2 Stops here

    Password

    The password or other first factor is checked

  3. 3

    Conditional Access

    Policies, risk included, block or require more

  4. 4

    MFA

    The second factor is completed, or registered

  5. 5

    Signed in

    A token is issued; ResultType 0

Microsoft: “Conditional Access policies are enforced after first-factor authentication is completed.” Conditional Access overview ↗︎

What it means

AADSTS50055 is the error Entra ID returns when the account’s password has expired: “The user’s password is expired, and therefore their login or session was ended.” The flow that follows is part of the description — “They will be offered the opportunity to reset it, or can ask an admin to reset it.” For an interactive user that is a password-change screen; for a script, an older mail client or anything else that cannot show it, the sign-in simply keeps failing.

The code only appears where the password is subject to an expiration policy in Entra ID. For hybrid accounts whose on-premises Active Directory password expired, Microsoft documents a separate code, AADSTS50144 (InvalidPasswordExpiredOnPremPassword), and on the domain itself the equivalents are the Kerberos 0x17 KDC_ERR_KEY_EXPIRED failure and the Windows status code 0xC0000071 (STATUS_PASSWORD_EXPIRED). After the password is changed, earlier sessions can fail with AADSTS50133 (SsoArtifactRevoked), which Microsoft describes as a session that “isn’t valid due to password expiration or recent password change.”

Is it an attack?

ContextReading
Interactive sign-in from the user’s usual device, password change followsThe policy working as intended
Non-interactive sign-ins for one account, same app and IP every few minutesA job or script using the old password
Mobile mail app or Outlook failing repeatedly after the expiry dateA client that cannot show the change screen; update the password on the device
Hosting, VPN or Tor IP, or a country the user has never signed in fromSomeone is trying an old password — possibly from a past breach
Same IP producing 50055 for one account and 50126 for othersPart of a password spray; 50055 marks the accounts with expired passwords
Password change shortly after 50055, from an unfamiliar addressTreat as account takeover until the user confirms it

The interesting cases are the unusual sources. Old passwords circulate in breach dumps for years, and an expired one is often the version an attacker has. Because Microsoft describes the reset as offered to the user after this error, the response to a 50055 nobody can explain is to make sure that offer did not go to the wrong person.

How to investigate

Group the expired-password failures by account, source and client to separate users from automation:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50055"
| summarize Failures = count(), IPs = make_set(IPAddress, 10), Locations = make_set(Location, 5),
            Apps = make_set(AppDisplayName, 5), Clients = make_set(ClientAppUsed, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by UserPrincipalName
| extend PerHour = round(1.0 * Failures / max_of(1, datetime_diff("hour", LastSeen, FirstSeen)), 1)
| order by Failures desc

A steady per-hour rate from one app and IP is automation. Then check who changed the password afterwards and from where:

let expired = union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(14d) and ResultType == "50055"
    | summarize FirstExpired = min(TimeGenerated), SignInIPs = make_set(IPAddress, 10) by UserPrincipalName;
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has "password"
| extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName), ChangedFrom = tostring(InitiatedBy.user.ipAddress)
| join kind=inner expired on UserPrincipalName
| where TimeGenerated >= FirstExpired
| project TimeGenerated, UserPrincipalName, OperationName, Result, ChangedFrom, SignInIPs
| order by TimeGenerated desc

If a change came from an address that never appears in the user’s history, reset the password again through an administrator, revoke sessions, review the account’s authentication methods and look at its mailbox and application consents. For service accounts, fix the stored credential and consider replacing the password entirely with a managed identity or certificate. And if the expiring account is a person’s, a policy that forces a change on a schedule mostly produces these errors; Microsoft’s current password guidance favours long passwords plus MFA over periodic expiry.

Related codes

  • AADSTS50144 InvalidPasswordExpiredOnPremPassword
  • AADSTS50133 SsoArtifactRevoked
  • 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.
  • AADSTS50053 This error can result from two different reasons: IdsLocked Entra ID refused the sign-in before accepting it: either smart lockout has locked the account after repeated failures, or the source IP was blocked for malicious activity.
  • AADSTS50057 UserDisabled Entra ID refused the sign-in because the account is disabled; the code does not say whether the password was right, so repeated attempts on leaver accounts deserve a look at where they came from.

Detect it

MITRE ATT&CK: T1078.004T1098

Frequently Asked Questions

Does AADSTS50055 mean the password was correct?
Microsoft's description says only that the password is expired and that the user will be offered the opportunity to reset it; it does not state that the password was checked. Treat the code as evidence that the sign-in reached an account whose password has expired, and decide from the source, the client and what happened next whether the person behind it should be holding that account's password.
How is AADSTS50055 different from AADSTS50144?
Microsoft describes 50144 (InvalidPasswordExpiredOnPremPassword) as the user's Active Directory password having expired — the on-premises password of a hybrid account. 50055 is the expired-password error for the password Entra ID itself evaluates. In both cases the fix is a new password, but 50144 sends you to Active Directory and its password policy rather than to Entra ID.
A service account fails with AADSTS50055 every few minutes — what is it?
Almost always an application, script or scheduled job still using the old password, so it keeps failing until the credential is updated. Look in the non-interactive sign-in log for the same account, application and IP repeating at a fixed interval. Updating the stored password fixes it; moving the job to a managed identity or a certificate removes the problem for good.
Should a password change after AADSTS50055 worry me?
Only if the person who changed it is not the account owner. Microsoft states the user is offered the opportunity to reset the password after this error, so the next step for whoever made the sign-in is a password change. Compare the address and device of the change in the audit log with the user's usual ones before assuming it was them.

Find AADSTS50055 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.