What is the difference between AADSTS50079 and AADSTS50072?

Both mean the account must use multifactor authentication and has nothing to complete it with. Microsoft labels 50072 as the interactive enrollment interrupt, while its description of 50079 covers two cases — a managed user who must register security info, or a federated user who must bring the multifactor claim from their own identity provider. Investigate both the same way: who reached the prompt, from where, and who registered afterwards.

Is AADSTS50079 normal for new employees?

Yes. A new account, or one brought into a new Conditional Access policy or per-user MFA, hits 50079 until the user registers a method. It is routine when the sign-in comes from the user's expected device and location and a registration by that user follows. It is not routine for an account that registered long ago, a dormant account, or a source the user does not recognise.

Why is AADSTS50079 dangerous if MFA is required?

Because the requirement can only be satisfied by registering a method, and the person at the prompt chooses it. If an attacker reached 50079 with a stolen password, completing the registration gives them a second factor of their own, and every later MFA prompt is theirs to approve. Microsoft's guidance to protect security info registration exists for exactly this window.

What does 50079 mean for a federated user?

Microsoft's description says a federated user needs to get the multifactor claim from the federated identity provider. The sign-in reached Entra ID without proof that MFA happened at the identity provider, such as AD FS or a third-party IdP. Check that the federation trust passes the MFA claim and that the identity provider actually enforces MFA for the application.

AADSTS50079 Entra ID sign-in error Triage: high

AADSTS50079 (UserStrongAuthEnrollmentRequired): MFA Registration Required

Published October 24, 2026 · Updated October 27, 2026

The sign-in needs multifactor authentication the account cannot provide yet — a cloud user has no security info registered, or a federated user arrived without the MFA claim — so whoever completes the next registration owns the second factor.

Did the attacker have the password? Yes — the password was accepted; the sign-in failed at a later step. Treat the credential as known to whoever attempted it.

Microsoft's definition

UserStrongAuthEnrollmentRequired

UserStrongAuthEnrollmentRequired - Due to a configuration change made by the admin such as a Conditional Access policy, per-user enforcement, or because the user moved to a new location, the user is required to use multifactor authentication. Either a managed user needs to register security info to complete multifactor authentication, or a federated user needs to get the multifactor claim from the federated identity provider.

Source: Microsoft Entra authentication and authorization error codes · checked against the published table on every build · look up another code

Where it appears

Microsoft Sentinel / Log Analytics: the ResultType column of SigninLogs and AADNonInteractiveUserSignInLogs
Microsoft Graph signIns API and JSON exports: status.errorCode, with the text in status.failureReason
Entra admin center sign-in log download (CSV): the Sign-in error code column

Where AADSTS50079 stops an Entra ID sign-in

1

Account

Exists, is enabled, is not locked out or blocked
2

Password

The password or other first factor is checked
3

Conditional Access

Policies, risk included, block or require more
4 Stops here

MFA

The second factor is completed, or registered
5

Signed in

A token is issued; ResultType 0

Microsoft: “Conditional Access policies are enforced after first-factor authentication is completed.” Conditional Access overview ↗︎

What it means

AADSTS50079 is returned when a policy requires multifactor authentication for this sign-in and the account has no way to satisfy it. Microsoft names the triggers — a Conditional Access policy, per-user MFA enforcement, or the user signing in from a new location — and the two situations behind the error: a managed (cloud) user who “needs to register security info to complete multifactor authentication”, or a federated user who “needs to get the multifactor claim from the federated identity provider.”

Like the other strong-authentication codes such as AADSTS50076 and AADSTS50072, it is reached after the first factor: Entra ID only asks for MFA, or for MFA registration, once the credentials were accepted. That makes the code more than a configuration message. It is a sign-in that knew the password and stopped one step short.

Is it an attack?

Context	Reading
New or newly onboarded user, expected device and country, registration follows	Onboarding — the policy is doing its job
Account registered for years, now shows 50079	Security info was removed or reset; check the audit log before anything else
Dormant, shared or former-employee account	Someone has the password and is trying to finish enrollment
Hosting, VPN or Tor source, or a country the user has never signed in from	Likely an attacker with a stolen or sprayed password
Several accounts with 50079 from one IP	A spray that found working passwords for unregistered accounts
Federated users, 50079 after an identity-provider change	The MFA claim is not being passed through the federation trust

The window between a password compromise and MFA registration is one of the most abused gaps in Entra ID: an account that never registered security info effectively has no second factor until someone registers one. Treat any 50079 you cannot attribute to the real user as a compromised password.

