AADSTS50072: User needs to enroll for second factor authentication

What does AADSTS50072 mean?

Microsoft’s description:

UserStrongAuthEnrollmentRequiredInterrupt: User needs to enroll for second factor authentication (interactive).

Microsoft’s password spray playbook lists it among the Entra codes to monitor, worded as “50072 - User prompted to provide MFA”. Both texts point to the same moment: the password was accepted, MFA applies, and the sign-in is interrupted for the second factor. The error reference says the user still has to enroll one.

The closely related 50079 is the code the playbook describes as “user needs to register security info”.

What is the quick fix?

Usually nothing is broken. The user has to set up a second factor and then finish signing in.

• User: follow the registration prompt from a device and network you trust. If you didn’t start this sign-in, stop and contact IT.
• Admin, new users: Microsoft’s Conditional Access guidance says “Administrators have to issue Temporary Access Pass credentials to new users so they can satisfy the requirements for multifactor authentication to register” when registration itself requires MFA. Microsoft also notes “Temporary Access Pass does not work for guest users.”
• Admin, unexpected rows: if the user should already have methods, or the IP is unfamiliar, see the next section.

Is it an attack?

For a new hire or a user who just came into scope of an MFA policy, 50072 is the normal path into MFA. It matters when the sign-in isn’t the user’s: whoever completes enrollment from that session chooses the second factor. This is reasoning from how registration works, not a Microsoft statement. It is the same concern as on the 50079 page.

Pattern	Likely meaning
50072 for a new or newly in-scope user from a known office or home IP	Expected enrollment. Benign.
50072 from an IP that also produced 50126 failures against other users	A spray found a working password on an account without MFA.
50072 from an unfamiliar IP or country, then a success	Someone may have registered their own method. Check the account’s methods.
50072 for a long-standing account that should already be registered	Check whether its methods were removed, and by whom.

These readings are based on Microsoft’s description and the playbook listing. Microsoft doesn’t publish a threat pattern for 50072 specifically.

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

50072 per user and IP, with whether the same user and IP had a success afterwards:

let window = 7d;
let interrupts =
    SigninLogs
    | where TimeGenerated > ago(window)
    | where ResultType == "50072"
    | summarize FirstInterrupt = min(TimeGenerated), Interrupts = count(),
                Apps = make_set(AppDisplayName, 5)
              by UserPrincipalName, IPAddress
    | extend Apps = strcat_array(Apps, ", ");
let successes =
    SigninLogs
    | where TimeGenerated > ago(window)
    | where ResultType == "0"
    | project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress;
interrupts
| join kind=leftouter successes on UserPrincipalName, IPAddress
| summarize SuccessAfter = countif(SuccessTime > FirstInterrupt)
          by UserPrincipalName, IPAddress, FirstInterrupt, Interrupts, Apps
| sort by FirstInterrupt desc

50072 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 == "50072"
| where IPAddress in (sprayIPs)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName,
          ClientAppUsed, UserAgent
| sort by TimeGenerated asc

The threshold of 5 failed users is a starting point, not a Microsoft number. ResultType is a string column, so compare it with "50072", not 50072.

How do Conditional Access and MFA affect it?

• 50072 means an MFA requirement applies and the account can’t meet it yet.
• Microsoft documents that an interrupted sign-in “appears on the logs but shows Not applied for Conditional Access.” So notApplied on a 50072 row doesn’t mean your policies are missing.
• Conditional Access can protect the registration step itself with the Register security information user action. Microsoft’s template “requires users who are not on a trusted network to do multifactor authentication” to register.

How do I fix AADSTS50072?

For the user: register your second factor when prompted, from a device and network you trust.

For admins:

1. For new users, issue a Temporary Access Pass if your registration policy requires MFA.
2. For every 50072 from an IP the user doesn’t use, check the account’s registered methods and remove any you can’t tie to the user.
3. Protect security info registration with a Conditional Access policy on the Register security information user action.