SSPR

Self-service password reset (SSPR) lets users reset their own Microsoft 365 passwords without help-desk involvement. Users verify identity using registered authentication methods — Microsoft Authenticator, mobile phone, alternate email, security questions — then set a new password. For hybrid environments, password writeback (configured in Entra Connect or Entra Cloud Sync) syncs the new password back to on-premises Active Directory. Available in all Entra ID tiers for cloud-only accounts; password writeback requires Entra ID P1 (included with Microsoft 365 Business Premium, E3, E5). Combined with combined registration, SSPR and MFA share the same registered methods, registered once.

Why it exists as a distinct feature

Before SSPR, "I forgot my password" was reliably one of the top-two reasons for help-desk contact at almost every organisation, and the traditional fix — a help-desk agent verifying identity by voice and manually resetting the password — is itself a well-known social-engineering target: attackers impersonate employees over the phone specifically to get a help-desk agent to reset a password for an account they don't control. SSPR removes both problems at once: the reset happens without a human in the loop, using the same strong registered methods that back MFA, so the verification step is at least as strong as a normal sign-in rather than weaker.

Worked example

A tenant sets its SSPR policy to require two of three registered methods (Authenticator notification, phone call, or security questions) before allowing a reset, and enables password writeback. An employee forgets their password on a Monday morning, goes to the SSPR portal, approves a push notification in Microsoft Authenticator and confirms an alternate email code, then sets a new password. Because writeback is enabled, that password is synchronised back to the on-premises Active Directory account within seconds via the same Entra Connect (or Cloud Sync) channel used for the reverse direction, so the employee can immediately use the new password to unlock their domain-joined laptop — without writeback, the cloud password and on-prem password would diverge, and the employee would still need a help-desk reset for the on-prem side.

Registration policy is the real lever

SSPR's actual security depends entirely on how many methods are required at registration and reset time, not on the feature being "on." A tenant that allows a single security question as the sole reset method has effectively no meaningful protection — the questions are frequently guessable or discoverable from public information. The standard hardening is requiring two independent methods at reset, excluding security questions from admin accounts entirely, and pairing SSPR with a Conditional Access policy that requires a compliant device or trusted location before the reset portal is even reachable, for higher-risk populations.

Common pitfalls

The most frequent adoption blocker is skipping the registration campaign — SSPR only works for users who have registered methods in advance, so a tenant that enables the policy without a mandatory registration period (commonly enforced by Conditional Access requiring registration within a grace window) finds most users still can't self-serve when they actually need to, because nobody registered ahead of time. The second is forgetting that combined registration means an SSPR method change can affect MFA and vice versa — since Entra ID stores one shared method set per user, disabling a "weak" method for SSPR purposes also removes it as an MFA option.