AADSTS50076, AADSTS50079 and AADSTS50158: fixing MFA and authentication-strength sign-in errors

Symptoms to confirm

A user is interrupted or blocked after entering a correct password, an app keeps asking to sign in again, or a background client silently stops syncing.

Likely causes

• A client that can't do MFA. Legacy protocols and old clients have no way to show an MFA prompt, so once a Conditional Access policy requires MFA they receive AADSTS50076 on every attempt. Modern apps holding an older token get it once, then send the user to complete MFA; that single event is expected.
• The user has nothing registered. A policy demands MFA but the user never registered a method, or a Register security information policy blocks registration from their current location. The result is AADSTS50079 or AADSTS50072, or AADSTS53004 when a risk policy is involved.
• An authentication strength the user can't meet. The strength requires methods the user hasn't registered or that aren't enabled for them in the Authentication methods policy. If one required method can be registered, the user is sent to combined registration; if none can, the sign-in is blocked. Certificate-based authentication, Windows Hello for Business and Authenticator phone sign-in can't be registered during that interrupt.
• Session controls. A sign-in frequency control, or the Every time frequency that risk-based policies use, expires a previously accepted MFA (AADSTS50078) and triggers a fresh prompt.
• External challenges. Terms of use, external authentication methods and custom controls hand the user to another page; the redirect itself is logged as AADSTS50158.

+1 more causes in the full article.

Checklist

1. 1

   Find the sign-in and read the Basic info

   In the Microsoft Entra admin center go to Entra ID › Monitoring & health › Sign-in logs (Reports Reader is enough). Filter by the user or the correlation ID from the error page, and check both the interactive and non-interactive tabs; background clients appear on the second one.

2. 2

   Read the Authentication details tab

   Each authentication step is listed with the method used, its result and a Requirement column naming the authentication strength (or plain multifactor authentication) that had to be satisfied. If the MFA step is missing entirely, the client never reached the prompt.

3. 3

   Read the Conditional Access tab

   Every evaluated policy appears with its result. Select the one that applied and look at Grant controls to see which strength was enforced, and at the session controls for a sign-in frequency setting.

4. 4

   Apply the fix for your scenario

   • Legacy or non-interactive client (50076 on every attempt): move the user to a modern-authentication client, replace Basic-auth protocols in apps and devices, and convert scripts to a managed identity or service principal. Then block legacy authentication with Conditional Access so the loop can't return.
   • Not registered (50079, 50072): have the user open Security info (aka.ms/mysecurityinfo) and register. For a new starter or someone with a lost phone, issue a Temporary Access Pass so they can register without an existing method. Check that your Register security information policy allows registration from where they are; if a risk policy caused 53004, remediate the risk first.
   • Authentication strength mismatch: open Entra ID › Authentication methods › Authentication strengths to see which combinations the strength accepts, confirm those methods are enabled for the user under Entra ID › Authentication methods › Policies, and check what they have registered. Pre-register passkeys, certificates or Windows Hello for Business before enforcing a phishing-resistant strength, or create a bootstrap strength that includes Temporary Access Pass and scope it to the Register security information user action.
   • External challenge (50158): follow the log to the next event. If the user never accepted the terms of use or the external provider failed, fix that side. If you combine an external authentication method with an authentication strength, switch the policy to the Require multifactor authentication grant; the two are currently incompatible.
   • Repeated prompts (50078): review sign-in frequency controls and remember that risk-based policies legitimately require reauthentication every time while the risk stands.

   +1 more in the full article.

5. 5

   Turn on a registration campaign

   To stop the unregistered-user case recurring, go to Entra ID › Authentication methods › Registration campaign.

Verify

• Ask the user to sign in again and open the new event. Authentication details should show the MFA step with Succeeded and the expected requirement, and the Conditional Access tab should show the policy as Success.
• For a replaced legacy client, the Client app value should now be a browser or a mobile or desktop app rather than a legacy protocol.
• For a newly registered user, the method appears on their Authentication methods page, and the Authentication methods activity report under Entra ID › Monitoring & health › Usage & insights reflects it.

Prevent it next time

• Register before you enforce: run a registration campaign and protect the registration page with a Conditional Access policy before turning on MFA or strength requirements.
• Roll out authentication strengths in report-only mode and test with the What If tool, especially for phishing-resistant strengths whose methods can't be registered on the fly.
• Keep a Temporary Access Pass process at the helpdesk for first registration and lost devices.
• Block legacy authentication everywhere so AADSTS50076 can only ever be the one-off interrupt it was designed to be.