AADSTS50052: Password exceeds the maximum length (fix)

What does AADSTS50052 mean?

Microsoft’s error code reference doesn’t list AADSTS50052 (checked 30 October 2026).

The lab reproduced it. A password-grant token request with a 300-character password returned:

AADSTS50052: The password entered exceeds the maximum length. Please reach out to your admin to reset the password.

Microsoft documents the code on another page. Its “What’s new for authentication?” page has a March 2020 entry, “User passwords will be restricted to 256 characters”, effective 13 March 2020, for all endpoints and all user flows:

Users with passwords longer than 256 characters who sign in directly to Microsoft Entra ID (not a federated IDP, like AD FS) will be asked to change their passwords before they can sign in. Admins may receive requests to help reset the user’s password.

The error in the sign-in logs will be similar to AADSTS 50052: InvalidPasswordExceedsMaxLength.

That page gives the message as “The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.” The lab got the same text without “of 256”.

The limit itself is in Microsoft’s password policy: “A minimum of 8 characters and a maximum of 256 characters.”

Reproduced in the lab

On 30 October 2026 an automated lab run sent a password-grant (ROPC) token request for a test user in my lab tenant, with a 300-character password. Entra returned AADSTS50052 with the first line quoted above.

That confirms the code and the current wording at the token endpoint. Our reading: Entra checks the length before it checks the password. The current policy caps passwords at 256 characters, so a 300-character password can’t match one set under it. It could only be wrong, yet the answer was the length error and not AADSTS50126. We did not test whether a user that doesn’t exist gets 50052 too. It lands in SigninLogs: Status Failure, Conditional Access Not Applied. Entra’s explanation on the row reads: “The user is unable to login because their password exceeds the permitted maximum length. They should contact their admin to reset the password. If SSPR is enabled for their tenant, they can reset their password by following the “Forgot your password” link.“ The KQL below was run on these rows (how). The first two queries found the row. The third returned nothing as written, as expected for one attempt; with its threshold lowered to 1 it found it.

Is it an attack?

Usually not. A real person rarely types 257 characters.

Pattern	Likely meaning
One user, repeated, from their usual devices	A password set before the March 2020 limit, or a sign-in tool or password manager that sends too much. The user needs a reset.
One app or service account, every attempt	A script or config sending the wrong value as the password, such as a token, a certificate or a whole file.
Many users from one IP, mixed with 50126	A spray or stuffing tool sending broken or over-long entries from a bad list. Look at the 50126 rows; those are the real attempts.

The meanings in this table are our reading. Microsoft doesn’t describe these patterns. A 50052 is a failed sign-in. No token is issued.

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

Microsoft’s 2020 notice says the error shows in the sign-in logs, but doesn’t say which table. Check where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "50052"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Who hits it, from where, with which app:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "50052"
| summarize Attempts = count(),
            LastSeen = max(TimeGenerated),
            IPs = make_set(IPAddress, 10),
            Apps = make_set(AppDisplayName, 5),
            Clients = make_set(ClientAppUsed, 5)
          by UserPrincipalName
| sort by Attempts desc

IPs that produce 50052 for several users, with their other credential failures next to it. The threshold of 3 users is a starting point:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50052", "50126", "50034")
| summarize Users = dcount(UserPrincipalName),
            TooLong = countif(ResultType == "50052"),
            WrongPassword = countif(ResultType == "50126"),
            UnknownUser = countif(ResultType == "50034")
          by IPAddress
| where TooLong > 0 and Users >= 3
| sort by Users desc

How do I fix AADSTS50052?

For the user: your password is longer than the 256 characters Entra allows. Ask your admin to reset it, or use “Forgot your password” if your organisation allows self-service reset. Microsoft’s notice says: “If SSPR is enabled for their tenant, they can reset their password by following the “Forgot your password” link.“ Pick a new password of 256 characters or fewer.

For developers: check what your code sends in the password field. If it is longer than 256 characters, it is almost certainly not the password. Probably a secret, token or file read into the wrong variable, though we haven’t confirmed that.

For admins:

1. Find the user with the queries above.
2. Reset the password to one of 256 characters or fewer. Microsoft’s policy allows 8 to 256 characters.
3. If it is a service account used by a script, fix what the script sends, then look at why it uses a password grant at all.