AADSTS50079: User must register for MFA

What does AADSTS50079 mean?

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.

Microsoft’s password spray playbook lists it as “50079 - user needs to register security info”. The password was accepted. The account has no MFA method, so the next screen is registration.

Is it an attack?

For a new hire, a freshly enabled policy, or a user who never registered, 50079 is the normal path into MFA. It becomes the most important row in an investigation when the sign-in is not the user’s.

Whoever completes registration from that session chooses the MFA method. If an attacker with a sprayed or phished password lands on an unregistered account, 50079 is the moment they can add their own authenticator app or phone, and from then on MFA protects the attacker, not the user. This is reasoning from how registration works, not a Microsoft statement, but it is why the playbook lists the code.

Pattern	Likely meaning
50079 for a new or newly in-scope user, from a known office or home IP	Expected registration. Benign.
50079 from an IP that also produced 50126 failures against other users	A spray found a working password on an account with no MFA.
50079 from an unfamiliar IP or country, then a security info registration event, then 0	Likely account takeover with attacker-registered MFA (T1098.005).
50079 for a long-standing account that should already be registered	Check whether its methods were deleted, and by whom.

How do I find it in my logs (KQL)?

50079 from IPs that were failing passwords against other users the same day:

let sprayIPs =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50126"
    | summarize FailedUsers = dcount(UserPrincipalName) by IPAddress
    | where FailedUsers >= 5
    | project IPAddress;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50079"
| where IPAddress in (sprayIPs)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName,
          ClientAppUsed, UserAgent
| sort by TimeGenerated asc

50079 followed within an hour by a security info registration in AuditLogs for the same user:

let interrupts =
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == "50079"
    | project InterruptTime = TimeGenerated,
              UserPrincipalName = tolower(UserPrincipalName),
              SigninIP = IPAddress;
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has "security info"
| extend UserPrincipalName = tolower(tostring(InitiatedBy.user.userPrincipalName)),
         AuditIP = tostring(InitiatedBy.user.ipAddress)
| join kind=inner interrupts on UserPrincipalName
| where TimeGenerated between (InterruptTime .. (InterruptTime + 1h))
| project InterruptTime, RegisteredAt = TimeGenerated, UserPrincipalName,
          SigninIP, AuditIP, OperationName, Result
| sort by RegisteredAt desc

Verify the exact OperationName values for security info registration in your own workspace before relying on the has "security info" filter, and check that InitiatedBy carries the user and IP fields for those events. The threshold of 5 failed users is a starting point, not a Microsoft number.

How do Conditional Access and MFA affect it?

• 50079 means an MFA requirement applies but the account can’t meet it yet. The requirement is not the problem. Who gets to satisfy it first is.
• Microsoft documents that an interrupted sign-in “appears on the logs but shows Not applied for Conditional Access.”
• Conditional Access can protect the registration step itself, for example by only allowing security info registration from trusted locations or compliant devices. When a policy blocks registration, users see 53010 instead.
• Federated users get this code when the federated identity provider didn’t send the MFA claim. In that case registration in Entra ID is not the fix.

How do I fix AADSTS50079?

For the user: register your MFA method from a device and network you trust. If you get a registration prompt you didn’t expect, stop and contact IT.

For admins:

1. For every 50079 from an IP the user doesn’t use, check the account’s registered methods. Remove any you can’t tie to the user.
2. If an attacker registered a method, reset the password, remove the method, and revoke sessions (Revoke-MgUserSignInSession).
3. Protect security info registration with Conditional Access so it can only happen from trusted locations or devices.
4. Don’t leave accounts unregistered for long. An account with a password and no MFA method is registered by whoever signs in first.