# AADSTS50072: User needs to enroll for second factor authentication Canonical: https://brambrinkmeier.com/entra/aadsts/50072/ By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/50072.json **Short answer:** AADSTS50072 is an interrupt: the user must enroll a second factor before the sign-in can finish. For a new user it is expected. Microsoft's password spray playbook lists it among the codes to monitor. From an unfamiliar IP it can mean someone with the correct password is being asked to set up MFA on the account. **Fix:** User: register your second factor when prompted, from a device and network you trust. If you didn't start this sign-in, stop and contact IT. Admin: issue new users a Temporary Access Pass if registration requires MFA. From an unfamiliar IP, check the account's registered methods. | Field | Value | |---|---| | Code | AADSTS50072 | | Microsoft name | UserStrongAuthEnrollmentRequiredInterrupt | | Category | Multifactor authentication | | Type | Interrupt (an expected extra step, not a failure) | | Attack signal | Medium: worth a look in context | | MITRE ATT&CK | [T1078.004](https://attack.mitre.org/techniques/T1078/004/) Valid Accounts: Cloud Accounts, [T1098.005](https://attack.mitre.org/techniques/T1098/005/) Account Manipulation: Device Registration | | Where to look | `SigninLogs` | | In Microsoft's error reference | Yes | | Verification | documentation | | Last updated | 2026-10-25 | ## 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](https://brambrinkmeier.com/entra/aadsts/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](https://brambrinkmeier.com/entra/aadsts/50079/). | 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: ```kusto 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: ```kusto 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. ## Evidence Not reproduced in the lab yet; the page is based on Microsoft's documentation. Lab-run rows naming this code (9; full list at https://brambrinkmeier.com/lab-runs.json): | Date | Scenario | Expected | Got | Message (first line) | |---|---|---|---|---| | 2026-10-25 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | 65001 | AADSTS65001: The user or administrator has not consented to use the application with ID '{app-id}' named 'lab-signin-client'. Send a | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | 65001 | AADSTS65001: The user or administrator has not consented to use the application with ID '{app-id}' named 'lab-signin-client'. Send a | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | | 2026-10-30 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | 65001 | AADSTS65001: The user or administrator has not consented to use the application with ID '{app-id}' named 'lab-signin-client'. Send a | | 2026-10-31 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | | 2026-10-31 | Correct password (security defaults / MFA / consent decide) | success / 50076 / 50079 / 65001 / 50072 | success | | ## Sources 1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes) 2. [Password spray investigation (Microsoft incident response playbook)](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray) 3. [Interactive user sign-ins](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-interactive-sign-ins) 4. [Require MFA for security info registration (Conditional Access)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration) 5. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs) ## Related codes [AADSTS50079](https://brambrinkmeier.com/entra/aadsts/50079/), [AADSTS50074](https://brambrinkmeier.com/entra/aadsts/50074/), [AADSTS50076](https://brambrinkmeier.com/entra/aadsts/50076/), [AADSTS53003](https://brambrinkmeier.com/entra/aadsts/53003/) ## License and citation CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change. Cite as: Bram Brinkmeier, "AADSTS50072: User needs to enroll for second factor authentication", https://brambrinkmeier.com/entra/aadsts/50072/ (CC BY 4.0), last updated 2026-10-25.