Theoretical Foundation: Configure self-service password reset (SSPR)

---

1. Initial Intuition

In any company with hundreds or thousands of employees, one of the most frequent helpdesk tasks is resetting passwords. An employee forgot their password on Monday morning, calls support, waits in the queue, a technician verifies their identity and resets the password. This cycle costs time, money, and patience.

Self-Service Password Reset (SSPR) is Microsoft Entra ID's solution to this problem: it allows users to reset their own passwords or unlock their accounts without needing to call the helpdesk, as long as they have previously registered identity verification methods (like a mobile phone or alternative email).

The perfect analogy is the "Forgot your password?" feature on banking websites. You click it, the site verifies your identity through an SMS code or email, and you set a new password. SSPR is exactly that, but integrated with Entra ID, working for both Azure portal access and Windows login and corporate applications.

---

2. Context

SSPR is part of Microsoft Entra ID's security and productivity feature set. It sits at the intersection of identity security and user experience:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

An important point: the registration of authentication methods for SSPR and for MFA uses the same infrastructure in the Combined Security Info Registration portal (aka.ms/mysecurityinfo). A user who registers their mobile phone for MFA can use the same phone for SSPR, and vice versa. This eliminates the need for separate registrations.

Password Writeback (shown in orange) is the functionality that connects SSPR to hybrid environments. Without it, a reset made in Entra ID doesn't propagate to the on-premises Active Directory, and the user would continue with the old password in the local environment.

License Requirements

Feature	Required license
SSPR for cloud-only users	Microsoft Entra ID Free (with P1/P2 for advanced features)
SSPR with Password Writeback	Microsoft Entra ID P1 or P2
SSPR + Identity Protection integration	Microsoft Entra ID P2

Important note: Basic SSPR (cloud-only) is available in the free plan. Password Writeback requires P1 or P2. For AZ-104, it's important to know this distinction.

---

3. Building the Concepts

3.1 SSPR Enablement Scope

The first concept to understand is that SSPR doesn't need to be enabled for everyone at once. There are three scope options:

Option	Who can use SSPR	When to use
None	Nobody	SSPR disabled in the tenant
Selected	Only users from a specific group	Pilot, gradual rollout, specific groups
All	All users in the tenant	Complete deployment

The Selected option is fundamental for conducting a controlled pilot before enabling for everyone. You create a security group called, for example, SG-SSPR-Pilot, add 50 volunteer users, enable SSPR for that group, collect feedback, and then expand to All.

3.2 SSPR Authentication Methods

For users to reset their passwords on their own, the system needs to verify it's really them. This is done through authentication methods. Entra ID supports the following methods for SSPR:

Method	How it works	Notes
Mobile app notification	Push notification in Microsoft Authenticator	Most secure and convenient
Mobile app code	TOTP code generated by Authenticator	Works without internet on the phone
Email	Code sent to alternative email (not corporate)	Alternative email, not the one the user is trying to access
Mobile phone	SMS code or voice call to mobile	Widely supported
Office phone	Voice call to business extension	Less common for SSPR
Security questions	Pre-registered questions and answers	Less secure, see note below

About security questions: they are the weakest method because answers can be discovered through social engineering or social media research. Microsoft recommends not using security questions as the only method, and SSPR doesn't allow it to be the only method when only one method is required for reset.

3.3 Number of Required Methods

One of the most important configurations is how many methods the user needs to present to reset their password:

Configuration	Behavior	Security
1 method required	User presents only 1 registered method	Less friction, lower security
2 methods required	User must present 2 different methods	Higher security, more friction

The choice depends on the organization's risk profile. For most companies, 1 method is sufficient when the method is Microsoft Authenticator or SMS. For high-security environments or privileged access accounts, 2 methods is more appropriate.

3.4 Method Registration

Before being able to use SSPR, users need to register their authentication methods. There are three registration scenarios:

Forced registration at next login: the administrator enables the option to require users to register methods when they log in next time. The user is redirected to aka.ms/mysecurityinfo and cannot skip registration.

Voluntary registration: the user accesses aka.ms/mysecurityinfo on their own and registers their methods. Depends on communication and adoption.

Grace period: if forced registration is enabled, you can configure a period of days (default: 14 days) during which the user can postpone registration. After this period, registration becomes mandatory.

3.5 Password Writeback: The Hybrid Link

In environments where there's an on-premises Active Directory synchronized with Entra ID via Entra Connect, there's a challenge: passwords for synchronized users are managed in the local AD. If a user resets their password through SSPR (in Entra ID), this change needs to be propagated back to the on-premises AD. This is Password Writeback.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Without Password Writeback enabled, a user who reset their password in SSPR can access cloud services (Microsoft 365, Azure portal), but cannot log into Windows on a domain-joined computer, as the AD still has the old password.

