Microsoft's Self-Service Password Reset (SSPR) portal is a legitimate feature designed to let users recover their accounts without calling the helpdesk. As 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 license.
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.
Figure 1. SSPR landing page
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 controls
-
`WorkflowConsistencyCheck` - 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:
```
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:
```
<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.
Beyond these two primary states, the server returns a range of named views that correspond directly to Microsoft's documented SSPR error codes. These views are not visible to the user in the same form — users see a friendly error message — but they appear verbatim in the “CurrentViewName” hidden field of the wire response and can be read directly from the POST reply:
| View name | SSPR error code | Meaning |
|---|---|---|
| `ViewSsprNotEnabledInUserPolicy` | SSPR_0011 | Account exists; no password reset policy defined for this user |
| `ViewUserNotMemberOfScopedAccessGroup` | SSPR_0013 | Account exists; not a member of the group enabled for SSPR |
| `ViewUserNotEnabled` | SSPR_0009 / SSPR_0012 | SSPR disabled at tenant level or missing licence |
| `ViewFeatureNotAvailable` | - | Guest, external, or federated account - SSPR not applicable |
The error codes themselves are documented in Microsoft's SSPR troubleshooting reference. The key insight is that each one confirms the account exists — the server has looked it up and made a policy decision about it — even though it is declining to offer the reset flow.
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”.
Figure 2. SSPR method selection screen showing registered verification methods.
The visible radio buttons directly correspond to what is registered on the account:
```html
<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.
Figure 3. Legacy SSPR CAPTCHA challenge — visual character entry.
As of August 2026, Microsoft removed this CAPTCHA entirely and replaced it with backend throttling and behavior-based abuse detection (see MC1400824). The landing page now presents only the email field with no visual challenge.
Figure 4. SSPR landing page post-CAPTCHA removal — clean email input with no challenge.
What the Portal Reveals
The SSPR portal is public-facing and requires no authentication. The way it behaves — and crucially, the way it behaves differently depending on the account — makes it a useful reconnaissance tool at several stages of a campaign.
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 a visible error and keeps “CurrentViewName” at “ViewUserIdentifierVerification” with the “UserIdErrorLabel” span set to “display:inline”.
Figure 5. Invalid account — user not found error message.
Importantly, every non-“ViewUserIdentifierVerification” response — including “SSPR_0011”, “SSPR_0013”, and the guest/federated not-available response — is confirmation that the account exists. The server only reaches those policy checks after successfully resolving the username in the directory. A true not-found simply bounces the form back to step 1. For an attacker with a list of email addresses harvested from LinkedIn, a company website, or a data breach, this turns a set of guesses into a confirmed target list before any credential attack is attempted.
Authentication Method Leakage
For accounts where SSPR is enabled, the portal reveals exactly which second factors are registered. The distinction matters: an account with an authenticator app registered is a meaningfully harder target than one with only an alternate email OTP. An attacker who can see that a target uses SMS rather than an authenticator app can tailor their approach accordingly — SMS is susceptible to SIM swapping and real-time phishing proxies in a way that TOTP is not. Accounts with weak-only methods or no methods at all require only a compromised password to access, with no meaningful second factor in the way.
Admin Account Identification
Microsoft enforces SSPR for administrator accounts regardless of the tenant-wide SSPR policy. If an organization has disabled SSPR for standard users, standard accounts return “ViewSsprNotEnabledInUserPolicy” (SSPR_0011). Admin accounts bypass this check entirely and proceed to method enumeration regardless. Any account that reaches the method selection screen when the broader tenant policy is disabled is likely a privileged role account — and their registered methods are visible too.
The note is visible in the Entra admin center itself on the password reset properties page — SSPR policy settings explicitly apply only to end users, with admins always enabled regardless.
Figure 6. Entra admin center — password reset properties showing SSPR scoped to selected group with admin policy note.
When SSPR is scoped to a specific group, users outside it receive “ViewUserNotMemberOfScopedAccessGroup” (SSPR_0013). Users inside the group who have not registered any methods see the following rather than the radio button selection screen:
Figure 7. SSPR — the account exists but no methods were registered.
In tenants where SSPR is disabled for standard users, admin accounts stand out immediately. Knowing which accounts hold privileged roles, and what their registered factors are, helps focus a targeted phishing or social engineering campaign on the highest-value accounts.
Putting It Together
Each finding from the portal maps directly to a stage of a campaign:
- Reconnaissance: A list of email addresses from LinkedIn, a company website, or a data breach can be validated quickly. Confirmed accounts are separated from guesses before any credential attack is attempted, avoiding wasted effort and unnecessary noise.
- Target Prioritization: Accounts with weak or missing MFA are the most viable targets for password spraying, credential stuffing, or phishing. An attacker who obtains or guesses a password for one of these accounts has a clear path to access with no meaningful second factor in the way.
- Privilege Escalation: In tenants where standard SSPR is disabled, any account that still enumerates cleanly is likely an admin. Knowing which accounts hold privileged roles, and what factors they have registered, informs where to direct a targeted attack.
- Phishing/Vishing: Knowing the specific second factor a target has registered allows an attacker to choose the most effective approach. An account protected by SMS is a viable target for a real-time phishing proxy or SIM swap. An account using a push notification authenticator could be susceptible to MFA fatigue attacks. An account with only alternate email OTP may not require anything beyond access to a secondary inbox. Each method has a different threat profile, and the portal reveals which one applies.
Weak Verification Methods
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.
What Changes When SSPR Policy Changes
The two outputs below show the same four accounts run against the same tenant under two different SSPR configurations. The difference in results demonstrates exactly why the “CurrentViewName” field is more informative than a simple pass/fail.
Configuration 1: SSPR Disabled for All Standard Users
```
12:55:37 [1/4] user1@example.com - SSPR DISABLED (SSPR_0011) [2.4s]
12:55:42 [2/4] admin@example.com - MFA OK methods=['Alternate Email (OTP)', 'Authenticator App (TOTP)'] [2.0s]
12:55:47 [3/4] fail@example.com - USER NOT FOUND [0.7s]
12:55:52 [4/4] nomfa@example.com - SSPR DISABLED (SSPR_0011) [3.3s]
--- Summary (17.0s) ---
Total : 4
Valid accounts : 3/4
Not found : 1/4
SSPR enabled : 1/4
SSPR disabled : 2/4 (account exists; policy blocks SSPR)
SSPR N/A : 0/4
No/Weak MFA : 0/1
--- Valid accounts ---
user1@example.com
admin@example.com
nomfa@example.com
--- SSPR disabled (account exists) ---
user1@example.com
nomfa@example.com
```
Three accounts are confirmed to exist. Two return “ViewSsprNotEnabledInUserPolicy” (SSPR_0011) — the server found the account, checked the policy, and declined to proceed. One (“admin”) reaches the method selection screen because it is an admin account. Admin accounts bypass the user policy check entirely and always proceed to SSPR regardless of the tenant setting, which is what makes them identifiable here. “nomfa” returns the same SSPR_0011 response as “user1” — both exist, but we cannot tell from this run alone whether “nomfa” has any MFA methods registered.
Configuration 2: SSPR Scoped to a Selected Group
```
13:19:34 [1/4] user1@example.com - SSPR DISABLED (Not in SSPR group - SSPR restricted and user excluded) [2.2s]
13:19:39 [2/4] admin@example.com - MFA OK methods=['Alternate Email (OTP)', 'Authenticator App (TOTP)'] [2.0s]
13:19:43 [3/4] fail@example.com - USER NOT FOUND [0.9s]
13:19:47 [4/4] nomfa@example.com - NO MFA methods=['(none - no SSPR methods registered)'] [4.7s]
--- Summary (17.7s) ---
Total : 4
Valid accounts : 3/4
Not found : 1/4
SSPR enabled : 2/4
SSPR disabled : 1/4 (account exists; policy blocks SSPR)
SSPR N/A : 0/4
No/Weak MFA : 1/2
--- Valid accounts ---
user1@example.com
admin@example.com
nomfa@example.com
--- Weak or no MFA ---
nomfa@example.com
```
The same four accounts, different policy. “user1” now returns “ViewUserNotMemberOfScopedAccessGroup” (SSPR_0013) instead of SSPR_0011 — the account exists but is not in the security group that has been granted SSPR access. “nomfa” now returns “ViewMultigateUserControl” with an empty method list, meaning it is inside the scoped group, SSPR proceeded normally, and the account has no verification methods registered at all. This is SSPR_0014 territory (“UserNotProperlyConfigured”) — the account is reachable but has nothing to verify with.
What the Difference Tells Us
| Account | Config 1 | Config 2 | Conclusion ||---|---|---|---|| `user1` | SSPR_0011 (policy disabled) | SSPR_0013 (not in group) | Exists; no SSPR access in either config || `admin` | MFA OK | MFA OK | Admin account; bypasses policy both times || `fail` | NOT FOUND | NOT FOUND | Does not exist || `nomfa` | SSPR_0011 (policy disabled) | NO MFA (empty methods) | Exists; in the scoped group; no MFA registered |
“nomfa” is the interesting one. Config 1 could not tell us anything about its MFA posture because SSPR never reached the method check. Config 2 reveals it has no methods registered at all — a much more actionable finding. Scoped SSPR, counterintuitively, leaks more information about the accounts that are inside the group than a blanket disabled policy does, because those accounts proceed all the way to method enumeration.
The No-MFA Assumption from SSPR_0014
When an account is in scope for SSPR but has no authentication methods registered, Microsoft returns SSPR_0014 and the user sees:
> You can't reset your own password because you haven't registered for password reset.
Figure 8. SSPR — the account exists but no methods were registered.
The Microsoft documentation for SSPR_0014 states: "You haven't registered the necessary security information to perform password reset."
This is directly relevant to MFA posture. Because Microsoft's combined registration experience registers methods for both SSPR and MFA in the same flow, an account that has not registered for password reset has almost certainly not registered for MFA either. The two share the same method registry on modern tenants — if nothing was registered for SSPR, there is nothing registered for MFA sign-in either.
This is not a guarantee. As noted in the limitations, a user could have registered MFA methods through a legacy flow before combined registration was enabled, or an admin could have pre-seeded MFA methods without going through the SSPR registration flow. In practice, on most standard tenants, these cases are uncommon. An SSPR_0014 response — or equivalently, a “ViewMultigateUserControl” with an empty radio table — is a strong signal that the account has no meaningful second factor protecting sign-in and should be treated as a high-priority finding.
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 `ViewFeatureNotAvailable`. Their MFA posture cannot be assessed this way.
- SSPR disabled or misconfigured (SSPR_0011 / SSPR_0014). If SSPR is not licensed or not enabled for a user, the endpoint returns “ViewSsprNotEnabledInUserPolicy” (SSPR_0011) and no method information is available. The account exists and likely has MFA configured, but this tool cannot determine what. A related code, SSPR_0014 (“UserNotProperlyConfigured”), applies when the account is in scope but has registered no authentication methods — this surfaces as “ViewMultigateUserControl” with an empty radio table rather than a separate view name, so it is identified by the absence of methods rather than the view itself. Both confirm the account exists.
ResetSpy
Based on the above, a Python script was developed to automate the enumeration process against a list of target accounts by replicating the two-request flow described above for each target, parsing the `CurrentViewName` field and `MultigateAuthenticationControl_RadioTable` from the response, and then classifying each account.
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
```
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@example.com - MFA OK methods=['Authenticator App (TOTP)'] [2.1s]
10:52:08 [2/5] bob@example.com - NO MFA methods=['Alternate Email (OTP)'] [1.9s]
10:52:11 [3/5] ghost@example.com - USER NOT FOUND [1.1s
10:52:14 [4/5] admin@example.com - SSPR DISABLED (SSPR_0011 - account exists, policy blocks SSPR) [1.7s]
10:52:17 [5/5] guest_ext#EXT#@example.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@example.com
bob@example.com
admin@example.com--- Weak or no MFA ---
bob@example.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.
It 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 basic rate-limit detections.
ResetSpy is available at github.com/mlcsec/ResetSpy.
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. Monitoring Entra Audit Logs for status failures with “user is not member of the password reset users group” can identify enumeration or malicious activity.
- Enforce Strong Authentication Methods. Remove alternate email and security questions from the permitted SSPR methods list if your organization'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 Entra Audit Logs — unusual volumes of events with status failures are worth alerting and investigating.
- 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.
Figure 9. Entra Audit Logs
