9.2 Self-Service Password Reset (SSPR)

Quick Answer: SSPR lets users reset their own forgotten passwords from any browser or the Windows sign-in screen, without calling the helpdesk. Enable it in Entra admin center → Protection → Password reset, choose who can use it, and pick how many methods (1 or 2) they must prove at reset time. With Entra Connect password writeback, hybrid users can reset their on-prem AD password too.

What SSPR Solves

Password resets are consistently one of the top helpdesk call drivers—often 20–40% of all support tickets. Self-Service Password Reset (SSPR) lets users reset a forgotten password themselves after proving identity through pre-registered authentication methods. The result is faster recovery for users and lower support cost for the org, especially outside business hours when helpdesk staffing is thin.

Configuring SSPR

In the Microsoft Entra admin center, navigate to Protection → Password reset → Properties to enable SSPR. You choose:

• Enabled for: All users, Selected users (pick a group), or None. A staged rollout to a pilot group is the standard best practice before going tenant-wide.
• Number of methods required to reset: 1 or 2. Requiring two methods is more secure; requiring one maximizes usability. Microsoft caps the reset requirement at two.

On the Authentication methods blade you select which methods are available for reset:

• Email notification
• Mobile phone (SMS or voice)
• Office phone (voice)
• Security questions (you define the pool; the user registers 3–5 if enabled)
• Microsoft Authenticator app notification
• Microsoft Authenticator app code (OTP)
• FIDO2 security key (when combined registration is used)

The number of methods available must be greater than or equal to the number required. If you require two methods, users register at least two and prove any two during a reset.

The Register-vs-Reset Trap

A frequent MS-102 trap is conflating what a user registers with what they must prove. The SSPR blade exposes a single "Number of methods required to reset" setting, and its only valid values are 1 or 2. There is no separate "number of methods required to register" slider for methods generally — the closest thing is the security-questions pair (number of questions required to register and to reset, each 3–5). The practical rule: a user must have at least as many registered methods as the reset requirement, but may register more, and only the required number is challenged at reset time.

Registration Campaign

Users are prompted to register at sign-in when "Require users to register when signing in?" is set to Yes. A registration campaign nudges unregistered users with reminders within a set number of days. Skipping this leads to lower registration coverage and more failed resets—always verify registration coverage before going live.

Security Questions — Best Practices

Microsoft discourages security questions because answers are often guessable or socially discoverable, and they contribute to reset failures and helpdesk escalations. As of March 2027, security questions will be retired from SSPR entirely; plan now to move users to Authenticator and FIDO2. If you still enable them in the interim, the user must register 3–5 questions from your custom pool, and administrator accounts cannot use security questions at all. Treat questions as a last-resort method behind Authenticator and phone.

---

Combined Registration

With combined registration enabled (the default for new tenants), users register their security info once at aka.ms/mfasetup. The same registered methods satisfy both SSPR and MFA (Multifactor Authentication). This is the recommended model because it avoids double registration and reduces confusion.

Without combined registration (legacy mode), SSPR registration and MFA registration are separate, users register twice, and admins manage two registries. Microsoft recommends moving every tenant to combined registration.

The Microsoft Authenticator app is the strongest method here: it supports passwordless phone sign-in, TOTP codes, and number-matching push notifications. A single registration entry can satisfy SSPR proof, an MFA challenge, and passwordless sign-in.

SSPR and the Authentication Methods Policy

The Authentication Methods Policy (Protection → Authentication methods → Policies) is the centralized control plane for allowed methods. As of September 30, 2025, Microsoft retired the ability to manage authentication methods in the legacy per-user MFA and SSPR policies—the Authentication Methods Policy is now where methods are enabled per group and where method-specific settings live: Authenticator authentication mode, geolocation and application context in push notifications, Temporary Access Pass lifetime, and FIDO2 key restrictions (AAGUIDs). Number matching is not among them — it is enforced tenant-wide and cannot be disabled. Migration is reversible through three states: Pre-migration, Migration in Progress, and Migration Complete.

