AADSTS50076 - MFA Required (Step-up Authentication)
Azure AADSTS50076 is a step-up authentication requirement indicating that while the password was accepted, Microsoft Entra ID requires Multi-Factor Authentication (MFA) due to a Conditional Access policy or a detected risk signal.
Last reviewed: April 9, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does MFA Required (Step-up Authentication) Mean?
AADSTS50076 is a conditional success. The user’s primary credentials such as a password are verified, but the request does not satisfy the current security requirements of the tenant. This is usually triggered by a Conditional Access policy that demands MFA for a specific app, location, or risk level. For interactive users, it is a manageable prompt. For headless scripts, it is a hard failure because a bot cannot answer a push notification or enter a TOTP code.
Common Causes
- -Conditional Access Policy Change: An admin enabled a new policy or turned on Security Defaults for the tenant.
- -Headless Automation: A CI/CD pipeline or script is using a user account through a flow such as ROPC that now requires MFA.
- -Risk-Based Elevation: The sign-in originates from an impossible-travel location or a suspicious IP, forcing Entra to demand higher assurance.
- -Managed Device Requirement: The policy changed to require a compliant or hybrid-joined device, which the current client does not provide.
- -Token Re-evaluation: A long-lived refresh token is reused, but the tenant now requires a fresh MFA claim before issuing a new access token.
How to Fix MFA Required (Step-up Authentication)
- 1For Interactive Apps: Catch the error and call
acquireTokenRedirectoracquireTokenPopupso the user can complete MFA. - 2For Automation and Scripts: Stop using user credentials. Migrate the workload to a service principal with a client secret or certificate.
- 3Check the Conditional Access Tab: In Entra sign-in logs, open the failed request and inspect the Conditional Access tab to see exactly which policy interrupted the flow.
- 4Review Named Locations: If the issue is triggered by a remote office or known network, confirm the relevant IP ranges are configured correctly as trusted locations where appropriate.
Step-by-Step Diagnosis for MFA Required (Step-up Authentication)
- 1Analyze the Entra sign-in logs for the specific Correlation ID and review the Authentication Requirement column.
- 2Verify whether the user has recently registered MFA methods. If no methods are enrolled, adjacent errors like AADSTS50079 may appear.
- 3Check whether the application is using a legacy flow such as ROPC. These flows are structurally incapable of satisfying AADSTS50076.
- 4Determine whether Security Defaults or a new Conditional Access policy was recently enabled in the tenant.
Human vs. Machine Authentication
- -Human (Interactive): Can satisfy MFA. For an interactive user, AADSTS50076 is a prompt rather than a terminal failure.
- -Machine (Non-interactive): Cannot satisfy MFA. For automation, AADSTS50076 is a fatal architectural mismatch.
Conditional Access Logic
- -Policies are evaluated after the password check. AADSTS50076 is the bridge between valid primary credentials and final token issuance.
Implementation Examples
const request = { scopes: ["User.Read"] };
try {
const silentToken = await msalInstance.acquireTokenSilent(request);
} catch (error) {
if (error.errorCode === "AADSTS50076") {
// Password was accepted, but MFA is now required
msalInstance.acquireTokenRedirect(request);
}
}# Instead of using a user account:
# az login -u user@company.com -p password
# Use a service principal:
az login --service-principal \
--username <app-id> \
--password <secret> \
--tenant <tenant-id>Seen in Production
Nightly deployment fails after MFA enforcement
Frequency: high
Example: A developer created a nightly backup or deployment script using their own user account. It worked until IT enabled MFA for all developers. The script then started failing with AADSTS50076 on every run.
Fix: Create an Azure app registration for the workload and switch the script to service principal authentication.
Debugging Tools
- -Entra ID Sign-in Logs: Filter by failure status and error code 50076.
- -Conditional Access What If tool: Predict which policy will trigger MFA for a given user, app, and network context.
- -MSAL Logger: Review the
suberrorfield, which often contains interaction or MFA-related detail.
How to Verify the Fix
- -Confirm that an interactive user can complete the MFA challenge and receive a token successfully.
- -Verify that the automation workload succeeds after moving to a workload identity such as a service principal instead of a user identity.
- -Ensure sign-in logs show MFA as satisfied for the successful retry.
How to Prevent Recurrence
- -Use Workload Identities: Always use managed identities or service principals for non-human access.
- -Pilot Conditional Access Changes: Use report-only mode before enforcing a policy that might break critical scripts.
- -Use Modern Auth: Retire legacy authentication protocols that do not support step-up requirements well.
- -Pro tip: If AADSTS50076 appears in a pipeline, do not try to bypass it for that user. Treat it as a signal to move the workload from a user model to a service model.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.