Episode 6 — Self-Service Password Reset (SSPR)

In Episode 5 you opened your tenant to the outside world with Microsoft Entra B2B — invitations, #EXT# guest objects, and the two control planes that govern cross-tenant access and invitations. Now we close Part I on identity with the feature that keeps all those users out of your helpdesk queue: letting them reset their own passwords.

Learning objectives

Describe the SSPR reset flow step by step, including every gate a user must pass.
Configure SSPR for a pilot group: enablement, authentication methods, registration, notifications, and customization.
Distinguish the end-user SSPR policy from the separate administrator reset policy.
Predict user experience from the methods-registered vs methods-required matrix.
Explain the hybrid requirements: password writeback, licensing, and the federated-user sync delay.

Why it matters

Password resets are among the most common — and most expensive — helpdesk tickets. Self-service password reset (SSPR) lets users change, reset, or unlock their own account with no administrator or helpdesk involvement, which directly reduces helpdesk calls and lost productivity. For the AZ-104 exam, SSPR is a named skill: you must know the enablement options, the authentication methods, the licensing boundaries (especially writeback), and the subtle but heavily tested difference between how SSPR treats end users and administrators.

What SSPR gives users

A user interacts with SSPR at two URLs, and it pays to memorize both:

URL	Purpose
https://aka.ms/ssprsetup	Register (or update) authentication methods
https://aka.ms/sspr	Reset, change, or unlock the account

If a user forgets their password or locks themselves out, they follow the prompts at the reset portal and unblock themselves — provided they pass every gate described next.

How the reset flow works

When a user reaches the SSPR portal, Microsoft Entra ID first handles page localization, then checks whether the account is valid, which organization it belongs to, and where the password is managed. Only then does it evaluate the SSPR gates:

Is SSPR enabled for this user? If not — contact your administrator.
Has the user registered the right authentication methods per the administrator policy? If the policy requires one method, the user needs data for at least one enabled method; if it requires two methods, at least two. (Accounts holding an Azure administrator role are instead held to the strong two-gate policy — more on that below.)
Is the password managed on-premises (federated, pass-through authentication, or password hash synchronization)? If yes, password writeback must be configured — otherwise the user is told to contact their administrator.

If every check passes, the user is guided through the reset or change.

🧠 Mnemonic: the gate sequence is E-R-M-W — Enabled → Registered → Methods enough → Writeback (if hybrid). Remember it as "Every Reset Must Work."

Enabling SSPR: None, Selected, All

In the Microsoft Entra admin center, browse to Entra ID > Password reset. On the Properties page, Self service password reset enabled offers three values:

Setting	Who can use SSPR
None	Nobody (default off state; also how you disable SSPR)
Selected	Members of one Microsoft Entra group chosen in the admin center
All	All end users in the tenant

Two practical notes on Selected: the admin center lets you pick only one group, and — useful for wider rollouts — SSPR supports nested groups here.

The administrator nuance. This Properties setting governs end users only. Administrator accounts are governed by a separate administrator reset policy that Microsoft enforces for them: a strong two-gate policy requiring two authentication methods, regardless of what you configure for end users. The Microsoft docs describe this from two angles that look contradictory (SSPR "isn't enabled for administrators" vs "enabled by default for admins"); the reconciled view is exactly this split — your None/Selected/All switch never applies to admins, who always fall under the stricter two-gate policy. Consequence: always test SSPR with a non-administrator account, otherwise you are testing the wrong policy.

Authentication methods

On the Authentication methods page you choose how many methods a user must supply and which methods are available. Users can only reset with a method the administrator enabled. The SSPR methods are:

Microsoft Authenticator push notifications
Hardware OATH tokens (preview)
Software OATH tokens
SMS
Voice call
Email OTP

(Note: since September 30, 2025, authentication methods can no longer be managed in the legacy MFA/SSPR policies — tenants use the centralized Authentication methods policy, migrated via the manual migration control.)

Number of methods required to reset is one or two. What the mobile app can do depends on that number (for tenants not yet migrated to the centralized policy):

Methods required to reset	Mobile app features available
One	Code
Two	Code or Notification

The exam-favorite matrix — can the user actually reset?

Methods registered	Methods required	Result
1 or more	1	Able to reset or unlock
1	2	Unable to reset or unlock
2 or more	2	Able to reset or unlock

A user below the minimum sees an error page and must request an administrator reset. Also beware: removing available methods from the policy can silently push registered users below the minimum. And one special rule: Authenticator can't be selected as the only method when only one method is required — pair it with at least one additional method (or at least two, when two are required).

