When configuring Azure MFA and Conditional Access there is the potential to lock out all users from the system including the Azure Portal. As with any security control/mechanism, the costs of implementation and maintenance always need to be commensurate with the risks and costs of not implementing the control (e.g. assets at risk, reputational risk).
With this in mind, here are some key best practices you should follow when enabling MFA:
- Ensure that end users are informed adequately that MFA is coming as it can negatively affect the user experience and cause confusion. Microsoft provides communication templates and end user documentation for this purpose - Microsoft provides communication templates and user documentation - per (per https://www.microsoft.com/security/blog/2020/01/15/how-to-implement-multi-factor-authentication/)
- Always grant exclusions for every MFA policy - this will ensure there is always an MFA backdoor so you don't completely lock yourself out (especially if conditional access rules apply to all apps or the Azure portal). When enabling conditional access, make sure exclusions are made for
- Administrators
- Support staff.
- Any trusted IPs and known IP addresses/named locations.
- Testing - Use what-if policies to test effective permissions when making changes.
- Pilot changes using select groups to apply and test MFA policies.
- Don't block users who report fraud as users can lock themselves out (though this is less secure there is a danger of false positives).
- Don't use MFA portal and Conditional access at same time - It's not a good idea to use MFA through the MFA control panel as well as conditional access. Disable user accounts for MFA management in the MFA portal prior to if you are using conditional access - otherwise you'll have 2 competing rulesets.
- Use Azure Identity Protection (IdP) - as good way to ensure users are forced to register MFA (MFA needs to be configured first) and to ensure MFA coverage. Also allows notifications, blocks or requires MFA when administrative accounts are logged into during high sign-in risk activities such as when seeing anomalous travel of sign-ins.
