AADSTS50076, 50079 and 50158: fix Microsoft Entra MFA sign-in errors

AADSTS50076 means Microsoft Entra ID needs multifactor authentication for this resource and the request didn't include it, so the client must start a new interactive sign-in. AADSTS50079 means MFA is required but the user has no usable method registered (or, for federated users, the identity provider didn't send an MFA claim). AADSTS50158 means the user was sent to an external challenge such as terms of use or a third-party MFA provider; it isn't a failure on its own.

Who this is for and what you will have at the end

This guide is for administrators and help desk staff who see these codes in error pages, scripts or the Microsoft Entra sign-in logs, typically after a Conditional Access rollout, a new device, or a change in authentication methods. It's also for engineers whose automation started failing with AADSTS50076.

At the end you will have:

• A precise meaning for each code and the related codes that usually appear alongside them.
• A repeatable way to find the sign-in event, the authentication step that failed, and the source of the MFA requirement.
• Fixes for each code, covering users without methods, non-interactive scripts and federated domains.
• A Log Analytics query for spotting patterns across many users.

What each code means

The definitions below come from the Microsoft Entra error code reference.

Related codes often appear in the same investigation:

The practical distinction: 50076 is "MFA wasn't performed", 50079 is "MFA can't be performed yet", and 50158 is "MFA or another challenge was handed to something outside Entra ID".

Prerequisites

• At least the Reports Reader role to read sign-in logs. To see which Conditional Access policies applied, you need a role that can read Conditional Access data, such as Global Reader, Security Reader, Security Administrator or Conditional Access Administrator.
• Authentication Administrator to issue a Temporary Access Pass to users, or Privileged Authentication Administrator for administrators.
• Authentication Administrator to require a user to re-register for MFA; Authentication Policy Administrator to change authentication method policies.
• Optional: sign-in logs sent to a Log Analytics workspace for the query in Step 3.

Step 1: Find the sign-in event

Ask the user for the time of the failure and, if possible, the correlation ID from the error page's More details link.

1. Sign in to the Microsoft Entra admin center as at least a Reports Reader.
2. Browse to Entra ID > Monitoring & health > Sign-in logs.
3. Filter by Username, Date and, if you have it, Correlation ID. Set Status to Failure if you want only failed events.
4. Check both User sign-ins (interactive) and User sign-ins (non-interactive). A 50076 from a background token refresh lands in the non-interactive tab.
5. Open the event and record the Correlation ID, Sign-in error code, Failure reason and Additional Details.

The Additional Details field often names the fix. For example, the failure reason "Authentication failed during the strong authentication request" comes with additional details stating that the user didn't complete the MFA prompt.

Step 2: Work out why MFA was required

Open these tabs in the sign-in event:

• Authentication Details lists the authentication policies applied, such as Conditional Access or security defaults, the sequence of methods attempted, and whether each step succeeded and why. It's the fastest way to see whether the user was prompted at all.
• Conditional Access lists every policy evaluated with its result. Select the ellipsis next to a policy to see which sign-in details matched its conditions.
• Basic info includes Troubleshoot Event, which opens the sign-in diagnostic.

If the requirement didn't come from Conditional Access, it came from per-user MFA, ID Protection or security defaults. The AuthenticationRequirementPolicies field in Log Analytics records which of those sources applied.

A sudden spike across many users almost always follows a change. Check Entra ID > Monitoring & health > Audit logs with the Service filter set to Conditional Access for Update Conditional Access policy, Add Conditional Access policy and Update security defaults around the time failures began.

Step 3: Query the pattern in Log Analytics

Interactive sign-ins are in the SigninLogs table, where ResultType holds the error code as a string. This query shows who is hitting each code, from which app and protocol, and what demanded MFA:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50076", "50079", "50158")
| summarize Events = count(), LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppDisplayName, ResultType, AuthenticationProtocol, ClientAppUsed, AuthenticationRequirementPolicies
| order by Events desc

Read the results this way:

• AuthenticationProtocol of ropc means something is sending a username and password directly. It can't show an MFA prompt, so it fails with 50076 every time MFA is required.
• A ClientAppUsed value for a legacy protocol points at an old client or script.
• The same user with 50079 across many apps means they have no registered method.

To follow a 50158 through to its outcome, query by correlation ID:

SigninLogs
| where CorrelationId == "<correlation-id>"
| project TimeGenerated, ResultType, ResultDescription, AuthenticationRequirement, ConditionalAccessStatus
| order by TimeGenerated asc

Fix AADSTS50076

Interactive users. Have the user sign in again through a browser or an app that supports modern authentication and can show the MFA prompt. If the user is stuck in a loop, check the Authentication Details tab: the issue may be a method that fails (an Authenticator notification that never arrives) rather than missing MFA.

Location-triggered prompts. The error text mentions moving to a new location. A user who signs in from a different network can fall into the scope of a policy that doesn't apply on the usual network, such as one that excludes a trusted named location. That's working as designed; the user completes MFA.

Scripts and legacy clients. Anything that passes a stored username and password can't satisfy MFA. Options, in order of preference:

