Microsoft’s self-service password reset (SSPR) system — part of Entra ID — may be unintentionally disclosing sensitive account details to anyone initiating a reset, even without valid credentials. Particularly, the system’s responses vary depending on the type of username submitted, revealing whether a user exists, whether SSPR is enabled for them, and which multi-factor authentication (MFA) methods are available. These nuances give attackers potential intelligence about user accounts.
How the Exposure Works
The vulnerability stems from differences in server responses when someone enters a username into the SSPR portal. Invalid usernames trigger one type of reply, while existing usernames—especially those eligible for password reset—produce distinct responses. For example, a valid user might be prompted to pick a verification method or run into policy errors indicating the user’s membership in an SSPR-disabled group. These variations, small though they seem, betray whether an account is real and what security features it employs.
For users who are eligible, the portal also displays available verification methods such as SMS, automated call, authenticator app, or security questions. Attackers can exploit this to tailor their social engineering or phishing campaigns. Someone who uses SMS verification becomes a more appealing target for SIM-swapping; knowing a user relies on less secure methods like email OTP or security questions lowers the bar for compromising an account.
Why It Matters for Enterprises
This issue enables “user enumeration” attacks—where an attacker confirms which addresses correspond to active accounts within a company. With such a list, they can launch more targeted credential-stuffing or phishing attacks. For higher-risk or privileged accounts, quirks in response patterns might mark them out. Admin roles, for example, often have stricter verification or special password-reset policies, and seeing an account pass certain checks might signal elevated permissions.
Defensive teams are advised to audit their SSPR configurations closely: limit which users are included, prefer phishing-resistant MFA options for privileged accounts, and minimize weaker fallback methods like email OTP, legacy questions, or alternate email. Monitoring Entra audit logs for repeated reset attempts, especially those targeting executive-level usernames, can help detect probing activities. Though Microsoft has rate-limiting in place, it alone won’t prevent attackers from gathering reconnaissance data when response messages differ noticeably.
A proof-of-concept tool named ResetSpy demonstrates how to automate this reconnaissance: scanning lists of known emails to detect which are valid accounts, which reset workflow they fall into, and which authentication methods they use. Such tools magnify the security risk by enabling mass probing with minimal effort.
What this reveals is not just a Microsoft flaw but a reminder: identity tools and workflows entrusted with protecting credentials can ironically become sources of exposure. As more organizations shift to passwordless or MFA-based access, how reset portals behave when facing invalid or untargeted input becomes mission-critical. Companies using Entra ID should treat SSPR settings like any perimeter control—monitor, tighten, and test. Watch for updates from Microsoft; in the meantime, patch these visibility gaps through configuration rather than waiting for a code fix.
