AADSTS50079 - MFA Registration Required
Azure AADSTS50079 is an enrollment error indicating that the user’s credentials were accepted, but the sign-in cannot complete because the account has not yet registered the required Multi-Factor Authentication (MFA) methods.
Last reviewed: April 4, 2026|Editorial standard: source-backed technical guidance
What Does MFA Registration Required Mean?
AADSTS50079 is a missing-proof signal. Unlike other MFA errors where a challenge is simply issued, AADSTS50079 occurs when the directory has no record of a usable authentication method such as Microsoft Authenticator or a phone number for the user. It is effectively a mandatory pause in the authentication flow that redirects the user to the Security Info registration portal. It is often triggered by Security Defaults or a new Conditional Access policy targeting users who have not completed their initial setup.
Common Causes
- -Security Defaults Enabled: The tenant-wide setting was turned on, requiring users to register for MFA within the allowed grace period.
- -First-Time Login: A new employee accesses a protected resource before completing MFA onboarding.
- -Lost or Reset Methods: The user deleted their Authenticator app or changed phone numbers, leaving the account without valid strong-authentication methods.
- -Registration Policy Trigger: A Conditional Access registration policy is forcing users to set up MFA from a specific trusted context.
- -Service Account Misuse: An automation script is using a human identity that is now subject to mandatory MFA enrollment.
How to Fix MFA Registration Required
- 1Direct the User to Security Info: Send the user to
https://aka.ms/setupmfaorhttps://mysignins.microsoft.com/security-infoto register a method. - 2Admin Reset: If the user is locked out because they lost a device, have an admin require re-registration of MFA to clear the stale state.
- 3Check Security Defaults: If this starts affecting a whole group unexpectedly, verify whether Security Defaults was enabled in the tenant.
- 4Use Temporary Access Pass: Issue a Temporary Access Pass so the user can complete MFA registration without relying on a lost device.
Step-by-Step Diagnosis for MFA Registration Required
- 1Search the Entra sign-in logs for the specific Correlation ID and confirm the result is AADSTS50079.
- 2Open Entra ID > Users > Authentication Methods for the user and verify whether the list is empty or missing a required strong method.
- 3Confirm whether the user is still inside any MFA registration grace period configured through Security Defaults or related policy.
- 4For hybrid users, verify that the relevant registration state is correctly visible in the cloud if SSPR writeback or related synchronization is part of the design.
AADSTS50079 vs AADSTS50076
- -AADSTS50079 (Registration): The user has no usable MFA method registered and must complete setup first.
- -AADSTS50076 (Challenge): The user already has a method, but this sign-in requires completing an MFA challenge now.
Automation Deadlock
- -If an automated process hits AADSTS50079, the bot cannot complete registration. This is a strong signal to migrate the workload to a service principal or managed identity.
Implementation Examples
try {
const silentToken = await msalInstance.acquireTokenSilent(request);
} catch (error) {
if (error.errorCode === "AADSTS50079") {
// The user has no MFA methods and must complete registration interactively
msalInstance.loginRedirect({
...request,
prompt: "select_account",
});
}
}# List a user's registered authentication methods
mgc users authentication methods list --user-id <user-id>How to Verify the Fix
- -Verify the user’s Authentication Methods view shows at least one valid MFA method such as Microsoft Authenticator.
- -Confirm the user can complete sign-in and receive tokens successfully after registration.
- -Check sign-in logs and verify the MFA requirement is marked as satisfied on the successful retry.
How to Prevent Recurrence
- -Strengthen Onboarding: Make MFA registration a day-one task before users access protected apps.
- -Register Backup Methods: Encourage users to configure both a primary and backup MFA method to reduce reset loops.
- -Use Managed Identities for Automation: Ensure CI/CD pipelines and background jobs do not rely on human identities that can hit MFA enrollment requirements.
- -Pro tip: Use Entra registration campaigns to move users toward stronger methods before you enforce hard-blocking policies.
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.