50126 Error Code | Fix Microsoft Sign-In Failures

What The 50126 Error Code Means

The 50126 error code appears when a Microsoft Entra ID or Azure Active Directory sign-in fails because the credentials do not pass validation. The message often shows as AADSTS50126 with text about an invalid username or password, which tells you the sign-in request never reaches the target app.

During sign-in, the user submits credentials, Microsoft checks the account, and the service issues a token only when every step succeeds. When the flow stops on a 50126 error code, Entra ID blocks the request because something about the user name, password, or account configuration does not match what the directory expects.

You usually see this error in Microsoft 365, Teams, Outlook on the web, SharePoint, and any custom app that trusts Entra ID tokens. In most cases the cause is simple, such as a typo or an expired password. In tougher cases it points to account status, federation settings, or conditional access rules that change how credentials are validated.

The error page often includes extra fields such as request ID, correlation ID, and a timestamp. Those details help admins trace the exact sign-in event inside Entra ID logs and match 50126 entries with a specific user action, device, or application.

Common Causes Of 50126 During Sign In

When users run into 50126 during sign in, the same groups of triggers repeat again and again. Some sit fully on the user side, while others come from tenant configuration, federation, or security policy inside Microsoft Entra ID.

• Wrong username — The user types the wrong address, misses a character, or uses a personal Microsoft account address instead of the work or school login.
• Wrong password — The password changed on another device, expired earlier, or includes characters entered under the wrong keyboard layout or input language.
• Account locked or disabled — Repeated failures or admin action place the account in a locked or disabled state, so Entra ID refuses the sign-in even when the current password is correct.
• Password expired — The organization enforces expiry, and the user tries to sign in with an old password that no longer passes directory checks.
• Multi-factor sign-in flow mismatch — A script or background task uses credentials from a user account that now has strong sign-in turned on, so the flow expects interaction that never happens.
• Federation or domain mismatch — The domain still uses on-premises identity, but the sign-in method cannot redirect there, so Entra ID sends back 50126 even though the password might succeed in another flow.
• Conditional access blocking — Policy rules that use device platform, location, risk, or app context can stop the request and surface a 50126 result to the user.

Security tools, migration platforms, and third party portals that rely on Entra ID also surface this label. Even when the screen looks slightly different, the meaning stays the same: the system could not accept the supplied credentials for that specific sign-in attempt.

User Side Versus Tenant Side Causes

User side causes revolve around typos, expired passwords, and incomplete strong sign-in setup. Tenant side causes stem from federation, domain configuration, and policy rules that change how Entra ID handles credentials. Sorting events into these two groups helps decide whether the user can fix the problem alone or needs admin help for the 50126 error code.

50126 Error Code Fixes For Microsoft Sign Ins

For regular users, the fastest way to clear a 50126 error code is to work through a short list of checks before raising a ticket. These steps remove the most common causes with low effort and give your admin solid detail if the issue remains.

• Confirm the sign-in page — Use the correct portal link for your tenant, such as the work or school Microsoft 365 page, not a consumer Microsoft account page.
• Re-enter the username carefully — Type the full address again, including the correct domain, and watch for spaces before or after the text.
• Re-enter the password slowly — Turn off caps lock, check keyboard layout, and type each character with care so you know the password you send is the one you intend.
• Try another device or browser — Sign in from a different browser profile, private window, or another device to rule out cached cookies or extensions that interfere with the flow.
• Reset the password — If your organization offers a self-service reset page, use it to set a fresh password, then sign out everywhere and sign in again.
• Complete strong sign-in setup — If the account expects an app or phone prompt that never appears, finish the strong sign-in registration steps on a trusted device and test once more.

Each time you try, note the exact time and any small change in the error text. If 50126 shows every single time, even after a known fresh password, that detail tells your admin that the cause sits beyond a simple user mistake.

Extra Checks When Only One App Fails

Sometimes 50126 appears for a single app while other Microsoft services work fine. In that case, a few extra checks can narrow the field before an admin steps in.

• Test the same app on the web — If the desktop client fails, try the browser version with the same account to see whether the problem sits in the local client.
• Remove and re-add the account — In the client settings, remove the work account, close the app, then add the account back and try another sign-in.
• Check for app updates — Install the latest update for that app so the sign-in stack matches current Entra ID requirements.

If none of these steps clear the 50126 error, send your admin the timestamp, the app name, and a screenshot of the error details panel. That context gives the help desk a head start when they review logs inside the tenant.

Admin Checks To Resolve Persistent 50126 Errors

Administrators have deeper tools to track down 50126 across Microsoft Entra ID. A structured approach that starts in the sign-in logs, then moves through account checks and configuration review, keeps the work steady and repeatable.

Use Sign-In Logs First

The sign-in logs in the Entra admin center show every attempt with result codes and extended details. Filtering those logs for the user and for the 50126 result pins down the scope of the issue and reveals patterns across apps, devices, and locations.

• Filter by user and error — In the Microsoft Entra admin center, open the sign-in logs, filter by the user account, then add a filter on the 50126 result to see only failing attempts.
• Check client app and status — Look at the client app column to see whether failures come from interactive sign-in, legacy protocols, or a resource owner password flow.
• Review conditional access result — Inspect the details panel for each event to see whether a conditional access policy changed the outcome or blocked access outright.

