Change Password does not require SSPR registration

[dwarfered]

An end user subject to an assigned user risk by Identity Protection may remediate their assigned risk by using the Conditional Access flow as defined.

However, the Identity Protection article defines a prerequisite requirement that users are both Azure AD MFA and SSPR enrolled.

This appears to be misleading.

From testing it appears users only require Azure AD MFA as a minimum. Users can have an incomplete SSPR registration or be denied SSPR entirely and still perform the remediation.

Example Scenario An organisation's policy requires all users to MFA (Authenticator) but has not yet mandated all complete its SSPR registration campaign (requiring 2 methods for a reset). Following the article it implies all of its users first must register for SSPR. Those members with MFA Authenticator alone can already remediate their 'high risk' using MFA alone (without complete or available SSPR).

[opbld33]

Learn Build status updates of commit b8b4694:

:white_check_mark: Validation status: passed

File	Status	Preview URL	Details
articles/active-directory/identity-protection/howto-identity-protection-configure-risk-policies.md	:white_check_mark:Succeeded

For more details, please refer to the build report.

Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[Jak-MS]

@MicrosoftGuyJFlo

• Can you review this PR?
• IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team

[MicrosoftGuyJFlo]

@dwarfered They must have SSPR to do secure password change. They must have MFA to perform MFA that is the intent of that statement.

[MicrosoftGuyJFlo]

#hold-off

[dwarfered]

Thanks @MicrosoftGuyJFlo, perhaps this explains what I mean clearer:

A company has a SSPR configuration requiring 2 methods to reset at aka.ms/sspr

User A Has strong authentication methods: Microsoft Authenticator Mobile (SMS) Alternative Email

User B Has strong authentication methods: Microsoft Authenticator

User B is not fully SSPR enrolled (cannot Reset) but may still remediate his risk using the change password flow. Which following the sign in screens is

1. The company needs you to sign in again
2. Approve the MFA challenge
3. It looks like you’re compromised, enter your current, new and confirm new. An additional “Reset” method, sms or email time based one time password is not requested as it’s a change operation.

[dwarfered]

[MicrosoftGuyJFlo]

#label:"awaiting-product-team-response"

[MicrosoftGuyJFlo]

The Identity Protection PMs are reviewing this

[tracyshi]

Thanks for raising this. We have confirmed that although SSPR can be used to remediate user risks, it is not a hard prerequisite for completing the password change flow when the user risk policy applies. @MicrosoftGuyJFlo We can close this PR now since we have opened a separate PR https://github.com/MicrosoftDocs/azure-docs-pr/pull/216383 to update our doc with more changes. Thanks!

[Court72]

Closing this PR per https://github.com/MicrosoftDocs/azure-docs/pull/99936#issuecomment-1294366310