Enumerating MFA via Microsoft's Password Reset Portal
Microsoft’s Self-Service Password Reset (SSPR) portal is a legitimate feature designed to let users recover their accounts without calling the helpdesk. It turns out it also tells you quite a lot about the accounts in a tenant — whether they exist, what authentication methods they have registered, and in some cases, which ones are likely administrators. This post covers what the portal leaks, why it matters from both sides, and what defenders can do about it.
What is SSPR?
SSPR allows users to reset their own passwords by verifying their identity through a registered second factor — an authenticator app, a phone number, an alternate email address, and so on. It is configured at the tenant level in Entra ID and requires an Entra ID Premium P1 licence.
The portal is publicly accessible at passwordreset.microsoftonline.com with no prior authentication required. When a user enters their email address and clicks Next, the server responds with a list of verification methods registered for that account. This is the point of interest.
How the Portal Works
The flow involves two HTTP requests per account.
Step 1 — Landing page (GET)
Navigating to the portal loads a standard ASP.NET WebForms page presenting a username field.
The GET response sets the session cookies and embeds three hidden form fields that are required for the server to accept any subsequent POST:
__VIEWSTATE— encrypted, serialised page state bound to the session__EVENTVALIDATION— a signed list of permitted postback controlsWorkflowConsistencyCheck— a timestamp-based anti-replay value
These are cryptographically tied to the session cookie and cannot be predicted or reused across requests.
Step 2 — Username submission (POST)
Clicking Next triggers an ASP.NET UpdatePanel async postback — not a full page navigation. The browser sends a POST to the same URL with the form tokens from step 1, the email address, and a set of control identifiers that tell the server which button was clicked:
1
2
3
4
5
6
7
8
9
10
POST https://passwordreset.microsoftonline.com/
ctl00$ScriptManagerMain=...UpdatePanelMain|...ButtonNext
__EVENTTARGET=ctl00$ContentPlaceholderMainContent$ButtonNext
__VIEWSTATE=<token>
__EVENTVALIDATION=<token>
ctl00$ContentPlaceholderMainContent$TextBoxUserIdentifier=user@contoso.com
ctl00$ContentPlaceholderMainContent$CurrentViewName=ViewUserIdentifierVerification
ctl00$ContentPlaceholderMainContent$WorkflowConsistencyCheck=<token>
__ASYNCPOST=true
The response is a pipe-delimited wire format specific to ASP.NET UpdatePanel. The important part is the HTML block injected into the page, which contains a hidden field:
1
2
<input type="hidden" name="ctl00$ContentPlaceholderMainContent$CurrentViewName"
value="ViewMultigateUserControl" />
This CurrentViewName field is the ground truth for what the server decided. A value of ViewMultigateUserControl means the account exists and SSPR has advanced to the method selection screen. ViewUserIdentifierVerification means the server bounced back to step 1, indicating the account was not found.
Step 3 — Method selection screen
For a valid account with SSPR enabled, the response HTML contains a MultigateAuthenticationControl_RadioTable listing every registered verification method. Methods the user has not registered are present in the DOM but hidden with display:none.
The visible radio buttons directly correspond to what is registered on the account:
1
2
3
4
5
6
7
8
9
10
<table id="MultigateAuthenticationControl_RadioTable">
<tr id="MultigateAuthenticationControl_AltEmailRadioButtonTr">
<input id="MultigateAuthenticationControl_AltEmailRadio" type="radio" />
<label>Email my alternate email</label>
</tr>
<tr id="MultigateAuthenticationControl_AppCodeRadioButtonTr">
<input id="MultigateAuthenticationControl_AppCodeRadio" type="radio" />
<label>Enter a code from my authenticator app</label>
</tr>
</table>
Each radio button ID maps to a specific method. Hidden rows (display:none) are skipped — they represent methods the account has not registered or that the tenant policy has disabled.
The legacy CAPTCHA (now removed)
Prior to August 2026, the portal could present a visual CAPTCHA challenge on the landing page before the username could be submitted. This was served as part of the initial page load and required the user to solve it alongside the email field.
As of August 2026, Microsoft removed this CAPTCHA entirely and replaced it with backend throttling and behaviour-based abuse detection (see MC1400824). The visual challenge no longer appears. Whether the backend controls are effective against low-and-slow enumeration at realistic request rates remains to be demonstrated in practice.
Defensive Considerations
User enumeration
The portal distinguishes between accounts that exist and those that do not. A valid account advances to the method selection screen. An invalid one returns an error with CurrentViewName staying at ViewUserIdentifierVerification and the UserIdErrorLabel span set to display:inline. This makes it straightforward to confirm whether a given email address corresponds to a real account in the tenant — useful information for an attacker building a target list.
Authentication method leakage
For accounts where SSPR is enabled, the portal reveals exactly which second factors are registered. An attacker can see whether an account has a strong factor (authenticator app, push notification, phone) or only a weak one (alternate email OTP, security questions). Accounts with weak-only methods or no methods at all are considerably easier to compromise — there is no meaningful second factor standing between an attacker and the account if they obtain or guess the password.
Admin account identification
Microsoft enforces SSPR for administrator accounts regardless of the tenant-wide SSPR policy. If an organisation has disabled SSPR for standard users, standard accounts return a ViewSsprNotEnabledInUserPolicy response. Admin accounts, however, still advance to the method selection screen. Any account that enumerates cleanly when the broader tenant policy is disabled is likely a privileged role account. Their registered methods are also visible, meaning an attacker can identify high-value targets and assess how well-protected they are before deciding how to proceed.
Adversarial Opportunities
The SSPR portal is public-facing, requires no authentication, and behaves differently depending on whether an account exists and what methods it has configured. This makes it useful for several stages of a campaign:
Reconnaissance. Validate a list of email addresses harvested from LinkedIn, company websites, or data breaches. Separate confirmed accounts from guesses before investing further effort.
Target prioritisation. Identify accounts with weak or missing MFA. These are the most viable targets for password spraying, credential stuffing, or phishing — an attacker who compromises the password has a clear path to access.
Privilege escalation preparation. In tenants where standard SSPR is disabled, enumerate admin accounts specifically. Knowing which accounts have privileged roles, and what their registered factors are, helps an attacker decide where to focus a targeted phishing campaign.
Method-aware phishing. Knowing that a target uses SMS rather than an authenticator app informs the choice of attack. SMS-based MFA is susceptible to SIM swapping and real-time phishing proxies in a way that TOTP is not.
Weak Methods Worth Flagging
Not all second factors are equal. The following are considered weak because they can be phished or socially engineered without significant difficulty:
- Alternate email OTP — the attacker only needs access to a secondary inbox, which may itself be weakly protected
- Security questions — answers are often guessable, publicly available, or obtainable through social engineering
An account that has only these methods registered should be treated similarly to an account with no MFA at all for practical threat modelling purposes.
Limitations of This Approach
It is worth being clear about what the SSPR portal does and does not reveal.
SSPR and MFA use separate method registries. In practice they overlap significantly — Microsoft’s combined registration flow, the default since 2020, registers methods for both simultaneously. But they are not guaranteed to be identical. A method registered for MFA sign-in may not appear in SSPR if it was registered before combined registration was enabled, or if an admin has explicitly excluded it from the SSPR policy.
FIDO2 security keys and certificate-based authentication are not supported by SSPR at all. An account whose only factor is a hardware security key will appear here as having no methods — a false negative. In high-security or passwordless environments this is worth accounting for.
Guest and federated accounts authenticate through their home tenant. The resource tenant’s SSPR portal has no visibility into their home tenant’s method registry and returns a not-supported response. Their MFA posture cannot be assessed this way.
Defensive Recommendations
Enable SSPR selectively and monitor it. SSPR access can be scoped to a specific security group. Restricting it to users who genuinely need it reduces the attack surface and makes enumeration harder. Accounts outside the scoped group return a ViewUserNotMemberOfScopedAccessGroup response that confirms existence but not methods.
Enforce strong authentication methods. Remove alternate email and security questions from the permitted SSPR methods list if your organisation’s policy allows it. Require authenticator app or phone verification as a minimum.
Monitor the SSPR portal for unusual activity. Bulk enumeration attempts — many requests in a short window across varied email addresses, with no subsequent password reset completion — are detectable patterns. Entra ID logs SSPR activity under the audit logs and sign-in logs. Unusual volumes of UserIdentifierVerification events from the same source IP are worth alerting on.
Use Conditional Access to protect privileged accounts. Admin accounts should have phishing-resistant MFA (FIDO2, certificate-based) rather than SMS or authenticator push. Even if an attacker identifies a privileged account through SSPR, a phishing-resistant factor significantly raises the cost of exploitation.
Consider restricting methods for admin accounts. Microsoft enforces SSPR on admin accounts at the platform level and this cannot be disabled, but the methods admins register can be restricted to strong factors only, limiting what an attacker learns and reducing the available attack surface.
ResetSpy
Based on the above, a simple Python script was put together to automate the enumeration process against a list of target accounts. ResetSpy replicates the two-request flow described above for each target, parses the CurrentViewName field and MultigateAuthenticationControl_RadioTable from the response, and classifies each account.
1
2
3
4
5
# Single account
resetspy user@contoso.com
# List of accounts
resetspy emails.txt --csv results.csv
For each target it returns:
- Whether the account exists in the directory
- Which SSPR verification methods are registered, if any
- Whether those methods constitute a meaningful second factor or are weak-only
- The SSPR policy state — disabled, scoped group exclusion, guest/federated, or fully enabled
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
ResetSpy
────────────────────────────────────────────────────────────────────────
Target : emails.txt
Endpoint : https://passwordreset.microsoftonline.com/
Accounts : 5
Delay : 2.0s + jitter
Retries : 1
UA pool : 16
10:52:05 [1/5] alice@contoso.com - MFA OK methods=['Authenticator App (TOTP)'] [2.1s]
10:52:08 [2/5] bob@contoso.com - NO MFA methods=['Alternate Email (OTP)'] [1.9s]
10:52:11 [3/5] ghost@contoso.com - USER NOT FOUND [1.1s]
10:52:14 [4/5] admin@contoso.com - SSPR DISABLED (SSPR not enabled in user policy (SSPR_0011)) [1.7s]
10:52:17 [5/5] guest_gmail.com#EXT#@contoso.com - SSPR N/A (guest/external/federated) [1.4s]
--- Summary (9.3s) ---
Total : 5
Valid accounts : 3/5
Not found : 1/5
SSPR enabled : 2/5
SSPR disabled : 1/5 (account exists; policy blocks SSPR)
SSPR N/A : 1/5 (guest/external/federated)
CAPTCHA : 0/5
Errors : 0/5
No/Weak MFA : 1/2
--- Valid accounts ---
alice@contoso.com
bob@contoso.com
admin@contoso.com
--- Accounts without real MFA ---
bob@contoso.com ['Alternate Email (OTP)']
Results can be exported to CSV with --csv. The MFA Status column in the output makes flagged accounts immediately apparent — PROTECTED, WEAK ONLY - FLAGGED, or NO METHODS - FLAGGED — useful for triaging large account lists quickly.
The tool also handles the various SSPR policy states that return non-standard view names — scoped group exclusions, feature-unavailable responses for guest accounts, and throttle responses — rather than treating them all as errors. User-Agent strings are rotated per request from a pool of 16 realistic browser strings across Windows, macOS, iOS, and Android to reduce fingerprinting, and jitter is applied between requests to avoid trivial rate-limit detection.
ResetSpy is available at github.com/mlcsec/ResetSpy.