AADSTS50074 - Strong Authentication Required
Azure AADSTS50074 is a high-assurance requirement signal. It indicates that the current authentication attempt or session context lacks the strong authentication claims required by the tenant’s security policy.
Last reviewed: April 9, 2026|Editorial standard: source-backed technical guidance
What Does Strong Authentication Required Mean?
AADSTS50074 is an assurance-gap error. In Entra ID, every session carries an effective authentication strength. If a user moves from a lower-risk app to a higher-risk app, or if a background process tries to refresh a token after a policy change, Entra checks whether the current session was established with strong enough proof. If not, it returns AADSTS50074. It is broader than a simple MFA prompt because it often signals that the type of authentication already used is no longer sufficient for the target resource.
Common Causes
- -Silent Auth In A Loud Environment: The app attempts
acquireTokenSilentwhen the underlying policy now requires an interactive MFA or stronger-auth challenge. - -Headless Script Collision: A CI/CD pipeline or automation script is using a user account in a tenant where MFA is now mandatory.
- -Policy Step-Up: The user is already signed in, but access to a more sensitive part of the app triggers a stronger Conditional Access requirement.
- -Stale Session Claims: The session was strong enough earlier, but a changed IP, risk signal, or policy refresh now requires fresh strong-auth verification.
- -Incomplete MFA Enrollment: Entra wants to challenge the user, but no valid methods such as Authenticator, SMS, or FIDO2 are available.
How to Fix Strong Authentication Required
- 1Switch To Interactive Mode: Catch the error and trigger
acquireTokenRedirectorloginPopup. Silent retries will not satisfy AADSTS50074. - 2Check Sign-In Logs: In Entra sign-in logs, review authentication requirement and Conditional Access details to see what raised the auth-strength requirement.
- 3Verify Enrollment: Make sure the user has actually completed MFA setup through the Security Info or setup MFA flow.
- 4Move To Workload Identities: If the failure is in automation, stop using a human account and switch to a service principal, managed identity, or workload identity federation.
Step-by-Step Diagnosis for Strong Authentication Required
- 1Open Microsoft Entra admin center and locate the failed sign-in with code AADSTS50074.
- 2Review the Conditional Access tab to see whether the grant controls require MFA, auth strength, or additional device-based conditions.
- 3Verify whether the client is sending
prompt=noneor otherwise attempting a silent path that hides the required challenge. - 4Check whether the app is moving between different resources or risk contexts that trigger stronger assurance requirements.
The MFA Error Trilogy
- -AADSTS50074: The current session is not strong enough and the flow usually needs interactive escalation.
- -AADSTS50076: MFA is required now and the challenge can usually be presented directly.
- -AADSTS50079: MFA is required, but the user has not finished setting it up yet.
Headless Automation Deadlock
- -If a bot or script hits AADSTS50074, retries are a dead end. The real fix is changing the authentication flow, usually from user credentials to client credentials or workload identity.
Implementation Examples
try {
const silentToken = await msalInstance.acquireTokenSilent(request);
} catch (error) {
// AADSTS50074 often arrives as an InteractionRequiredAuthError
if (error.errorCode === "AADSTS50074" || error.name === "InteractionRequiredAuthError") {
console.warn("Strong auth required. Transitioning to UI...");
msalInstance.acquireTokenRedirect(request);
}
}# Check if the user has any strong auth methods registered
mgc users authentication methods list --user-id <user-id>How to Verify the Fix
- -Confirm the user can log in successfully after being redirected to an interactive MFA-capable flow.
- -Check the Authentication Details in sign-in logs and verify the strong-auth or MFA requirement is now satisfied.
- -Ensure automated tasks no longer appear as user sign-ins once they are migrated to workload identities.
How to Prevent Recurrence
- -Use Modern Auth SDKs: MSAL handles interaction-required branches more cleanly than older libraries.
- -Adopt Workload Identity Federation: For GitHub Actions, Azure DevOps, and similar systems, remove password and MFA dependence entirely.
- -Review CA Rollouts: Before enforcing higher auth strength, confirm all supported client applications can surface or satisfy the required challenge.
- -Pro tip: Treat AADSTS50074 as an identity-upgrade request. It is usually not a password problem. It is a sign the session needs a stronger proof path.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.