---

4. Structural View

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

5. Practical Operation

User Flow: Password Reset

A user who forgot their password accesses https://aka.ms/sspr (or clicks "Forgot my password" on the Microsoft 365 or Windows login screen). The flow is:

1. Enters UPN (their corporate email address)
2. Solves a CAPTCHA to prevent malicious automation
3. Chooses verification method (from those registered)
4. Completes verification (enters SMS code, approves app notification, etc.)
5. If configured for 2 methods, repeats with a different second method
6. Sets the new password (respecting the tenant's complexity policy)
7. Receives confirmation and is redirected to login

Important and Non-Obvious Behaviors

Administrators always need 2 methods: regardless of the tenant configuration for regular users, accounts with administrative roles in Entra ID always need 2 methods to reset passwords via SSPR. This is additional protection that cannot be disabled.

Administrators cannot use security questions: for security reasons, accounts with administrative roles cannot use security questions as a verification method in SSPR.

Reset notifications: when a password is reset via SSPR, Entra ID can send an email notification to the user and/or administrator. This serves as a security alert: if someone tried to use SSPR without being the legitimate user, the real user is notified and can contact the helpdesk.

Lockout after failed attempts: SSPR has protection against brute force. After a number of failed verification attempts, the account is temporarily locked for SSPR. The user needs to wait or contact the helpdesk.

Registration and SSPR portals are different from usage portal: registration is done at aka.ms/mysecurityinfo. SSPR usage is at aka.ms/sspr. Most users reach SSPR through the "Forgot my password" link on the login screen, not by accessing the portal directly.

---

6. Implementation Methods

6.1 Azure Portal

When to use: initial setup, point adjustments, status verification.

Path: Microsoft Entra ID > Password reset

The "Password reset" section in the Azure portal has the following tabs:

Tab	What it configures
Properties	Scope: None / Selected / All
Authentication methods	Which methods are allowed, how many are required
Registration	Mandatory registration at login, grace period, reconfirmation frequency
Notifications	Notification to user and admin when password is reset
Customization	Custom helpdesk link displayed when SSPR is not available
On-premises integration	Password Writeback

Advantages: complete view of all settings in one place, immediate feedback.

Limitations: doesn't scale for automation or deployment across multiple tenants.

6.2 PowerShell (Microsoft Graph PowerShell SDK)

When to use: automation, consistent deployment between tenants, audit scripts.

Check current SSPR configuration:

# Requires Policy.Read.All permission
Get-MgPolicyAuthenticationMethodPolicy

Check authentication methods registered by a user:

$userId = "joao.silva@contoso.com"
Get-MgUserAuthenticationMethod -UserId $userId

This returns all methods registered by the user, including phones, the Authenticator app, and passwords (as primary authentication method).

Remove an authentication method from a user (useful when an employee loses their phone):

$userId = "joao.silva@contoso.com"
$methods = Get-MgUserAuthenticationPhoneMethod -UserId $userId
foreach ($method in $methods) {
    Remove-MgUserAuthenticationPhoneMethod -UserId $userId -PhoneAuthenticationMethodId $method.Id
}

6.3 Microsoft Graph API

Check registered authentication methods:

GET https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com/authentication/methods

Add a phone number for a user (pre-populating registration):

POST https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com/authentication/phoneMethods
Content-Type: application/json

{
  "phoneNumber": "+55 11 99999-0000",
  "phoneType": "mobile"
}

This is particularly useful for pre-registering methods during onboarding: the HR system can send the new employee's mobile number, and a script automatically populates the authentication method before first login, eliminating the need for the user to register on their own.

6.4 Configuration via Microsoft Entra Admin Center

The Microsoft Entra Admin Center (entra.microsoft.com) offers the same interface as the Azure portal for SSPR configuration, with a slightly more modern experience. For AZ-104, both paths lead to the same result.

---

7. Control and Security

Password Policies

SSPR respects and is integrated with Entra ID password policies:

Policy	Default behavior	Configurable?
Minimum length	8 characters	Yes (up to 256)
Complexity	Requires uppercase, lowercase, numbers or symbols	No (always required)
Password history	Cannot reuse last 3 passwords	Not configurable through portal
Expiration	90 days (default), but many tenants disable	Yes
Banned passwords	Global list of common passwords (Azure AD Password Protection)	Can add custom list

Azure AD Password Protection is a component that blocks weak or predictable passwords (like "Contoso2024!" for a company called Contoso). It operates both in the cloud and can be extended to on-premises AD with an agent installed on domain controllers.

SSPR Auditing

All SSPR activity generates records in the Audit Logs and Self-service password reset activity reports of Entra ID:

Path: Microsoft Entra ID > Password reset > Audit logs

Recorded events include:

• Self-service password reset flow activity started: user initiated the process
• User wrote back password to on-premises directory: writeback executed
• User reset password (self-service): reset completed successfully
• User registered for self-service password reset: method registration completed
• Blocked from self-service password reset: attempts blocked due to suspected abuse

Customization: Helpdesk Link

When SSPR is not available for the user (not in enabled scope, didn't register methods), the "Forgot password" screen can display a custom link to the internal helpdesk. This is configured in the Customization tab:

• Helpdesk email or URL: can be an email address or URL of an internal support portal
• Custom helpdesk text: text displayed next to the link

This customization improves user experience by clearly directing where to ask for help when self-service doesn't work.

---

8. Decision Making

How many methods to require for reset?

Situation	Recommended configuration	Reason
Regular users, low risk	1 method (Authenticator or SMS)	Less friction, sufficient for most
Accounts with access to sensitive data	2 methods	Greater assurance it's the real user
Administrative accounts	2 methods (mandatory by Azure)	Additional protection not configurable
Environment with high turnover	1 method + forced registration	Ensures registration without manual onboarding

Which authentication method to prioritize?

Method	Security	Usability	Recommendation
Microsoft Authenticator (notification)	High	High	First choice
Microsoft Authenticator (TOTP code)	High	High	Second choice
SMS	Medium	High	Good for users without smartphones
Alternative email	Medium	High	Useful as fallback
Voice call	Medium	Medium	For users without SMS access
Security questions	Low	High	Avoid as single method

When to enable Password Writeback?

Situation	Decision	Reason
100% cloud environment	Not necessary	No on-premises AD to synchronize
Hybrid environment with users using VPN/Intune	Required	Without writeback, reset doesn't work for local login
Hybrid environment where users only access cloud	Optional	If there's no local login, writeback is not critical
Users with Windows devices joined to local domain	Required	Windows login uses local AD password

---

9. Best Practices

Do gradual rollout with "Selected" scope: before enabling SSPR for everyone, create a pilot group with representative users from different profiles (technical, non-technical, mobile, fixed). Monitor usage, collect feedback and adjust settings before expanding.

Force registration but give a reasonable grace period: the default 14-day period is adequate for most environments. Very short periods cause unnecessary friction. Very long periods result in users who never register.

Communicate before enabling: users who don't know what SSPR is will call the helpdesk confused when they're redirected to register methods. Prior communication with clear instructions reduces calls and resistance.

Pre-populate mobile number via Graph API during onboarding: instead of depending on the user to register the method themselves, automatically inject the mobile number (provided by HR) at the moment of account creation. The user arrives with a method already registered.

Configure periodic reconfirmation of methods: Entra ID can request that users confirm/update their authentication methods periodically (default: 180 days). This ensures that outdated phone numbers don't remain as the only registered method.

Enable reset notifications to the user: the email notification when a password is reset works as a security alert. If the real user didn't initiate the reset, they're notified and can act quickly.

---

10. Common Errors

Enabling SSPR without communicating to users about registration

SSPR is enabled, but since users never registered methods, when they try to reset the password they receive the message that they don't have methods configured. They continue calling the helpdesk. SSPR exists but isn't used. The solution is to enable forced registration along with SSPR.

Not enabling Password Writeback in hybrid environment

The user resets the password through the portal, receives success confirmation, but can't log into the office computer. The helpdesk receives the confused call since the "reset worked". The cause is the absence of writeback. Always verify if the environment is hybrid before concluding the configuration.

Relying only on security questions

Questions like "What's the name of your first pet?" are frequently discovered through social media searches or by people close to you. If security questions are enabled, use them only as a second complementary method, never as the only method.

Not testing the complete flow after configuration

Administrators configure SSPR in the portal, mark it as "completed" and never test the real user flow. Problems like incorrect redirect URLs, methods that don't work in the user's country or poorly configured writeback settings only appear when a real user tries to use it. Always test with a test account before rollout.

Blocking access to aka.ms/mysecurityinfo by proxy or firewall

Some organizations filter external URLs aggressively. If aka.ms/mysecurityinfo or aka.ms/sspr are blocked by the corporate proxy, users can't register methods or use SSPR. Verify that these URLs are in the allow list.

Forgetting that administrators have different rules

An administrator testing SSPR with their own account notices they need 2 methods even with the tenant configured for 1. This is not a bug or incorrect configuration: it's the expected behavior for accounts with administrative roles. Testing should be done with a regular user account.

---

11. Operation and Maintenance

SSPR Usage Reports

Entra ID offers specific reports for SSPR in Microsoft Entra ID > Password reset > Audit logs and Usage & insights:

Registration report: shows how many users registered methods, which methods were registered and which users still haven't registered anything.

Usage report: shows how many resets were done, which methods were used, how many failed and why (invalid method, blocked user, etc.).

These reports are essential for:

• Identifying users who still haven't registered methods
• Measuring SSPR impact on helpdesk call reduction
• Identifying methods with high failure rates

Check users without registered methods

# List enabled users without any registered authentication method
$users = Get-MgUser -All -Filter "accountEnabled eq true" `
  -Property "id,displayName,userPrincipalName"

foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
    # Filter only "password" method (everyone has); look for additional methods
    $additionalMethods = $methods | Where-Object { 
        $_.AdditionalProperties["@odata.type"] -ne "#microsoft.graph.passwordAuthenticationMethod"
    }
    if ($additionalMethods.Count -eq 0) {
        Write-Output "$($user.DisplayName) - $($user.UserPrincipalName) - NO METHODS"
    }
}

Important Limits

Item	Value
Reset attempts before lockout	Configurable, default: no limit by design (protection by intelligent throttling)
SMS code validity	5 minutes
Email code validity	5 minutes
Method reconfirmation period	0 to 730 days (default: 180)
Minimum security questions for registration	3 to 5 (configurable)
Security questions required for reset	3 to 5 (configurable, cannot exceed registration number)

---

12. Integration and Automation

Integration with Entra Connect and Password Writeback

Password Writeback is configured in two places:

In Entra Connect (on-premises server): when configuring Entra Connect, enable the "Password writeback" functionality in the optional features section of the configuration wizard.

In the Entra ID portal: in Password reset > On-premises integration, enable "Write back passwords to your on-premises directory" and optionally "Allow users to unlock accounts without resetting their password" (allows unlocking AD account without needing to change password).

Pre-registration via Automation in Onboarding

The best automation strategy for SSPR is integrating pre-registration into the new employee onboarding flow:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

This flow ensures that 100% of users arrive with at least one registered method, eliminating dependence on voluntary adoption.

Monitoring with Azure Monitor

SSPR logs can be exported to a Log Analytics Workspace for centralized monitoring and alerts:

# Export Entra ID audit logs to Log Analytics
# Configured in: Microsoft Entra ID > Monitoring > Diagnostic settings

With logs in Log Analytics, it's possible to create alerts for:

• Spikes in number of resets (may indicate phishing campaign)
• High failure rate in verifications (may indicate brute force attack)
• Users who attempted SSPR but had no registered methods

---

13. Final Summary

Essential points:

• SSPR allows users to reset passwords and unlock accounts without helpdesk, using pre-registered authentication methods.
• Scope can be None, Selected (specific group) or All. Start with Selected for controlled pilot.
• Supported methods: Microsoft Authenticator (notification and TOTP), SMS, voice call, alternate email, security questions. Authenticator is the first choice.
• Number of methods required for reset can be 1 or 2. Administrators always need 2, regardless of configuration.
• Password Writeback is necessary in hybrid environments and requires P1 or P2 license. Without it, reset only updates the cloud.
• Combined registration (aka.ms/mysecurityinfo) shares methods between SSPR and MFA.

Critical differences:

• SSPR for regular users (Free license): works for cloud identities. Password Writeback not included.
• SSPR with Password Writeback (P1/P2 license): works for hybrid environments, propagates change to local AD.
• Administrators vs. regular users: admins always need 2 methods for SSPR, can't use security questions, and their resets go through a more rigorous process.
• Registration (aka.ms/mysecurityinfo) vs. usage (aka.ms/sspr): are different portals for distinct purposes.

What needs to be remembered:

• Enable forced registration on next login when deploying SSPR to ensure adoption.
• Pre-populate phone numbers via Graph API during onboarding to ensure users arrive with registered methods.
• Avoid security questions as the only method. Prefer Authenticator or SMS.
• Test the complete flow with a regular user account before rollout, not with administrator account.
• Configure reset notifications so users are alerted when a reset occurs, functioning as abuse detection.
• In hybrid environments, verify that Entra Connect has Password Writeback enabled AND that the Entra ID portal also has writeback activated. These are two independent configurations that both need to be active.