Registration and reconfirmation

On the Registration page:

Require users to register when signing in — prompts users to complete SSPR registration when they sign in with modern authentication or a browser (Microsoft 365, the admin center, federated or custom apps). Users can dismiss the prompt, but it reappears at every sign-in until they register; it is shown once per interactive session and doesn't break an existing session. Without this setting, users can still self-register at aka.ms/ssprsetup.
Number of days before users are asked to reconfirm their authentication information: 0 to 730 days, where 0 means never. (Only available when registration at sign-in is required.)

Notifications and customization

On the Notifications page:

Notify users on password resets — the user gets an email (primary and alternate addresses, falling back to UPN) whenever their password is reset. A cheap phishing/abuse tripwire.
Notify all admins when other admins reset their passwords — Global Administrators receive an email when another administrator resets via SSPR. Turn this on.

On the Customization page you can replace the generic "contact your administrator" dead-end: set Customize helpdesk link to Yes and provide a custom helpdesk email or URL (e.g. https://support.contoso.com/).

Hybrid environments: writeback and its quirks

If passwords are mastered on-premises (federation, pass-through authentication, or password hash synchronization), SSPR must push the new password back via password writeback (configured with Microsoft Entra Connect / cloud sync):

Write back passwords to your on-premises directory = Yes: federated, PTA, and PHS users can reset. Set to No, those users can't reset at all.
Allow users to unlock accounts without resetting their password: with Yes, a user can unlock the on-premises account without being forced to change the password.
Federated users wait up to ~2 minutes after "Your password has been reset": the source of authority is on-premises, and password hash sync back to Microsoft Entra ID runs on a 2-minute schedule.
SSPR shows only the cloud password policy — Entra Connect and cloud sync don't share on-premises password policy details with the cloud, which is also why users with synchronized writeback don't see a password strength indicator.
On-premises, SSPR behaves like an admin-initiated password reset; third-party password filters must be configured for that scenario (Microsoft Entra password protection for AD DS works by default).

Licensing. The edition table lists base SSPR as available across editions — SSPR capabilities vary by license — but the exam-critical line is: SSPR with on-premises writeback requires Microsoft Entra ID P1 or P2. The official deployment tutorial itself lists at least P1 as a prerequisite, which is what you should assume for a full end-user SSPR rollout.

Capability	Free	P1	P2
SSPR (cloud)	✅	✅	✅
SSPR with writeback (hybrid)	—	✅	✅

Deploying it: the tutorial in one paragraph

The reference rollout, condensed: sign in as at least Authentication Policy Administrator; Entra ID > Password reset > Properties, set Selected and pick the pilot group (e.g. SSPR-Test-Group); Authentication methods: number required = 2, methods = mobile app notification, mobile app code, email, mobile phone; Registration: require at sign-in = Yes, reconfirm after 180 days; Notifications: both toggles Yes; Customization: helpdesk link to your support portal. Then test with a non-administrator user: register at aka.ms/ssprsetup in a private browser window, then reset at aka.ms/sspr (account + CAPTCHA, then verification). To roll back, set the Properties value to None.

B2B recall (Episode 5): password reset and change are fully supported on all B2B configurations — guests from a partner Entra tenant follow their home tenant's SSPR policy, and self-service sign-up or invited B2B users reset with the email they registered. The exception: personal Microsoft accounts (Hotmail.com, Outlook.com…) granted guest access can't use Microsoft Entra SSPR.

Exercises

Exercise 6.1 — Enable SSPR for a pilot group

In a trial tenant (Entra ID P1), enable SSPR end to end for a group SSPR-Test-Group containing one non-administrator user testuser: two methods required, registration enforced at sign-in with a 180-day reconfirmation, both notifications on, and a custom helpdesk link. Then run the user test.

Solution

Sign in to the Microsoft Entra admin center (https://entra.microsoft.com) as at least Authentication Policy Administrator.
Entra ID > Password reset > Properties: set Self service password reset enabled to Selected, choose No groups selected, pick SSPR-Test-Group, Select, then Save.
Authentication methods: Number of methods required to reset = 2; methods = Mobile app notification, Mobile app code, Email, Mobile phone; Save.
Registration: Require users to register when signing in = Yes; reconfirmation days = 180; Save.
Notifications: Notify users on password resets? = Yes; Notify all admins when other admins reset their password? = Yes; Save.
Customization: Customize helpdesk link = Yes; enter e.g. https://support.contoso.com/; Save.
Test — in an InPrivate/incognito window, go to https://aka.ms/ssprsetup, sign in as testuser, register the methods, select Looks good. In a new InPrivate window, go to https://aka.ms/sspr, enter the account and CAPTCHA, complete verification, and reset. testuser receives the notification email.
Cleanup: set the Properties value back to None and Save.

Key check: the test account must be a non-administrator — admin accounts follow the separate two-gate policy, not your configuration.

Exercise 6.2 — One method registered, two required

Policy: Number of methods required to reset = 2, available methods = Authenticator (notification/code), SMS, email OTP. User Dana registered only her mobile phone for SMS months ago. Today she tries aka.ms/sspr. What happens, and what are two ways to unblock her?

Solution

Dana hits the methods gate: 1 method registered with 2 required = unable to reset or unlock. She sees an error page and must request an administrator reset.

Ways to unblock:

Have Dana complete registration at https://aka.ms/ssprsetup (an admin resets her password first so she can sign in), adding a second method such as email OTP or the Authenticator app. Enabling Require users to register when signing in plus a reconfirmation period (0–730 days) prevents the drift long-term.
Lower the policy to one method — usually the wrong call for security, and remember the constraint: Authenticator can't be the only method when one method is required, so at least one additional method must stay enabled.

Exercise 6.3 — The federated two-minute mystery

A federated user resets their password through SSPR, sees "Your password has been reset," but the new password fails at the next sign-in attempt 30 seconds later. It works after two minutes. Explain the mechanism — and name the setting that made the reset possible at all.

Solution

For federated (and PTA/PHS) users, the source of authority is the on-premises directory. SSPR performs the equivalent of an admin-initiated password reset in Active Directory via password writeback; the new password then flows back to Microsoft Entra ID through password hash synchronization, which is scheduled every 2 minutes. Until that sync runs, cloud sign-in still validates against the old hash — hence the wait of up to ~2 minutes.

The prerequisite setting is Write back passwords to your on-premises directory = Yes (Microsoft Entra Connect / cloud sync), which requires Microsoft Entra ID P1 or P2. Without it, the on-premises gate would have told the user to contact their administrator instead.

Key takeaways

SSPR lets users change, reset, or unlock their account at aka.ms/sspr, after registering methods at aka.ms/ssprsetup — fewer helpdesk calls.
The reset flow gates are E-R-M-W: SSPR enabled → methods registered → enough methods for the policy (1 or 2) → writeback if the password is managed on-premises.
Enablement is None / Selected / All; Selected takes one group in the admin center and supports nested groups.
The None/Selected/All switch governs end users only; administrators always fall under a separate strong two-gate policy (two methods) — so test with a non-admin account.
1 registered / 2 required = unable; the Authenticator app can't be the only method when one method is required.
Registration at sign-in interrupts once per interactive session without breaking it; reconfirmation runs every 0–730 days (0 = never).
SSPR with writeback requires P1/P2; federated users wait up to 2 minutes for the new password to sync back; only the cloud password policy is displayed.
Least-privilege role to configure SSPR: Authentication Policy Administrator.

Quick recall

Q: A user has registered only SMS, and the SSPR policy requires two methods. What happens at aka.ms/sspr? A: They see an error page and must request an administrator reset — 1 registered with 2 required = unable.

Q: You set Self service password reset enabled to None. Can a Global Administrator still reset their password through SSPR? A: Yes — administrators are governed by a separate administrator reset policy (strong two-gate, two methods), not by the None/Selected/All end-user setting.

Q: Scenario: Contoso is hybrid with password hash synchronization. Users on the pilot group pass every check but are told to contact their administrator. Most likely cause? A: Password writeback isn't configured/enabled — required for federated, PTA, and PHS users. Also verify the tenant has P1 or P2, which writeback requires.

Q: Which role is the least-privileged one to enable and configure SSPR in the admin center? A: Authentication Policy Administrator.

Q: A federated user completes a reset but can't sign in with the new password for a minute or two. Why? A: The source of authority is on-premises; password hash sync back to Microsoft Entra ID runs every 2 minutes.

Q: How many groups can you enable for SSPR in the admin center, and do nested groups count? A: One group via the admin center; nested groups are supported for wider deployments.

Coming up

That wraps Part I — identity. In Episode 7 we cross into Part II and Azure's authorization engine: Azure RBAC, where security principal + role definition + scope = role assignment, permissions are additive, deny assignments trump everything, and we trace the full evaluation flow ARM runs on every request.