Self-service password reset: convenient for users, and potentially for attackers too
Self-service password reset (SSPR) dramatically reduces service desk workload. But any mechanism that lets someone change a password without knowing the old one is, by design, a target. Its strength depends entirely on the verification methods you allow.
SSPR as an account takeover vector
An attacker who controls one of a user's verification methods can reset that user's password. The known scenarios are simple: a fraudulent SIM swap to intercept an SMS, compromise of the personal email address registered as a fallback, or answers to security questions found on social media. Once the password is changed, often only MFA stands between the attacker and the account, and sometimes it relies on the very same methods.
Choose the allowed methods
Not all methods are equal:
| Method | Assessment |
|---|---|
| Microsoft Authenticator notification or code | Preferred |
| SMS, voice call | Acceptable as a second method, exposed to SIM swapping |
| Alternate email | Only as strong as a mailbox you do not control |
| Security questions | Avoid |
Require two methods to reset, and enable periodic reconfirmation of registration details. Security questions rely on information that is often public or guessable; Microsoft does not allow them for administrator roles.
The separate administrator policy
Accounts holding an administrative role are subject to a separate, Microsoft-managed SSPR policy: it is enabled by default and requires two strong methods. Many organisations are unaware of it. If your administrators should not be able to reset their own passwords, this policy can be disabled through Microsoft Graph; otherwise, make sure their registered methods are robust.
Worth checking. Microsoft has been migrating legacy SSPR and MFA method settings into the unified Authentication methods policy. Confirm that your settings were carried over and that no weak method remains enabled by default.
Protect registration and writeback
The weak point is often registration: if an attacker can register their own methods with a stolen password, SSPR belongs to them. A Conditional Access policy targeting the "Register security information" user action (from a trusted network or a compliant device, for example) limits that risk, and a Temporary Access Pass makes onboarding new staff easier.
In hybrid environments, password writeback through Entra Connect or Cloud Sync pushes the change down to Active Directory. That is convenient, but it also means a fraudulent cloud reset grants access to on-premises resources. The sync account should hold only the permissions it needs on the relevant organisational units.
What an audit checks
- the number of methods required and the absence of security questions;
- the state of the administrator SSPR policy;
- Conditional Access protection of security information registration;
- notifications to users and administrators when a reset occurs;
- the scope of writeback permissions in Active Directory.