Per-user (or legacy) MFA, as the name suggests, is no longer Microsoft's preferred option for using MFA in Microsoft 365. It allows you to enable MFA per-user and to create exceptions where necessary but is only configurable via a separate legacy web panel or PowerShell. Users are prompted for MFA on every login, regardless of what they're accessing.
If you have Azure AD Premium P1 licenses, there is no reason to use Legacy MFA - you should be using Conditional Access as it provides all the same features and flexibility but with far better support.
Otherwise, if you really can't get everyone using MFA such that you can't use Security Defaults, you can use this approach to selectively enable MFA, such as on high privilege accounts - this is much better than not using MFA at all if Security Defaults doesn't work for you.
However, at best this should be an interim solution until you are able to transition to Security Defaults or Conditional Access - all accounts without MFA represent a potential security risk as they are available with a single factor of authentication.
If you choose this option, we will guide you through how to prepare the necessary parts of your environment, encourage users to enrol for MFA, and periodically set enrolled users to an "Enforced" state, causing them to then require MFA on future logins. This will allow you to roll out MFA usage without disruption.
For more information on these terms and this approach in general, read the Microsoft documentation.
See Microsoft documentation: Common problems with two-factor verification and your work or school account
Before using Legacy MFA, you'll need to do the following:
In Microsoft 365, legacy authentication can't make use of MFA. When you set a user to an "Enforced" state, anything that uses legacy authentication will no longer work.
Ideally, you aren't using legacy authentication and this doesn't pose an issue. Follow the steps outlined here to determine if that is the case. If you find that there is legacy authentication in use, first explore if it is possible to modernise the causes.
If that isn't possible, as you are using Legacy MFA, you have another option: app passwords. App passwords essentially allow you to create a more secure (long randomly generated) password, for use with legacy applications, that bypasses an MFA requirement.
The downside of this though is that users will have to generate the passwords themselves, complicating the setup process. You'll need to follow the steps in this guide to allow users to generate app passwords and then add these instructions to your user comms when talking about enrolling for MFA.
Depending on your requirements, you could permit only certain MFA methods. Microsoft defaults to sensible and secure options: app notification, app code or hardware token. We recommend keeping these defaults unless you have a good reason.
If you do need to change these settings, you must do so via the legacy MFA portal, as described here.
Want to learn more about MFA methods and choosing the right option for you? Read more on our blog.
Before enforcing MFA, you should aim to get most users registered for MFA to avoid disruption but figuring out who needs to register and engaging with each of them is a hugely time-consuming process.
Use the Push platform to quickly see who hasn't registered for MFA yet and use ChatOps to engage with them automatically to get it done with ease.
As you are using legacy, per-user MFA, you could configure users who have already registered for MFA as "Enforced" so they will be required to use MFA for future logins. Use the Push platform to quickly get a view of users that have registered for MFA.
Alternatively, if you want to force registration for users, you could set them to "Enabled", which forces them to register, but will not disrupt their existing workflow. Once registered, users will automatically transition over to "Enforced".
Follow the steps in this guide to learn more and configure your desired approach.