1. For unattended automation, move to app-only authentication: a service principal with a certificate, or a managed identity for workloads running in Azure. Service principal and managed identity sign-ins appear in their own sign-in log tabs.
2. For administrator scripts run by a person, switch to the module's interactive or device-based sign-in so MFA can be prompted. Note that device code flow is a common target of Conditional Access block policies.
3. Replace legacy protocol clients with ones that support modern authentication.

Don't fix 50076 by excluding the account from MFA. An exclusion leaves a password-only account that is easy to abuse and rarely reviewed again.

Fix AADSTS50079

Managed users with no method. The user registers at Security info, https://aka.ms/mysecurityinfo (or https://mysignins.microsoft.com/security-info). Check which methods are enabled for them under Entra ID > Authentication methods > Policies; if the method they try to add isn't enabled, they can't register it.

Users who can't complete the first registration, for example because they lost their phone, need a Temporary Access Pass:

1. Enable Temporary Access Pass under Entra ID > Authentication methods > Policies and include the user. This needs Authentication Policy Administrator.
2. As at least an Authentication Administrator, go to Entra ID > Users, select the user, then Authentication methods > Add authentication method > Temporary Access Pass.
3. Give the pass to the user. It can't be viewed again after you close the dialog.
4. The user signs in at Security info with the pass and registers a method.

The default TAP lifetime is one hour, configurable from 10 minutes to 30 days, with a default length of eight characters. The same step can be done with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
 
$properties = @{ isUsableOnce = $true }
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "user@contoso.com" -BodyParameter $properties

Stale or broken methods. If the registered method no longer works, an Authentication Administrator can open the user under Entra ID > Users, select Authentication methods > Require re-register MFA, and confirm. This deletes the user's phone numbers, Microsoft Authenticator registrations and software OATH tokens, and the user is asked to set up a new method at the next sign-in.

Federated users. For a federated domain, the second half of the 50079 definition applies: the user needs an MFA claim from the federated identity provider. The domain's federatedIdpMfaBehavior setting controls this:

If neither federatedIdpMfaBehavior nor the older SupportsMfa is set, the default is acceptIfMfaDoneByFederatedIdp. Check the current value:

Connect-MgGraph -Scopes "Domain-InternalFederation.Read.All"
Get-MgDomainFederationConfiguration -DomainId "contoso.com" |
    Select-Object FederatedIdpMfaBehavior, PreferredAuthenticationProtocol

With enforceMfaByFederatedIdp, 50079 points at the IdP's MFA configuration, not at the user's Entra methods. A Temporary Access Pass is evaluated in Entra ID without redirecting to the federated IdP, which makes it useful for recovery.

Fix AADSTS50158

Start by checking the next events with the same correlation ID. If a later event succeeded, the user completed the external challenge and there is nothing to fix.

When it doesn't succeed, identify the external step:

• Terms of use. A Conditional Access policy requires acceptance of a terms of use document. The user must accept it.
• Conditional Access custom controls. The policy redirects to a third-party provider. Check the provider's own logs.
• External authentication methods (external MFA). The provider is registered under Entra ID > Authentication methods. If the provider's application has been deleted or no longer has permission, sign-in fails and the method can't be used. Granting admin consent for the provider app requires at least Privileged Role Administrator.

If a user is in scope of both a custom control policy and an external MFA policy, they're redirected to the provider twice. Microsoft recommends separate test groups for each during migration.

Verify the fix

1. Have the user sign in again and confirm a Success event in the sign-in logs.
2. In Authentication Details, confirm the MFA step shows the expected method and a success result.
3. In the Conditional Access tab, confirm the MFA policy shows Success.
4. For scripts moved to app-only, confirm sign-ins appear under Service principal sign-ins or Managed identity sign-ins, not as user sign-ins.
5. Re-run the Step 3 query a day later; the user, app or protocol should no longer appear.

Troubleshooting quick reference

When the error is AADSTS53003 rather than an MFA code, the policy is blocking rather than challenging; see AADSTS53003 blocked by Conditional Access.

Checklist

• Sign-in event found in the right tab, with correlation ID, error code and additional details recorded.
• Source of the MFA requirement identified: Conditional Access, per-user MFA, ID Protection or security defaults.
• 50076: interactive retry for users; app-only auth for automation; no MFA exclusions.
• 50079: method registered at Security info, Temporary Access Pass for bootstrap, re-registration if methods are stale, federation MFA behavior checked.
• 50158: follow-up events checked; external provider or terms of use investigated only if they failed.
• Fix verified in sign-in logs and the Log Analytics query.

References

• Microsoft Entra authentication and authorization error codes
• How to troubleshoot Microsoft Entra sign-in errors
• Sign-in log activity details
• Troubleshoot sign-in problems with Conditional Access
• SigninLogs table reference
• Configure a Temporary Access Pass
• Troubleshoot combined security information registration
• Manage authentication methods for Microsoft Entra multifactor authentication
• Migrate from federation to cloud authentication (federatedIdpMfaBehavior)
• internalDomainFederation resource type
• Manage an external authentication method
• Use audit logs to troubleshoot Conditional Access policy changes