MFA and conditional access policies are powerful tools for our cloud security, but they are full of tricks.

I don’t pretend to cover the basics here. You know you can create conditional access policies to request MFA authentication from the users. You also know the fact the default configuration (which you should avoid) will request MFA from everyone.

However, for the user to fulfill the requirement, the user needs to be registered for the MFA. There are some different ways to control the user registration for MFA.

It’s recommended to ensure the registration of the users for MFA before the conditional access policies jumps in and start requesting MFA from the users.

Direct Registration Requirement

On Active Directory -> Security -> Identity Protection -> MFA Registration Policy you can define the users who will be required to register a 2nd authentication method for MFA.

MFA give the  user 14 days for the registration before making it required. However, this will be a registrations of a single alternate method which by default is the Authenticator App.

The user has the option to choose a different method instead of the authenticator app, but not many users do so. A request for a new registration will never appear for the user again, or that’s what most people believe.

Self-Service Password Reset

It’s undeniable that SSPR is a very interesting feature, but what’s its relation to MFA registration?

SSPR requires MFA authentication methods. You can check the authentication methods required by SSPR on Active Directory -> Password Reset -> Authentication Methods

The enabled authenticator methods don’t includ the authenticator app  by default. You can include it, but it’s not by default.

On the item below, Active Directory -> Password Reset -> Registration the default configuration is to require every user registered for SSPR to register an MFA method on their next login and by default will be a different one than the default Authenticator App.

This becomes the second option the user has to register a secondary MFA method.

The Problem

It’s not very good the idea to depend on SSPR for the registration of a secondary MFA method. What happens if the user is in the middle of a trip and don’t have access to the main MFA methods registered? How could the user authenticate with alternate methods?

It’s not a good idea to have a single MFA method registered, how could you configure additional ones?

The Solution

There are two addresses the user can access directly to register additional MFA methods:

• First Option: https://aka.ms/mfasetup
• Second Option: https://aka.ms/setupsecurityinfo 

Conclusion

It may be a good idea for the IT team to make these addresses available to the users so they can control their own MFA registration methods and ensure that, when in trouble, they still have alternate options to authenticate on the systems.