AD1.6 Self-Service Password Reset

Configuring SSPR

Navigate to entra.microsoft.com → Protection → Password reset. The configuration has four key sections.

Properties: Set “Self-service password reset enabled” to “All” (all users). You can start with a pilot group if you want to test first, but SSPR has minimal blast radius — users who don’t need it simply never use it, and users who do need it get an immediate benefit.

Authentication methods: Set “Number of methods required to reset” to 2 (this means the user must verify their identity with two methods, matching MFA strength). Under “Methods available to users,” enable Microsoft Authenticator notification, Authenticator app code, email (a secondary email address), and mobile phone. Disable “Security questions” — they’re easily guessable or researchable through social media. The strongest configuration uses the methods the user has already registered for MFA, which means SSPR registration and MFA registration converge.

Registration: Set “Require users to register when signing in” to “Yes” and set “Number of days before users are asked to reconfirm” to 180. This ensures every user has SSPR methods registered and periodically re-validates them.

Notifications: Enable “Notify users on password resets” (the user gets an email when their password is reset — if they didn’t initiate it, this is an early warning of compromise) and “Notify all admins when other admins reset their password” (any admin password reset triggers notification to all other admins — a critical alert for detecting admin account compromise).

Password writeback for hybrid environments

If your environment uses Azure AD Connect to sync on-premises Active Directory with Entra ID (which NE does), you need password writeback enabled. Without writeback, a user who resets their password via SSPR changes only the cloud password — their on-premises AD password stays the same, and they can’t log into domain-joined devices with the new password.

Password writeback is configured in the Azure AD Connect wizard on your sync server. Open Azure AD Connect → Configure → Customize synchronization options → Optional features → check “Password writeback.” After enabling writeback, SSPR password changes propagate to on-premises AD within seconds.

If you’re running Azure AD Connect Cloud Sync instead of the classic Azure AD Connect, password writeback is enabled in the Entra admin center → Hybrid management → Azure AD Connect → Cloud Sync → Password writeback toggle.

Test writeback after configuration: have a user reset their password via aka.ms/sspr, then attempt to log into a domain-joined workstation with the new password. If the login succeeds, writeback is working. If it fails, check the Azure AD Connect sync service logs for writeback errors — the most common issue is insufficient permissions for the AD Connect service account in Active Directory.

The security benefit most people miss

SSPR isn’t just a convenience feature — it’s a security control. Helpdesk password resets are a known social engineering vector. An attacker calls the helpdesk, claims to be a locked-out employee, provides enough personal information to satisfy the identity verification (employee number, date of birth, manager’s name — all findable on LinkedIn or through prior reconnaissance), and the helpdesk technician resets the password. The attacker now has a fresh password for the account.

SSPR eliminates this vector because the identity verification happens through cryptographic methods (Authenticator app, FIDO2 key) that the attacker can’t replicate over a phone call. The helpdesk technician is removed from the password reset flow entirely for standard users, which means there’s no human to social engineer.

For your helpdesk team, this also means they should be trained to decline password reset requests: “Our policy requires self-service password reset through aka.ms/sspr. If you’re unable to complete the self-service process, I can help you with SSPR registration, but I cannot manually reset your password.” This is a hard line to hold — but it’s the line that prevents social engineering attacks against your helpdesk.

Banned password lists — stop weak passwords at the source

While you’re configuring SSPR, configure custom banned passwords. Navigate to entra.microsoft.com → Protection → Authentication methods → Password protection. Enable “Custom banned password list” and add terms specific to your organisation: company name, product names, office locations, and common variations. Entra ID already blocks thousands of common weak passwords globally, but the custom list catches organisation-specific patterns like “Northgate2026!” or “Engineering1” that the global list doesn’t know about.

Set “Mode” to “Enforced” (not “Audit” — banned passwords should be blocked, not logged). Set “Enable password protection on Windows Server Active Directory” to “Yes” if you have hybrid environment — this extends the banned password check to on-premises AD password changes as well, so users can’t set weak passwords locally and have them sync to the cloud.

The combination of SSPR and banned passwords means users can reset their own passwords 24/7, and the new password they choose is automatically checked against both the global banned list and your custom list. A user trying to set “Northgate123!” gets rejected immediately with a message to choose a stronger password. No helpdesk intervention needed.

Monitoring SSPR activity

SSPR generates audit events that you should monitor, especially in the first two weeks after deployment. Navigate to entra.microsoft.com → Protection → Password reset → Audit logs. The key events to watch for:

“Self-service password reset flow activity completed” — this is a successful SSPR reset. Expect a steady volume as users adopt the feature. A sudden spike (10+ resets in an hour from different accounts) could indicate an attacker testing stolen credentials against the SSPR flow.

“User blocked from self-service password reset” — this means a user tried SSPR but couldn’t complete the identity verification (wrong MFA method, expired registration, too many failed attempts). Check whether this is a legitimate user who needs registration help or an attacker failing to verify a stolen identity.

“Self-service password reset flow activity progress” — this captures each step of the SSPR flow, including which verification methods were used and whether each step succeeded or failed. Useful for troubleshooting when a user reports “SSPR isn’t working.”

One particularly valuable SSPR monitoring pattern: if you see a “Self-service password reset flow activity completed” event for a user who also has a “Leaked credentials” risk detection in Identity Protection, the password reset is almost certainly a legitimate user responding to your notification that their credentials were found in a breach database. Correlating SSPR events with risk detections confirms that your notification process is working — users are receiving the leaked credential notification and proactively resetting their passwords. Add these audit events to your Monday morning review alongside the sign-in log check and the Defender incident queue review. Total addition to your weekly monitoring: 2 minutes.