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

The MFA family of AADSTS codes causes more helpdesk confusion than almost any other, because several of them are normal interrupts rather than failures. One tells a client to come back and do MFA, another says the user has nothing registered, and a third just means the user was sent to a terms-of-use page or a third-party provider. In this post I'll separate them, show where the answer sits in the sign-in log, and give a fix for each scenario.

Symptoms#

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. The sign-in logs show one of these codes. The descriptions below are Microsoft's documented meanings.

Why it happens#

• 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.
• Federation settings. When a federated domain enforces MFA at the identity provider, Entra ID expects the MFA claim from AD FS or the third-party IdP, and a missing claim surfaces as AADSTS50079.

How to fix it#

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. Note the Sign-in error code, the Failure reason and the Client app. A legacy protocol in Client app already explains a 50076 loop.

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. 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. Compare the required methods with the user's Authentication methods page under Entra ID › Users.

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.
• Federated users: run Get-MgDomainFederationConfiguration -DomainId contoso.com | Format-List and review FederatedIdpMfaBehavior. If it enforces MFA at the IdP, the IdP must issue the MFA claim.

5. Turn on a registration campaign#

To stop the unregistered-user case recurring, go to Entra ID › Authentication methods › Registration campaign. In the Microsoft managed state Microsoft picks the target method and snooze settings; in the Enabled state you choose Microsoft Authenticator or passkeys, a snooze period of 0 to 14 days, and whether users can skip only three times before registration becomes mandatory.

Verify the fix#

• 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.

References#

• Microsoft Entra authentication and authorization error codes
• How Conditional Access authentication strengths work
• Run a registration campaign to set up a passkey or Microsoft Authenticator