Welcome to Identity Protection Policies. In this lesson, we’ll review the identity protection policies that are available.

The three default identity protection policies that are available in Azure AD Identity Protection include the MFA Registration Policy, the User Risk Remediation Policy, and the Sign-In Risk Remediation Policy. There is very little customization available for each of these, but the settings that are available do generally apply to most companies. 

Let’s take a quick look at each one.

The MFA Registration Policy, as you might expect, allows you to push out Azure AD multi-factor authentication via a Conditional Access policy. This forces users to register for MFA at sign-in. In turn, this ensures that all users register for MFA on their first day of employment. I should also point out that MFA is one of the available self-remediation methods in Azure Identity Protection that can be used for risk events. 

The User Risk Remediation Policy is another identity protection policy that’s available in Identity Protection by default. This policy works in conjunction with Identity Protection’s ability to identify what it believes is normal or abnormal behavior for a specific user. The term “User Risk” really refers to the probability that Identity Protection has calculated that a particular user identity has been compromised, based on the observed behavior of the account. 

The User Risk Remediation Policy can be used to define what happens when Identity Protection determines that something is amiss with an account. In other words, you can use this policy to tell Identity Protection what to do when it calculates a risk score that indicates an account may be compromised. You can configure the policy to block access, to allow access, or to allow access but require a password change using Azure AD self-service password reset.

You can even configure the Controls within the policy so that when Identity Protection identifies a risk, the affected user can self-remediate the issue by performing a self-service password reset. In these self-remediation cases, the user risk event can be closed without the need to involve an administrator.

And then we have the Sign-In Risk Remediation Policy. Now, to understand what this policy does, you have to understand that Identity Protection looks at every account sign-in, calculating a risk score for each sign-in. The risk score for a sign-in represents the probability that the sign-in wasn't performed by the actual user, but maybe an imposter. The Sign-In Risk Remediation Policy allows you, as the administrator, to enforce organizational requirements based on the risk score signal that Identity Protection calculates for a particular sign-in. You can choose to block the user account’s access, allow access, or allow access but require multi-factor authentication.

If a risk IS detected, you can use the policy to require the affected user to self-remediate by performing multi-factor authentication. In such a case, the risky sign-event can be closed without the need to involve an administrator – because that’s the point of self-remediation – to reduce the noise that admins need to deal with.

I should mention, though, that the sign-in risk remediation policy can only be triggered for users who have already registered for Azure AD Multi-Factor Authentication, which takes us back to the usefulness of the MFA Registration Policy that we talked about a little bit ago.

Now, in addition to the three default policies that are available, you can also create a custom Conditional Access policy if none of those defaults work for you for some reason. When you create a custom policy, you can include sign-in risk as an assignment condition. That said, you would typically only use the Custom Policy is rare cases, since the default policies are designed to fit most typical environments.

 

So, to recap, you have the MFA Registration Policy, that allows you to force users to register for MFA at sign-in. You have the User Risk Remediation Policy, which can be used to define what happens when Identity Protection determines that an account may be compromised. And then you have the Sign-In Risk Remediation Policy, which allows you to enforce organizational requirements based on the risk score signal that Identity Protection calculates for a particular sign-in. The Custom Conditional Access policy can be used in the rare situation where the defaults don’t fit for some reason.