This first pass shows whether 50126 appears for one user, a group of users, a single app, or a whole domain. That insight guides the next set of checks.

Fix Account And Policy Issues

Once logs confirm the pattern, the next step is to inspect account status, strong sign-in settings, and policy rules that affect the scenario. Many stubborn cases fade once these core pieces line up with the way users actually sign in.

• Check account status — Confirm the account is enabled, licensed, and not blocked from sign-in. Remove any sign-in block flag that no longer applies.
• Reset or set the password — Set a known strong password for the user or service principal, then try a fresh interactive sign-in while you watch the logs for a new result code.
• Review strong sign-in settings — Check whether multi-factor sign-in is required and whether the scenario expects interactive prompts. Service accounts that run unattended jobs should not rely on user-style prompts.
• Review conditional access policies — Look for rules that deny or require extra steps for the specific user, app, device platform, or location tied to the failed attempt.

For domains that still use federation with on-premises identity, policy can also decide where password checks occur. If redirection cannot happen for that sign-in flow, Entra ID reports 50126 even when the user swears the password is correct.

Handle Federation And Cloud Password Validation

Federated domains often show 50126 when a resource owner password flow runs against an account that should redirect to on-premises identity. In those cases, the sign-in method cannot complete the redirect step, so the cloud directory throws a credential error.

• Confirm domain authentication type — Check whether the domain for the user is managed in the cloud or still federated with on-premises identity.
• Review AllowCloudPasswordValidation — For supported scenarios, apply the AllowCloudPasswordValidation policy so Entra ID can validate passwords in the cloud for accounts that also use federation.
• Prefer modern auth flows — Where possible, move scripts to device code flow or other modern auth methods instead of user-style password flows that trigger 50126 on federated domains.
• Test with a cloud-only account — Try the same app and flow with a simple cloud-only test user to see whether the issue ties to one account, one domain, or the entire tenant.

These checks place each 50126 error code into a clear bucket: user mistake, account configuration, policy, or federation. That breakdown makes repeat issues easier to handle across larger organizations.

To bring those checks together, map typical scenarios against quick actions. The table below pairs sample 50126 patterns with a first step so triage stays consistent for every analyst on the team.

Reducing 50126 Error Code Across Your Organization

Because most 50126 events tie back to credentials, clear user guidance and solid tenant hygiene can cut the volume of errors over time. Fewer failed attempts improve user experience and also reduce noise in security alerts and reports.

• Roll out self-service reset — Enable a secure reset portal so users can change passwords on their own without waiting for the help desk.
• Explain password rules — Share length, character, and expiry rules in plain language on onboarding pages and during account setup, not only in policy documents.
• Encourage password managers — Recommend approved tools so users avoid retyping long strings and cut down on small mistakes.
• Watch sign-in trends — Use sign-in reports to track spikes in 50126 events by location, app, or time of day, then adjust training or policy in those areas.
• Audit stale accounts — Regularly review accounts that show long periods without successful sign-ins but still appear in failed 50126 logs.
• Tune conditional access — Adjust rules that push many failed attempts from known safe locations or managed devices while keeping risk-based rules in place.

Small changes in these areas keep sign-in flows simple for most users, while still leaving room for advanced controls where risk is higher. The 50126 error code turns into a clear signal of real issues instead of a constant background event.

Service And Script Accounts

Service accounts and scripts deserve extra attention, because they often trigger long runs of 50126 events when something changes. These accounts do not sit in front of a user who can respond to prompts, so strong sign-in methods and password rules need a slightly different design.

• Use app registrations where possible — Replace user accounts in scripts with app registrations that use certificates or secrets, so background jobs do not depend on user passwords.
• Track password changes on service accounts — When a script must still use a password, keep a simple record of the last change and confirm that automation jobs use the current value.
• Review sign-in logs for service principals — Watch for patterns of 50126 on service principals and adjust permissions, secret expiry, or auth flow before users feel the impact.

Clear standards for these accounts reduce surprise bursts of 50126 during migrations, batch jobs, and other automated tasks that rely on Microsoft Entra ID.

When 50126 Is Not A Microsoft Entra Sign-In Issue

Most online searches for 50126 point to Entra ID and Azure sign-in. Even so, some software vendors reuse the same number for general Windows or application failures. In those cases the error appears in local tools or repair utilities, not during sign-in to cloud services.

Generic web pages that mention 50126 without clear context often belong to registry cleaners or driver utilities. They may report a broad system problem and urge you to run a scan or buy a program that claims to fix every issue in one click.

For safety, favor direct steps instead of quick-fix utilities. Use built-in Windows tools, official vendor instructions, or a trusted admin before letting a third party program change system files based only on an error number.

So when you see 50126, pause and read the entire message. If the screen mentions Entra ID, Azure Active Directory, or AADSTS50126, treat it as a sign-in issue and follow the steps in this article. If the message talks about local system components or registry data, treat the number as a local Windows error and follow guidance for that component instead.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback