Agent Foskett Academy • Microsoft Entra • Module 2 • Lesson 17

Lesson 17 — Self-Service Password Reset in Microsoft Entra

A forgotten password should not automatically become a helpdesk ticket.

Microsoft Entra Self-Service Password Reset allows users to reset or change their own password after securely verifying their identity with registered authentication methods. In hybrid environments, password writeback can return the new password to on-premises Active Directory in real time.

This lesson explains SSPR scope, combined registration, verification methods, password writeback, reporting, rollout planning and the investigation steps Agent Foskett follows when password recovery fails or appears suspicious.

Secure recovery must verify the user without creating an easier path for an attacker.

Start Lesson Back to Microsoft Entra Academy

Agent Foskett Microsoft Entra Self-Service Password Reset lesson

What you will learn

This lesson explains how Microsoft Entra enables secure password recovery and hybrid password writeback.

SSPR configuration

Combined registration

Password writeback

Recovery investigation

Learning objectives

After completing this lesson, you should be able to explain, configure and investigate Microsoft Entra Self-Service Password Reset.

Describe the SSPR user experience and verification process.
Scope SSPR to appropriate users and groups.
Configure authentication methods and registration requirements.
Explain combined MFA and SSPR registration.
Describe password writeback for hybrid identities.
Use audit and registration reports to troubleshoot recovery.

The problem this solves

Forgotten passwords, locked accounts and expired credentials interrupt work and generate repetitive support requests.

SSPR restores access through a controlled identity-verification process without requiring an administrator to manually reset every password.

What is Self-Service Password Reset?

Microsoft Entra Self-Service Password Reset allows an eligible user to change or reset their password after successfully proving control of the required registered verification methods.

User cannot sign in ↓ Opens the password reset experience ↓ Microsoft Entra identifies the account ↓ SSPR scope and registration are checked ↓ User completes required verification ↓ New password is validated against policy ↓ Cloud password is updated ↓ Hybrid password is written back when configured

Password change vs reset

A password change normally occurs when a user knows the existing password and replaces it with a new one.

A password reset is used when the existing password is forgotten, expired or unavailable and stronger identity verification is required.

SSPR scope

SSPR can be enabled for no users, selected groups or all eligible users.

A staged rollout should begin with a pilot group so registration, licensing, authentication methods and support processes can be validated.

SSPR configuration areas

Configuration area	Purpose	Operational question
Properties	Defines which users are enabled for SSPR.	Is the affected user actually in scope?
Authentication methods	Defines which verification methods may be used and how many are required.	Has the user registered enough permitted methods?
Registration	Controls whether users must register when signing in and how often information is reconfirmed.	Is the user's security information current?
Notifications	Controls user and administrator notifications after password-reset activity.	Would an unexpected reset be noticed quickly?
Customisation	Supports helpdesk links and organisational guidance.	Can users reach trusted assistance safely?
On-premises integration	Controls password writeback for synchronised identities.	Can the cloud reset reach Active Directory?

Verification methods

Available SSPR methods can include Microsoft Authenticator notifications or codes, mobile phone, office phone, email and security questions, depending on tenant configuration and account type.

Organisations should favour methods that provide strong assurance and avoid unnecessary dependence on easily redirected channels.

Number of methods required

Administrators can require one or two verification methods for reset.

Requiring two methods improves assurance but only works when users have enough usable methods registered and recovery support has been planned.

Combined registration

Combined security-information registration allows users to register methods once for both multifactor authentication and SSPR.

This creates a simpler user experience and gives administrators a more consistent view of authentication readiness.

Registration prompts

Users can be required to register security information during sign-in and periodically reconfirm it.

Registration campaigns should be communicated clearly so users recognise legitimate prompts and report unexpected requests.

Registration readiness workflow

SSPR pilot group created ↓ Approved verification methods enabled ↓ Combined registration communicated ↓ Users register and verify methods ↓ Registration reports reviewed ↓ Helpdesk and recovery process tested ↓ SSPR enforcement expanded in stages

Password policy evaluation

The replacement password must satisfy the password policy that applies to the account.

Weak, prohibited or non-compliant passwords are rejected and the user must choose another value.

Password protection

Microsoft Entra Password Protection can block commonly used and organisation-specific weak passwords.

SSPR should be paired with password protection so recovery does not result in an easily guessed credential.

Hybrid password writeback

Password writeback allows a password changed or reset in Microsoft Entra to be written back to an on-premises Active Directory environment through Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync.

User completes SSPR in Microsoft Entra ↓ New password passes cloud policy checks ↓ Password writeback service processes the request ↓ Microsoft Entra Connect or Cloud Sync communicates securely ↓ On-premises Active Directory applies its password policy ↓ Password is updated in Active Directory ↓ User signs in to cloud and on-premises resources

Writeback prerequisites

Supported Microsoft Entra licensing.
A configured synchronisation platform.
Password writeback enabled in the synchronisation configuration.
On-premises integration enabled in Microsoft Entra.
Required Active Directory permissions delegated to the connector account.
Network and service health confirmed.

Why writeback fails

The user is not a synchronised identity.
Password writeback is not enabled in both required locations.
The connector account lacks permissions.
The new password violates on-premises policy.
The synchronisation agent or service is unhealthy.
The targeted domain or organisational unit is misconfigured.

Notifications

Users can be notified when their password is reset, helping expose activity they did not initiate.

Administrators may also be notified when privileged accounts complete SSPR, providing extra visibility over high-impact identities.

Custom helpdesk link

The reset page can direct users to an approved organisational support location.

Use a trusted internal or public support destination and avoid instructions that encourage users to disclose passwords or verification codes.

Reporting and audit evidence

Evidence source	What it shows	Investigation value
Audit logs	Password reset, password change, registration and administrative configuration events.	Confirms who initiated an action, when it occurred and whether it succeeded.
Authentication methods activity	Method registration and usage across the organisation.	Identifies users without recovery-ready methods and unexpected registration patterns.
Sign-in logs	Sign-in attempts before and after recovery.	Connects password-reset activity to IP address, location, device, application and risk.
Provisioning or sync health	Connector and synchronisation status.	Helps isolate hybrid writeback failures.
Identity Protection	Risky-user and risky-sign-in detections.	Determines whether the reset followed suspicious activity.

Important registration change

From 7 September 2026, SSPR is scheduled to accept only authentication methods that users explicitly register.

Organisations should review registration reports and ensure users do not depend solely on directory-sourced contact properties.

Emergency access

Emergency-access accounts should not depend on the same recovery path as normal users.

Protect them with strong methods, documented controls, continuous monitoring and a tested break-glass process.

Recommended rollout process

1. Review licensing and identity architecture ↓ 2. Select secure SSPR methods ↓ 3. Configure a pilot group ↓ 4. Enable combined registration ↓ 5. Register and test pilot users ↓ 6. Configure notifications and support guidance ↓ 7. Enable and test hybrid writeback if required ↓ 8. Review audit, registration and failure reports ↓ 9. Expand deployment in controlled stages ↓ 10. Monitor reset activity and method changes

Agent Foskett investigation: “Password reset is not working”

1. Confirm the user's identity and account type ↓ 2. Check whether the user is licensed and in SSPR scope ↓ 3. Review registered verification methods ↓ 4. Confirm the required number of methods can be satisfied ↓ 5. Review the exact error and reset stage ↓ 6. Check password policy rejection ↓ 7. For hybrid users, verify writeback and connector health ↓ 8. Review audit logs for success or failure details ↓ 9. Check sign-in and risk events around the attempt ↓ 10. Correct the configuration without bypassing identity verification

Suspicious reset indicators

A reset immediately follows unfamiliar sign-in activity.
New authentication methods were registered shortly before recovery.
The source IP address or country is unusual.
A privileged account resets unexpectedly.
Repeated verification attempts occur across several accounts.
The user denies initiating the reset.

Immediate containment

Revoke active sessions.
Reset the password through a verified process.
Remove unrecognised authentication methods.
Review inbox rules, OAuth grants and privileged activity.
Confirm device and sign-in risk.
Preserve audit and authentication evidence.

Real-world scenario: the cloud reset succeeded, but Windows still rejected the password

1. A synchronised user completes SSPR successfully ↓ 2. Microsoft Entra accepts the new password ↓ 3. The user attempts to sign in to an on-premises device ↓ 4. Active Directory rejects the new password ↓ 5. Agent Foskett reviews SSPR audit events ↓ 6. Password writeback is found to be disabled ↓ 7. Writeback permissions and configuration are corrected ↓ 8. A controlled test confirms the password reaches Active Directory ↓ 9. Cloud and on-premises access now use the same credential

Common mistakes

Mistake	Impact	Better practice
Enabling SSPR without registration	Users reach the reset page but cannot prove their identity.	Complete combined registration before broad rollout.
Using weak verification options only	Account recovery becomes easier to abuse.	Prioritise strong, well-managed methods.
Assuming cloud reset updates Active Directory automatically	Hybrid users may have different cloud and on-premises passwords.	Configure and test password writeback.
No pilot deployment	Configuration errors affect the whole workforce.	Start with a representative test group.
Ignoring reset notifications	Unexpected recovery activity may go unnoticed.	Enable notifications and teach users how to report them.
Troubleshooting by manually bypassing verification	Support staff may weaken the recovery process.	Verify identity and correct the underlying policy or registration issue.

Key takeaways

SSPR allows eligible users to reset or change passwords without routine helpdesk intervention.
Users must be in scope and have sufficient permitted verification methods registered.
Combined registration supports both MFA and SSPR through one security-information experience.
Password writeback extends cloud password recovery to synchronised on-premises identities.
Cloud and on-premises password policies can both affect a hybrid reset.
Audit logs, registration reports, sign-in logs and sync health provide the investigation trail.
Notifications help expose unexpected password-reset activity.
Recovery controls should be piloted, monitored and designed to resist account takeover.

Related Agent Foskett resources

Continue developing Microsoft Entra authentication, recovery and identity investigation skills.

Lesson 16 — Authentication Strengths Lesson 15 — Authentication Methods Policies Lesson 4 — MFA and Authentication Methods Lesson 5 — Risky Users and Risky Sign-ins Lesson 3 — Conditional Access Fundamentals Microsoft Identity and Access Services

Continue learning

Continue through Microsoft Entra password protection and identity security, or return to the academy roadmap.

⬅ Previous lesson

Lesson 16 — Authentication Strengths in Microsoft EntraUnderstand multifactor, passwordless and phishing-resistant authentication requirements.

🏠 Academy home

Microsoft Entra AcademyReview the roadmap and continue through the identity security learning path.

📘 Next lesson

Lesson 18 — Microsoft Entra Password ProtectionLearn how banned-password lists and smart lockout reduce password-based attacks.

Microsoft Entra Self-Service Password Reset and Password Writeback

Microsoft Entra Self-Service Password Reset enables secure account recovery through registered authentication methods, combined MFA and SSPR registration, password policy enforcement, notifications and hybrid password writeback.

Microsoft Entra Academy Lesson 17 — Self-Service Password Reset

This Agent Foskett lesson explains SSPR configuration, verification methods, combined registration, Microsoft Entra Connect and Cloud Sync password writeback, audit reporting, troubleshooting and suspicious password-reset investigations.