Conditional Access does not gate SSPR directly. But the methods registered for SSPR are the same ones a Conditional Access policy can require as a grant control. Tightening CA to require Authenticator push without ensuring users have it registered breaks both SSPR and sign-in.

---

Password Writeback for Hybrid Environments

For users synced from on-premises AD (Active Directory), SSPR can reset the on-prem AD password—not just the cloud credential—through password writeback. Requirements:

• Entra Connect Sync or Entra Connect Cloud Sync deployed with Password Hash Sync (PHS) or Pass-Through Authentication (PTA)
• Password writeback enabled in the Connect configuration
• The user must be a synced (hybrid) identity—cloud-only users reset their cloud password directly, no writeback needed
• Entra ID P1 or P2 licensing assigned to the user

When a hybrid user completes SSPR, Entra ID writes the new password back to on-prem AD through the Connect sync agent, even if the on-prem environment is otherwise unreachable from the user's browser.

Network requirements: the Connect server must reach *.servicebus.windows.net and *.passwordreset.microsoftonline.com over TCP 443 (primary), with TCP 5671 (AMQP) and TCP 9350–9354 (Service Bus relay) also documented for Connect Health and event 32011 troubleshooting. Firewalls blocking these cause silent writeback failure—users see "We couldn't contact your on-premises environment."

Writeback troubleshooting: beyond connectivity, common causes are (1) the AD DS service account lacks Reset Password and Write permission on the user's OU; (2) password complexity rejection—violates an on-prem fine-grained password policy (event 6329, source ADSync, error 0x80230619); (3) the user object is filtered from sync scope; (4) reserved characters in OU paths. Check event log IDs 6329 (ADSync source) and 33001 (PasswordResetService source) on the Connect server.

---

SSPR from the Windows Sign-In Screen

On Microsoft Entra joined or hybrid Entra joined Windows 10 (v1803+) and Windows 11 devices, users can trigger SSPR directly from the lock screen by clicking Reset password. This requires:

• SSPR enabled and the user registered
• Device is Entra joined or hybrid joined—not Entra registered-only
• The reset link is not hidden by Intune policy (the OMA-URI ./Device/Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset must be allowed)
• For hybrid-joined devices, the user needs line-of-sight to a domain controller (VPN or on-prem network) to use the new password after reset

This is a high-impact feature for helpdesk reduction because most password reset requests come from users sitting at a locked screen.

---

Delegated Administration

Global Administrators aren't the only staff who manage SSPR. Relevant delegated roles:

For least privilege, assign Password Administrator (optionally scoped to an Administrative Unit) to tier-1 helpdesk—don't grant Global Administrator just to clear SSPR registration. None of these roles can reset credentials for members or owners of role-assignable groups except Privileged Authentication Administrator.

Reporting and Usage

Admins monitor SSPR through two blades: Protection → Password reset → Registration (how many users are registered, which methods they registered) and Protection → Password reset → Usage (reset and unlock events, success/failure, method used). Microsoft Graph also exposes authenticationMethod and password reset activity reports for programmatic monitoring and alerting. A weekly audit of "failed reset" rows often reveals users who never registered enough methods.

---

Licensing

SSPR is included with:

• Microsoft Entra ID P1 and P2
• Microsoft 365 Business Premium (includes Entra ID P1)
• Microsoft 365 E3 (includes Entra ID P1) and E5 (includes Entra ID P2)
• Any plan that bundles Entra ID P1 or higher

Without Entra ID P1/P2, cloud-only users get a limited free SSPR tier (cloud users only, no writeback, no custom questions). For any real deployment, P1 is the practical floor—writeback and custom questions both require it.

Worked Scenario

A pilot group reports "the reset button is missing from the Windows sign-in screen." Investigation: their devices are Entra registered, not joined. Fix: rejoin the devices via Intune (or point users to aka.ms/sspr in the browser as a workaround). A second wave of failures traces to the Connect server's egress proxy blocking *.servicebus.windows.net; after the firewall team opens the endpoints, writeback succeeds. Remaining failures are fine-grained password policy rejections—event 6329 on the Connect server—resolved by aligning cloud complexity rules with the on-prem PSO.