AADSTS50072 (UserStrongAuthEnrollmentRequiredInterrupt): MFA Not Set Up

What it means

An Entra ID sign-in runs in stages: credentials are checked, Conditional Access and MFA requirements are evaluated, a challenge is issued, and only then is a token returned. AADSTS50072 is recorded at that middle stage. Microsoft’s wording is “User needs to enroll for second factor authentication (interactive)” — MFA is required for this sign-in and the account has no method registered to be challenged with, so the interactive session is interrupted and the user is sent to registration instead.

Two facts follow from that, and both matter during triage:

• The first factor succeeded. Whoever sent the request supplied a password Entra ID accepted.
• The account has no second factor. Nothing stands between that password and a token except the registration prompt itself — and a registration prompt will happily accept the attacker’s own authenticator app or phone number.

Is it an attack?

Routine 50072 entries cluster around change: a new joiner’s first sign-in, an account whose methods an administrator has just reset, or a population that has only now come into scope for MFA. Those come from the user’s normal country, network and device, and a successful sign-in from the same IP follows once registration finishes.

Treat it as an incident when any of these are true:

• the IP, country or ASN is new for the user, or belongs to hosting, VPN or Tor space;
• the same IP produces 50072 for several different users, or appears alongside AADSTS50126 failures for other accounts — that is a spray that found a password on an unprotected account;
• enrollment completed from that unfamiliar address, which gives the attacker a durable second factor on the account (MITRE T1098.005);
• the client application or user agent is one the user never uses.

Codes AADSTS50074 and AADSTS50076 also mean the password was already accepted; 50072 is the case where the account has no second factor registered at all.

How to investigate

Start by finding which sources are hitting unenrolled accounts, and how many accounts each one touched:

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50072"
| summarize Attempts = count(), Users = dcount(UserPrincipalName),
            UserList = make_set(UserPrincipalName, 20), Apps = make_set(AppDisplayName, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by IPAddress, Location
| order by Users desc, Attempts desc

One IP against several users is a spray result, not a help-desk ticket. Then answer the question that sets the severity — did the sign-in complete from the same address after the prompt?

let lookback = 14d;
let prompts = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == "50072"
    | project PromptTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, Location, ClientAppUsed;
let wins = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == "0"
    | project WinTime = TimeGenerated, UserPrincipalName, IPAddress;
prompts
| join kind=leftouter wins on UserPrincipalName, IPAddress
| summarize SignedInAfter = countif(WinTime between (PromptTime .. (PromptTime + 30m)))
    by PromptTime, UserPrincipalName, IPAddress, Location, AppDisplayName, ClientAppUsed
| order by PromptTime desc

A row with SignedInAfter above zero from an address the user cannot account for means registration was completed by someone else: reset the password, revoke sessions, remove the authentication methods the user did not add, and then check the mailbox for new forwarding or inbox rules and the account for recent application consents. Rows with no success and an unfamiliar source still mean the password is known — reset it anyway, and look for the same IP under other accounts before closing the case.