Self-Service Password Reset (SSPR) in Microsoft Entra ID, Formerly Azure AD

Self-Service Password Reset (SSPR) in Microsoft Entra ID, Formerly Azure AD

Originally published 16 October 2020 · Reviewed 5 November 2026

Self-service password reset (SSPR) lets people recover their own account without raising a ticket. It is one of the quickest ways to cut password-related help desk work, and it is a security control as well, because it replaces phone calls where staff reset passwords after weak identity checks. This guide covers how it works in Microsoft Entra ID, which was called Azure Active Directory until 2023, what it needs, and a sensible rollout.

What users get

A user who forgets a password, or whose account is locked, goes to the password reset page, proves their identity with registered methods, and chooses a new password. A user who knows the current password can also change it from their account page. Administrators decide which users are in scope, how many methods are required, and which methods are allowed, and can review reset and registration activity in the logs.

Authentication methods for reset

Microsoft documents which methods can be used for password reset. In current guidance these include the Microsoft Authenticator app, software or hardware OATH tokens, SMS, voice call and email one-time passcode. Methods differ in strength, and the same trade-offs that apply to MFA apply here: a text message is easy to deploy but easy to phish, so allow it only if you must. Requiring two methods for reset is a reasonable default for most staff, and for administrator accounts the policy for password reset follows separate, stricter rules set by Microsoft.

Because the reset flow and MFA use the same registration, Microsoft recommends combined registration, so users set up both once.

Hybrid environments and password writeback

If your users live in on-premises Active Directory and synchronise to Microsoft Entra ID, a password reset in the cloud must reach the directory where the password is actually held. Password writeback does that through Microsoft Entra Connect. Without it, the user would reset a cloud password that the on-premises directory never receives. Microsoft's licensing page lists SSPR for cloud users in the free tier and SSPR with writeback as needing Microsoft Entra ID P1 or higher.

Writeback needs permissions for the Connect account on the relevant organisational units, and outbound connectivity from the Connect server to the Microsoft service. Your on-premises password policy still applies, so a cloud reset can fail when the new password violates local complexity or history rules. Test with a pilot user who is in each organisational unit you plan to cover.

Licensing in plain words

• Cloud-only users can use SSPR with the free tier.
• Writeback to on-premises Active Directory needs Entra ID P1 or higher, which Microsoft 365 Business Premium and E3 include.
• Licences are per user, and group-based licensing keeps the list manageable.

Check Microsoft's current licensing page, since feature placement can change.

Rollout plan

1. Decide the scope. Start with a pilot group, such as the IT team and a friendly department.
2. Choose methods. Prefer the Authenticator app and OATH tokens. Allow phone-based methods only where needed.
3. Combine registration with MFA. Ask users to register once, using the combined experience, and give them a deadline.
4. Enable writeback for hybrid users. Configure it in Microsoft Entra Connect, test a reset, and confirm the on-premises password changed.
5. Communicate. Tell staff what will happen, where to go to reset, and what to do if they have no registered method.
6. Prepare the exception path. Decide how the help desk verifies identity for people who cannot self-serve, and avoid ad hoc phone resets.
7. Review the logs. Check the audit logs for failed attempts, odd locations and accounts that never registered, and tune the policy.

Security considerations

SSPR can become an attack path if the weakest allowed method is weak. Attackers who control a phone number or a mailbox can try to reset an account. Reduce that risk by requiring two methods, limiting SMS and email, applying Conditional Access to the registration step so it happens from trusted conditions, and monitoring the reset logs. Combine SSPR with password protection so that new passwords are not on a list of common choices.

Common problems

• Users who never registered. SSPR cannot help them. Report on registration and chase the gaps.
• Writeback errors. Usually permissions on the account that Connect uses, or on-premises policy that rejects the password.
• Locked-out administrators. Keep emergency access accounts, as described in Microsoft's guidance, and do not rely on SSPR alone for them.
• Confusion about where to reset. Put the reset link on your intranet and in the sign-in help text.

Measuring whether it works

Pick two or three numbers before the rollout and look at them again after a month: how many password-related tickets you receive each week, what share of users have registered two methods, and how many resets complete without help desk involvement. If registration is low, the feature cannot help, so follow up with managers, not only with users. If tickets do not fall, read the sign-in and audit logs to see where people give up, and fix the instructions or the allowed methods. Record the baseline so that you can show the change to whoever pays for the licences.

Microsoft references

• How self-service password reset works, reviewed 5 November 2026.
• Password writeback and self-service password reset, reviewed 5 November 2026.
• Microsoft Entra licensing, reviewed 5 November 2026.

This article was first published on 16 October 2020. It was rewritten on 5 November 2026 with current product names. Microsoft's live documentation takes precedence if it has changed.