Self-service password reset frequently asked questions

Yes. As long as password reset is enabled and they are licensed, users can go to the password reset registration portal (https://account.activedirectory.windowsazure.cn/PasswordReset/Register.aspx?regref=ssprsetup) to register their authentication information. Users can also register through the Access Panel (https://myapplications.windowsazure.cn). To register through the Access Panel, they need to select their profile picture, select Profile, and then select the Register for password reset option.

If you enable combined registration, users can register for both SSPR and Microsoft Entra multifactor authentication at the same time.

No. Users who have populated authentication data are not required to re-register.

Yes, you can do so with Microsoft Entra Connect, PowerShell, the Microsoft Entra admin center. For more information, see Data used by Microsoft Entra self-service password reset.

No, this is not possible today.

Yes. When users register data by using the password reset registration portal, the data is saved into private authentication fields that are visible only to Privileged Authentication Administrators and the user.

No. If you define enough authentication information on their behalf, users don't have to register. Password reset works as long as you have properly formatted the data stored in the appropriate fields in the directory.

The fields that are able to be set by a Privileged Authentication Administrator are defined in the article SSPR Data requirements.

The password reset registration portal shows only the options that you have enabled for your users. These options are found under the User Password Reset Policy section of your directory's Configure tab. For example, if you don't enable security questions, then users are not able to register for that option.

A user is considered registered for SSPR when they have registered at least the Number of methods required to reset a password that you have set in the Microsoft Entra admin center.

Yes, there are security features built into password reset to protect it from misuse.

Users can attempt to validate their information (such as their phone number), but if they're unable to prove their identity five times within a 24-hour period, they're locked out for 24 hours.

Users can try to validate a phone number, auth app, send a text message, or validate security questions and answers only five times within an hour before they're locked out for 24 hours.

Users can send an email a maximum of 10 times within a 10 minute period before they're locked out for 24 hours.

The counters are reset once a user resets their password.

Emails, text messages, and phone calls should arrive in under a minute. The normal case is 5 to 20 seconds. If you don't receive the notification in this time frame:

• Check your junk folder.
• Check that the number or email being contacted is the one you expect.
• Check that the authentication data in the directory is correctly formatted, for example, +1 4255551234 or user@contoso.com.

The password reset UI, text messages, and voice calls are localized in the same languages that are supported in Microsoft 365.

The password reset portal shows your organization's logo and allows you to configure the "Contact your administrator" link to point to a custom email or URL. Any email that's sent by password reset includes your organization's logo, colors, and name in the body of the email, and is customized from the settings for that particular name.

Try some of the suggestions in our SSPR deployment article.

Yes, this page works on mobile devices.

Yes. When a user resets their password, if password writeback has been deployed through Microsoft Entra Connect, that user's account is automatically unlocked when they reset their password.

If you're an Microsoft Entra ID P1 or P2 customer, you can install Microsoft Identity Manager at no additional cost and deploy the on-premises password reset solution.

No, this is not possible today.

You can configure up to 20 custom security questions in the Microsoft Entra admin center.

Security questions can be 3 to 200 characters long.

Answers can be 3 to 40 characters long.

Yes, we reject duplicate answers to security questions.

No. After a user registers a particular question, they can't register for that question a second time.

Yes, one limit can be set for registration and another for reset. Three to five security questions can be required for registration, and three to five questions can be required for reset.

This is the expected behavior. Microsoft enforces a strong default two-gate password reset policy for any Azure administrator role. This prevents administrators from using security questions. You can find more information about this policy in the Password policies and restrictions in Microsoft Entra ID article.

N number of security questions are selected at random out of the total number of questions a user has registered for, where N is the amount that is set for the Number of questions required to reset option. For example, if a user has registered five security questions, but only three are required to reset a password, three of the five questions are randomly selected and are presented at reset. To prevent question hammering, if the user gets the answers to the questions wrong the selection process starts over.

Yes, if you use a group to enable SSPR, you can remove an individual user from the group that allows users to reset their password. If the user is a Privileged Authentication Administrator, they can reset their password and this cannot be disabled.

Users can change their passwords anywhere they see their profile picture or icon, like in the upper-right corner of their Access Panel experiences. Users can change their passwords from the Access Panel Profile page. Users can also be asked to change their passwords automatically at the Microsoft Entra sign-in page if their passwords have expired. Finally, users can browse to the Microsoft Entra password change portal directly if they want to change their passwords.

Yes, this is possible today if you use Active Directory Federation Services (AD FS). If you use AD FS, follow the instructions in the Sending password policy claims with AD FS article. If you use password hash synchronization, this is not possible today. We don't sync password policies from on-premises directories, so it's not possible for us to post expiration notifications to cloud experiences. In either case, it's also possible to notify users whose passwords are about to expire through PowerShell.

For cloud-only users, password changes can't be blocked. For on-premises users, you can set the User cannot change password option to selected. The selected users can't change their password.

Data should appear on the password management reports in 5 to 10 minutes. In some instances, it might take up to an hour to appear.

To filter the password management reports, select the small magnifying glass to the extreme right of the column labels, near the top of the report. If you want to do richer filtering, you can download the report to Excel and create a pivot table.

Up to 75,000 password reset or password reset registration events are stored in the password management reports, spanning back as far as 30 days. We are working to expand this number to include more events.

The password management reports show operations that occurred within the last 30 days. For now, if you need to archive this data, you can download the reports periodically and save them in a separate location.

Yes. A maximum of 75,000 rows can appear on either of the password management reports, whether they are shown in the UI or are downloaded.

Yes, you can get this info from the API to get password reset activity. You can also use the audit logs API and filter by SSPR events.

See the article How password writeback works for an explanation of what happens when you enable password writeback and how data flows through the system back into your on-premises environment.

Password writeback is instant. It is a synchronous pipeline that works fundamentally differently than password hash synchronization. Password writeback allows users to get real-time feedback about the success of their password reset or change operation. The average time for a successful writeback of a password is under 500 ms.

If your on-premises ID is disabled, your cloud ID and access will also be disabled at the next sync interval through Microsoft Entra Connect. By default, this sync is every 30 minutes.

Yes, SSPR relies on and abides by the on-premises Active Directory password policy. This policy includes the typical Active Directory domain password policy, as well as any defined, fine-grained password policies that are targeted to a user.

Password writeback works for user accounts that are synchronized from on-premises Active Directory to Microsoft Entra ID, including federated and password hash synchronized users.

Yes. Password writeback enforces password age, history, complexity, filters, and any other restriction you might put in place on passwords in your local domain.

Yes, password writeback is secure. To read more about the multiple layers of security implemented by the password writeback service, check out the Password writeback security section in the Password writeback overview article.

Next steps

• How do I complete a successful rollout of SSPR?
• Reset or change your password
• Register for self-service password reset
• Do you have a licensing question?
• What data is used by SSPR and what data should you populate for your users?
• What authentication methods are available to users?
• What are the policy options with SSPR?
• What is password writeback and why do I care about it?
• How do I report on activity in SSPR?
• What are all of the options in SSPR and what do they mean?
• I think something is broken. How do I troubleshoot SSPR?