How to investigate

List who is reaching the prompt, from where and through which applications:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50079"
| summarize Attempts = count(), IPs = make_set(IPAddress, 10), Apps = make_set(AppDisplayName, 5),
            Clients = make_set(ClientAppUsed, 5), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by UserPrincipalName
| order by Attempts desc

Then check whether a registration followed, and from which address — the step that decides the case:

let prompts = union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(14d) and ResultType == "50079"
    | summarize FirstPrompt = min(TimeGenerated), PromptIPs = make_set(IPAddress, 10) by UserPrincipalName;
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has "registered security info"
| extend UserPrincipalName = tostring(InitiatedBy.user.userPrincipalName), RegistrationIP = tostring(InitiatedBy.user.ipAddress)
| join kind=inner prompts on UserPrincipalName
| where TimeGenerated >= FirstPrompt
| project TimeGenerated, UserPrincipalName, OperationName, Result, RegistrationIP, PromptIPs
| order by TimeGenerated desc

A registration from an address the user does not recognise means the attacker now holds a working second factor: reset the password, revoke sessions, delete the authentication methods the user did not add, and review the account’s recent activity — mailbox rules, application consents, and new sign-ins approved with the new method. If no registration happened yet, still reset the password and look for the same source address under other accounts. To close the gap for good, require a trusted location or a Temporary Access Pass to register security info, so a password alone is never enough to enroll. Codes AADSTS50074 and AADSTS53003 cover the related “password was right, then a control stopped it” cases.

Related codes

AADSTS50072 UserStrongAuthEnrollmentRequiredInterrupt Entra ID accepted the credentials and then stopped the sign-in because the account has no second factor registered yet; from an address the user does not recognise it means an attacker has the password and is one enrollment away from owning the account.
AADSTS50076 UserStrongAuthClientAuthNRequired Entra ID accepted the username and password, then required multifactor authentication that this request did not provide. From scripts or legacy mail clients it is strong evidence that whoever sent it knows the password.
AADSTS50074 UserStrongAuthClientAuthNRequiredInterrupt The password was correct and Entra ID asked for multifactor authentication, which this request did not complete. Followed by a success it is routine; alone, from an unfamiliar place, it means someone else knows the password.
AADSTS50126 InvalidUserNameOrPassword Entra ID rejected the password (or the username) for this sign-in. One failure is a typo; the same failure across many accounts from one IP is password spraying.
AADSTS53003 BlockedByConditionalAccess A Conditional Access policy blocked the sign-in. Conditional Access is enforced after first-factor authentication completes, so for an interactive sign-in an unexpected 53003 usually means the password was right.

Detect it

Sigma rule LTR-0004: Detect Legacy-Protocol Sign-Ins With a Correct Password in Entra ID Logs →

MITRE ATT&CK: T1078.004 T1098.005

Frequently Asked Questions

What is the difference between AADSTS50079 and AADSTS50072?: Both mean the account must use multifactor authentication and has nothing to complete it with. Microsoft labels 50072 as the interactive enrollment interrupt, while its description of 50079 covers two cases — a managed user who must register security info, or a federated user who must bring the multifactor claim from their own identity provider. Investigate both the same way: who reached the prompt, from where, and who registered afterwards.
Is AADSTS50079 normal for new employees?: Yes. A new account, or one brought into a new Conditional Access policy or per-user MFA, hits 50079 until the user registers a method. It is routine when the sign-in comes from the user's expected device and location and a registration by that user follows. It is not routine for an account that registered long ago, a dormant account, or a source the user does not recognise.
Why is AADSTS50079 dangerous if MFA is required?: Because the requirement can only be satisfied by registering a method, and the person at the prompt chooses it. If an attacker reached 50079 with a stolen password, completing the registration gives them a second factor of their own, and every later MFA prompt is theirs to approve. Microsoft's guidance to protect security info registration exists for exactly this window.
What does 50079 mean for a federated user?: Microsoft's description says a federated user needs to get the multifactor claim from the federated identity provider. The sign-in reached Entra ID without proof that MFA happened at the identity provider, such as AD FS or a third-party IdP. Check that the federation trust passes the MFA claim and that the identity provider actually enforces MFA for the application.

Find AADSTS50079 in your own logs

Drop an Entra ID sign-in export into the free browser analyzer to see which users and IPs hit this code (nothing is uploaded), or run it through LogTriage for threat-intel enrichment and an AI-written incident report.

Open the free analyzer → Analyze your own logs