Self-service password reset, usually shortened to SSPR, lets a Microsoft 365 user who has forgotten or locked out their password reset it themselves, without calling anyone. They prove who they are using authentication methods registered ahead of time — a phone number, an authenticator app, an alternate email address — and once they've done that, they set a new password and get straight back to work. For a small business, it is one of the highest-leverage settings in the tenant to get right, because password resets are reliably one of the most common reasons someone calls IT.
SSPR itself doesn't cost anything extra to turn on — it's a capability of Microsoft Entra ID, the identity platform underneath every Microsoft 365 subscription. Where licensing starts to matter is in a hybrid environment with an on-premises Active Directory, covered further down, and in some of the more advanced authentication and reporting options. For a typical small business running entirely in the cloud, the setup described here needs no extra purchase — just the will to configure it properly and roll it out.
What does SSPR actually need to work?
Two things have to be true before SSPR does anyone any good. First, it has to be enabled for the users who need it — in Microsoft Entra ID, SSPR is turned on for none, some, or all users, and "some users" is done through a security group, which is the sensible middle ground for a staged rollout. Second, and this is the part businesses skip, every one of those users has to have actually registered authentication methods before the day they need them. SSPR enabled for someone who has never registered a phone number or an authenticator app is a feature that exists on paper and does nothing the day it's needed.
Choosing authentication methods and how many are required
Microsoft Entra ID offers a handful of methods users can register for SSPR: a notification or code through the Microsoft Authenticator app, a text message or phone call to a mobile number, a call to an office phone, an alternate email address, and security questions. Authenticator app and mobile phone are the two worth defaulting to for a small business — they're methods almost everyone already has in their pocket, and they double up as MFA methods too, so registering once often satisfies both. Security questions are the weakest option on the list and worth avoiding or disabling; the answers are often guessable or discoverable, which defeats the point of an identity check.
The tenant also controls how many methods a user has to register, and separately, how many they have to provide at the point of reset. A sensible default is to require two methods registered and two provided at reset time — one method alone means a single point of failure (a lost phone with both the authenticator app and the only registered mobile number on it locks the person out of resetting their own password), while two independent methods gives a genuine second check without becoming a registration chore nobody finishes.
Rolling it out so people actually register
Registration has to be forced, not requested, or it doesn't happen at scale. The reliable way to do this is to combine SSPR and MFA registration into a single interruption: when the user next signs in, they're prompted to set up their methods before they can continue, rather than being sent an email asking them to do it in their own time. Microsoft's combined registration experience is designed to do exactly this — one registration flow that covers both MFA and SSPR at once, so a user isn't asked to go through the process twice.
A staged rollout works better than flipping it on for everyone at once. Start with a pilot group — IT, and a handful of willing early adopters — confirm the registration prompt behaves as expected and that people can actually complete a self-service reset, then widen the required group in stages over a few weeks. Set a firm registration deadline, communicate it plainly (what it is, why it's changing, that it takes two minutes), and chase the stragglers directly rather than assuming a company-wide email will get everyone there. Businesses that skip the staged approach tend to get a flood of help desk calls from confused users on the day everyone is forced through the prompt at once — which is precisely the outcome the feature is meant to prevent.
What changes in a hybrid environment with on-premises Active Directory?
If user accounts are synchronised from an on-premises Active Directory into Microsoft Entra ID — a hybrid setup, common in businesses that have grown up around an on-site server — a cloud password reset through SSPR doesn't automatically flow back to update the on-premises password unless password writeback is switched on. Without writeback, a user resets their cloud password, and their on-premises password (which may still gate access to file shares or other on-site systems) stays exactly as it was, which is confusing at best and a support call at worst.
Password writeback is configured through Microsoft Entra Connect, the synchronisation tool that links the on-premises directory to the cloud tenant, and it's this piece — not SSPR itself — that tends to need a specific Microsoft Entra ID licence tier. For any business running hybrid identity, writeback should be treated as a required part of the SSPR rollout rather than an optional extra: turning on SSPR without it means the feature only half-works, and the gap is exactly the kind of detail that surfaces as a confusing failure at the worst possible time.
How do you know whether it's actually reducing password calls?
The whole point of SSPR is fewer help desk interruptions, so it's worth measuring rather than assuming. Two numbers matter. The first is registration coverage — what proportion of active users have actually completed authentication method registration, visible in Microsoft Entra ID's usage and insights reporting. A rollout sitting at 40% registered six months in isn't doing its job, whatever the enablement setting says. The second is the trend in password-related tickets logged with the help desk, tracked before and after rollout. If registration is high and password tickets haven't moved, something in the rollout — usually discoverability, or a registration flow people found confusing — needs fixing, not the feature itself.
The SSPR setup checklist
- 1Decide the scope: a security group for a staged rollout, widening to all users once the pilot is proven.
- 2Choose authentication methods — Authenticator app and mobile phone as the defaults, security questions avoided — and set how many are required to register and to reset.
- 3If the environment is hybrid, configure password writeback through Microsoft Entra Connect before rolling SSPR out, so cloud resets actually reach the on-premises password.
- 4Enable combined MFA and SSPR registration so users complete both in one interruption rather than two.
- 5Pilot with IT and a small willing group, confirm the registration prompt and a real reset both work end to end.
- 6Widen to the rest of the business in stages, with a firm registration deadline and direct follow-up for stragglers.
- 7Track registration coverage and the trend in password-reset tickets logged with the help desk, and treat a rollout under roughly 80% registered as unfinished.
Set up properly, SSPR turns the most common help desk interruption there is into something a user handles from their phone in under a minute, at any hour, without waiting on anyone. Set up and forgotten, it's a checkbox in the admin centre that a handful of people have registered for and nobody else knows exists.