Self-Service Password Reset Security Hardening: How to Close the SSPR Attack Surface That Bypasses MFA in Entra ID

SSPR supports multiple authentication methods with different resistance levels to attacker abuse:

Microsoft Authenticator app (push notification or code): Highest assurance. Requires the attacker to control the registered mobile device or steal the TOTP seed. Recommended as the primary SSPR method for all users.

FIDO2 security key: Highest assurance. Phishing-resistant. Requires physical possession of the registered key. Use for privileged users who have keys registered.

SMS / Voice call to phone number: Moderate risk. Vulnerable to SIM swapping, SS7 attacks, and call forwarding attacks. SIM swapping in particular is used in targeted account takeover against executives and high-value targets. Do not use as a sole SSPR method for any account with elevated access.

Office phone: Moderate risk. Easier to forward than mobile numbers in some enterprise telephony configurations. Same risk profile as SMS.

Email address (not corporate email): Moderate to high risk. If the backup email account is also compromised (or uses a weaker password), the SSPR path is broken. This method uses a separate email account outside the M365 tenant.

Security questions: Highest risk. Answers are frequently derivable from LinkedIn, social media, and public records databases (OSINT). Common security question categories (birthplace, mother's maiden name, high school, first car, pet name) have limited entropy and are systematically targeted. Disable this method entirely.

Configure method requirements:

Entra ID admin center > Protection > Password reset > Authentication methods
Number of methods required to reset: 2
Methods available to users: [uncheck Security questions, uncheck Email]
Required: Microsoft Authenticator, optionally add Mobile phone as second method only (not sole method)

No privileged account should be eligible for self-service password reset. Admin account password resets should require a manual helpdesk process with out-of-band identity verification.

Exclude privileged accounts from SSPR:

Entra ID admin center > Protection > Password reset > Properties
Self service password reset enabled: Selected (for group)
Select group: [All Users minus privileged admins exclusion group]

The recommended architecture:

1. Create an Entra ID security group: SSPR-Excluded-Privileged-Accounts
2. Add all accounts with admin roles to this group (automate with a dynamic group rule if using licensed Entra ID P1/P2)
3. Configure SSPR to target a group that specifically excludes this group, OR configure SSPR for Selected groups and exclude the privileged group from the selected target

Dynamic group rule to capture all users with any admin role assignment (for exclusion):

Entra ID > Groups > New group > Dynamic membership rules
Rule: (user.assignedRoles -ne null)

Note: this requires Entra ID P1 license for dynamic group membership.

For global administrators and privileged role administrators specifically, consider using the Privileged Identity Management (PIM) breakglass account pattern: two emergency access accounts with FIDO2 hardware keys, stored credentials in a physical safe, and SSPR completely disabled. Document these accounts and test access quarterly.

SSPR authentication occurs before sign-in, which means standard Conditional Access policies that require compliant devices or MFA do not apply during the SSPR flow. This creates a policy gap:

The gap: A Conditional Access policy requiring MFA for all sign-ins to Office 365 does NOT block an attacker from using SSPR to reset a password from an unmanaged device from an unfamiliar country. SSPR is a pre-authentication flow and bypasses sign-in Conditional Access.

What does apply during SSPR: Authentication method requirements, the number of required methods, and optionally, SSPR Conditional Access authentication context (preview as of 2026).

Mitigations for the gap:

1. Require 2 strong methods: If SSPR requires Microsoft Authenticator (phone possession) AND a second factor, the attacker must simultaneously control two separate authentication channels.

2. Monitor SSPR events aggressively: Alert on SSPR password resets from new countries or from flagged IP ranges:

// Kusto: alert on SSPR from unusual location
AuditLogs
| where OperationName == "Reset password (self-service)"
| extend IPAddress = tostring(AdditionalDetails[?(@.key == "ipAddress")].value)
| extend Country = tostring(AdditionalDetails[?(@.key == "country")].value)
| where Country !in ("United States", "Canada")  // Adjust to expected user locations
| project TimeGenerated, Identity, IPAddress, Country, ResultReason

1. Restrict SSPR registration: Use the SSPR registration campaign (Entra ID > Authentication methods > Registration campaign) to require users to register strong methods before using SSPR, and audit registrations monthly for unexpected method changes (e.g., a registered Authenticator being removed and replaced with SMS).

In hybrid environments where on-premises AD is synced with Entra ID, SSPR password writeback allows a cloud SSPR event to reset the on-premises AD password. This creates a cloud-to-on-prem write path that requires careful security configuration.

The Entra Connect Sync service account used for writeback requires specific AD permissions:

• Reset Password on the user object
• Write lockoutTime on the user object
• Write pwdLastSet on the base object of each domain

Audit the Entra Connect service account permissions:

# Identify the Entra Connect sync service account
Get-ADUser -Filter {SamAccountName -like "MSOL_*"} | Select-Object SamAccountName, DistinguishedName

# Check the permissions granted to this account on the domain
$syncAccount = "DOMAIN\MSOL_<suffix>"
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl -Path "AD:\$domainDN"
$acl.Access | Where-Object {$_.IdentityReference -eq $syncAccount} | Format-Table

The sync account should have only the minimum required permissions. If it has GenericAll or Domain Admin membership, investigate and remediate immediately -- this is a critical privilege escalation path.

Additionally, monitor for SSPR writeback events in on-premises AD:

• Event ID 4723 (attempt to change account password) with caller computer being the Entra Connect server is expected
• Event ID 4723 with caller being any other system is suspicious and should alert

SSPR is only as secure as the authentication methods registered. An attacker who gains temporary access to an account can register a new SSPR method and use it later for persistent access:

# Audit all SSPR method registration events in UAL over last 90 days
Connect-IPPSSession
$ssprRegs = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) `
    -Operations "User registered security info","User deleted security info" `
    -ResultSize 5000

# Parse and export registration events
$ssprRegs | ForEach-Object {
    $data = $_.AuditData | ConvertFrom-Json
    [PSCustomObject]@{
        Time = $_.CreationDate
        User = $_.UserIds
        Operation = $_.Operations
        Method = $data.AdditionalDetails | Where-Object {$_.key -eq "Type"} | Select-Object -ExpandProperty value
        IP = $data.ActorIpAddress
    }
} | Export-Csv sspr-registration-audit.csv -NoTypeInformation

Alerts to configure (Entra ID > Monitoring > Alert rules or Microsoft Sentinel):

• SSPR method registered from a country not in the user's normal sign-in countries
• SSPR method registration immediately followed by a password reset (attack sequence: register new method, immediately use it to reset)
• Deletion of Authenticator app from SSPR methods and replacement with SMS (downgrade attack)

For organizations with Entra ID P2 (Privileged Identity Management), use Identity Protection's "User risk" policies to require re-authentication before SSPR registration is allowed when the user's risk score is elevated.