Password resets are the most common helpdesk request in almost every small business I work with. Self-service password reset in Entra ID removes most of those calls, but a careless setup can also become the easiest way for an attacker to take over an account. If anyone with a stolen phone number can reset a password, you’ve just moved the weak point, not removed it.
This article covers licensing, the settings that matter, how SSPR interacts with MFA and Conditional Access, and a checklist for running it securely.
What you need: licensing and prerequisites
Scenario
Included in
Cloud-only user changes a known password
All editions, including Entra ID Free
Cloud-only user resets a forgotten password
Microsoft 365 Business Standard or higher, Entra ID P1 or P2
Synced (hybrid) user resets with writeback to on-premises AD
Microsoft 365 Business Premium, Entra ID P1 or P2
If your users are synced from on-premises Active Directory, you also need password writeback turned on in Microsoft Entra Connect or Microsoft Entra Connect cloud sync. Without writeback, a reset in the cloud doesn’t change the password users type at their domain-joined PC. Writeback uses an outbound connection only, so no inbound firewall rules are needed.
The settings that decide whether SSPR is safe
1. Authentication methods
SSPR can accept Microsoft Authenticator notifications, software and hardware OATH codes, SMS, voice calls, email one-time passcodes and, in the legacy settings, security questions. Choose the strongest set your users can realistically use:
Use: Microsoft Authenticator (notification or code), email to a personal address as a second method.
Limit: SMS and voice, only for a small exception group if at all.
Avoid: security questions. The answers are often discoverable on social media or guessable by colleagues.
Since the legacy MFA and SSPR method settings can no longer be managed after September 30, 2025, configure methods in Entra ID > Authentication methods > Policies. Security questions are the one exception that still lives in the legacy SSPR page.
2. Number of methods required
Set this to two. With one method, anyone who controls a single factor (a phone number, a mailbox) can take over the account. With two, they need both. One quirk to know: for SSPR, Microsoft Authenticator, software OATH and hardware OATH count as a single method. So a user needs Authenticator plus something else, such as email or a phone number, to satisfy a two-method policy.
3. Scope
Enable SSPR for a group, not “All”. That lets you leave out emergency access accounts and service accounts, and pilot with a small set of users first. Emergency access accounts in particular should not be in SSPR scope, because it can push them to register phone methods they shouldn’t have.
4. Notifications
Turn on both notification settings in the SSPR Notifications page:
Notify users when their own credentials are reset. If someone does this without the user knowing, the user gets an email and can raise the alarm.
Notify all admins when another admin resets theirs.
5. Re-confirmation
Under Registration, set how often users are asked to reconfirm their authentication information. The default of 180 days is reasonable. It keeps phone numbers and personal emails from going stale.
Admins are handled differently
Accounts with administrator roles follow a separate, stricter admin policy that you can’t change. Admins must use two methods and are limited to a set that includes phone options. That can force admins to register a phone number they would rather not have on the account. Many organizations choose to turn SSPR off for administrators entirely and handle admin recovery through a second admin with a documented process, especially once admins sign in with passkeys and rarely type a password at all.
Protect the registration process
SSPR is only as strong as the methods users register. If an attacker gets a user’s credentials before that user has registered methods, the attacker can register their own phone and keep control. Close the gap:
Create a Conditional Access policy targeting the Register security information user action that requires MFA, so new methods can only be added from a verified session.
Use a Temporary Access Pass for new hires so they register methods on day one under controlled conditions.
Run a registration campaign so existing users register before attackers get the chance.
Review the Authentication methods activity report for users with only one method registered.
Our MFA enablement service runs registration and SSPR together, because users register once for both through the combined security info experience.
A secure SSPR checklist
Licensing confirmed for cloud-only and synced users.
Writeback enabled and tested for hybrid users.
Methods configured in the Authentication methods policy; security questions off.
Two methods required.
SSPR scoped to a group that excludes emergency access and service accounts.
User and admin notifications turned on.
Security info registration protected by Conditional Access.
Temporary Access Pass enabled for onboarding and lost devices.
The reset link on the Windows sign-in screen enabled through Intune for Entra joined devices, so users locked out at the PC can recover.
Audit logs for SSPR activity reviewed or alerted on, especially for privileged users.
A good SSPR configuration still fails if nobody knows it exists. Roll it out in three short stages:
Pilot. Enable SSPR for a group of 10 to 15 people, including someone from the front desk and someone who works remotely. Ask each of them to test a reset from a phone and from a PC sign-in screen, and note anything confusing.
Register everyone. Turn on the registration requirement so users are asked to confirm their methods at their next sign-in. Because registration is combined with MFA, most people will already have Authenticator and only need to add a second method.
Announce and redirect. Send a short message explaining where the reset link is, then update the helpdesk script so callers are walked through SSPR rather than reset by hand. Keep a manual route for people with genuine problems, with identity verification by call-back to a known number.
After a month, check the SSPR usage and insights reports in the Entra admin center. You should see self-service resets replacing helpdesk tickets. If usage is low, the usual cause is that people don’t know the link exists, so put it on the intranet and in the email signature of IT staff.
Frequently asked questions
Does SSPR replace MFA?
No. They share registered methods, but SSPR is for recovering a forgotten credential and MFA protects every sign-in. You need both, and with passkeys in place, users will need resets far less often.
Should we allow SMS for SSPR?
Only as a second method alongside Authenticator, and ideally only for users who can’t use an app. A phone number on its own is too easy to take over through SIM swapping to be the only thing standing between an attacker and the account.
Why do some users see an error when they try SSPR?
Usually because they haven’t registered enough methods for the policy. If you require two methods and they’ve registered one, they can’t use SSPR and need an admin to help. The fix is a registration campaign and reconfirmation reminders.
Want fewer reset tickets without opening a new attack path? Book a free Microsoft 365 security assessment and we’ll review your SSPR methods, scope and registration protection.
Password resets are the most common helpdesk request in almost every small business I work with. Self-service password reset in Entra ID removes most of those calls, but a careless setup can also become the easiest way for an attacker to take over an account. If anyone with a stolen phone number can reset a password, you’ve just moved the weak point, not removed it.
This article covers licensing, the settings that matter, how SSPR interacts with MFA and Conditional Access, and a checklist for running it securely.
What you need: licensing and prerequisites
If your users are synced from on-premises Active Directory, you also need password writeback turned on in Microsoft Entra Connect or Microsoft Entra Connect cloud sync. Without writeback, a reset in the cloud doesn’t change the password users type at their domain-joined PC. Writeback uses an outbound connection only, so no inbound firewall rules are needed.
The settings that decide whether SSPR is safe
1. Authentication methods
SSPR can accept Microsoft Authenticator notifications, software and hardware OATH codes, SMS, voice calls, email one-time passcodes and, in the legacy settings, security questions. Choose the strongest set your users can realistically use:
Since the legacy MFA and SSPR method settings can no longer be managed after September 30, 2025, configure methods in
Entra ID > Authentication methods > Policies. Security questions are the one exception that still lives in the legacy SSPR page.2. Number of methods required
Set this to two. With one method, anyone who controls a single factor (a phone number, a mailbox) can take over the account. With two, they need both. One quirk to know: for SSPR, Microsoft Authenticator, software OATH and hardware OATH count as a single method. So a user needs Authenticator plus something else, such as email or a phone number, to satisfy a two-method policy.
3. Scope
Enable SSPR for a group, not “All”. That lets you leave out emergency access accounts and service accounts, and pilot with a small set of users first. Emergency access accounts in particular should not be in SSPR scope, because it can push them to register phone methods they shouldn’t have.
4. Notifications
Turn on both notification settings in the SSPR Notifications page:
5. Re-confirmation
Under Registration, set how often users are asked to reconfirm their authentication information. The default of 180 days is reasonable. It keeps phone numbers and personal emails from going stale.
Admins are handled differently
Accounts with administrator roles follow a separate, stricter admin policy that you can’t change. Admins must use two methods and are limited to a set that includes phone options. That can force admins to register a phone number they would rather not have on the account. Many organizations choose to turn SSPR off for administrators entirely and handle admin recovery through a second admin with a documented process, especially once admins sign in with passkeys and rarely type a password at all.
Protect the registration process
SSPR is only as strong as the methods users register. If an attacker gets a user’s credentials before that user has registered methods, the attacker can register their own phone and keep control. Close the gap:
Our MFA enablement service runs registration and SSPR together, because users register once for both through the combined security info experience.
A secure SSPR checklist
For the Windows sign-in screen piece, see our Intune services. If you’d like the whole configuration reviewed, it is part of every Microsoft 365 security assessment.
Microsoft’s explanation of how self-service password reset works covers each option in more depth.
Rolling SSPR out to staff
A good SSPR configuration still fails if nobody knows it exists. Roll it out in three short stages:
After a month, check the SSPR usage and insights reports in the Entra admin center. You should see self-service resets replacing helpdesk tickets. If usage is low, the usual cause is that people don’t know the link exists, so put it on the intranet and in the email signature of IT staff.
Frequently asked questions
Does SSPR replace MFA?
No. They share registered methods, but SSPR is for recovering a forgotten credential and MFA protects every sign-in. You need both, and with passkeys in place, users will need resets far less often.
Should we allow SMS for SSPR?
Only as a second method alongside Authenticator, and ideally only for users who can’t use an app. A phone number on its own is too easy to take over through SIM swapping to be the only thing standing between an attacker and the account.
Why do some users see an error when they try SSPR?
Usually because they haven’t registered enough methods for the policy. If you require two methods and they’ve registered one, they can’t use SSPR and need an admin to help. The fix is a registration campaign and reconfirmation reminders.
Want fewer reset tickets without opening a new attack path? Book a free Microsoft 365 security assessment and we’ll review your SSPR methods, scope and registration protection.