Microsoft is moving from a “force Multi-Factor Authentication for all users” model to a risk based model where users are requested to do Multi-Factor Authentication when their sign-in has a risk assigned to it. This could happen for example by an impossible travel, the user logging in from an IP address which has been in contact with a botnet or other “signals” as Microsoft calls them.
First of all, with AAD Identity Protection, instead of doing manual or scripted assigning of MFA, this is now done with an MFA registration policy. Here is an example on what this can look like:
This will let organizations start with a group of users and expand to more and more users. What will happen is that the user will be prompted to register for MFA when they log on with a browser (or Office with ADAL etc.), but their next logon will not require MFA.
When we look at StrongAuthenticationRequirements of the user, it will be empty, meaning that MFA is not enforced, but the user is still ready to use MFA whenever Azure AD requires it.
Now let us look at the Sign-in risk policy:
Here I have configured the policy to be invoked when the machine learning system in Azure AD find my sign-in a low or medium risk. If a high risk is detected, it is blocked completely.
When I sign in from my regular computer, nothing happens. No MFA; everything is like it has always been. This is perfect, and exactly how this should work. Azure AD detects that everything is safe, no risk at all, so I am not prompted for MFA.
Now, let us try signing in through a RDP session from a computer about 2 hours away by air.
Suddenly my sign-in requires Multi-Factor Authentication, because I made an impossible travel.