Before enabling MFA to users, you should configure a few settings in the MFA admin portal.
These settings allow you can choose which verification method to use or how much time the device will be remembered.
These settings must be configured and tested to make sure that users will not be affected by misconfiguration.
The important settings that include the service settings are:
Trusted IPs – Administrators of a managed or federated tenant can use the Trusted IPs feature to bypass two-step verification for users who sign in from the company intranet.
App passwords – Use the app password feature to enable an application to bypass Multi-Factor Authentication and continue working.
Remember Multi-Factor Authentication for trusted devices and browsers –  Use this feature to remember trusted devices and browsers for a set number of days after a user has successfully signed-in by using Multi-Factor Authentication.
Verification methods – Use this feature to select the list of authentication methods that users can use.
Tip: if you’re planning to use Azure AD conditional access, you need to know that few settings cannot be configured besides.

Trusted IPs

The Trusted IPs feature of Azure MFA is used by administrators of a managed or federated tenant.
The feature is available with the full version of Azure MFA and not the free version for administrators.
Managed – Specific range of IP addresses: Administrators specify a range of
IP addresses that can bypass two-step verification for users who sign in from
the company intranet.
Federated – All Federated Users: All federated users who sign in from inside
the organization can bypass two-step verification.
The users bypass verification by using a claim issued by Active Directory Federation Services (AD FS).
End-user experience internal – When the Trusted IPs feature is
disabled, two-step verification is required for browser flows.
App passwords are required for older rich client applications.
When the Trusted IPs feature is enabled, two-step verification is not required for browser flows.
App passwords are not required for older rich client applications, provided that the user hasn’t created an app password. After an app password is in use, the password remains required.
End-user experience external – Regardless of whether the Trusted IPs
feature is enabled, two-step verification is required for browser flows. App
passwords are required for older rich

App passwords

Some legacy applications, such as Office 2010 or earlier. Don’t support two-step verification.
The apps aren’t configured to accept a second verification. To use these applications, take advantage of the app passwords feature.
You can use an app password in place of your traditional password to allow an app to bypass two-step verification and continue working.
Modern authentication is supported for the Microsoft Office 2013 clients and later.
Office 2013 clients, including Outlook, support modern authentication protocols and can work with two-step verification. After the client is enabled, app passwords aren’t required for the client.
There are a few considerations about app passwords. When using app passwords, consider the following important points:
App passwords are only entered once per application. Users don’t have to keep track of the passwords or enter them every time.
The actual password is automatically generated and is not supplied by the user. The automatically generated password is harder for an attacker to guess and is more secure.
There is a limit of 40 passwords per user.
Applications that cache passwords and use them in on-premises scenarios can start to fail because the app password isn’t known outside the work or school account.
An example of this scenario is Exchange emails on-premises, but the archived mail is in the cloud.
After MFA is enabled on a user’s account, app passwords can be used with most non-browser clients like Outlook and Microsoft Skype for Business.
Administrative actions can’t be performed by using app passwords through non-browser applications, such as Windows PowerShell.
Tip: App passwords don’t work in hybrid environments where clients communicate with both on-premises and cloud auto-discover endpoints.
To enable or disable App passwords, choose one of the options.

Verification methods

You can choose the verification methods available for your users by using the selectable verification methods feature.
The following table provides a brief overview of the methods.
When your users enroll their accounts for Azure Multi-Factor Authentication, they choose their preferred verification method from the options that you have enabled.

Remember trusted devices

The remember MFA feature for devices and browsers trusted by the user is a free feature for all Multi-Factor Authentication users.
Users can bypass subsequent verifications for a specified number of days after they’ve signed-in successfully to a device by using Multi-Factor Authentication.
The features enhance usability by minimizing the number of times a user has to perform two-step verification on the same device.
The remember Multi-Factor Authentication feature sets a persistent cookie on the browser when a user selects the Don’t ask again for the X days option at sign-in.
The user isn’t prompted again for Multi-Factor Authentication from that same browser until the cookie expires.
If the user opens a different browser on the same device or clears their cookies, they’re prompted again to verify.
Please don’t ask again for the X days option isn’t shown on non-browser applications, regardless of whether it supports modern authentication.
These apps use refresh tokens that provide new access tokens every hour. When a refresh token is validated, Azure AD checks that the last two-step verification occurred within the specified number of days.
The feature reduces the number of authentications on web apps, which normally prompt every time.
The feature increases the number of authentications for modern authentication clients that normally prompt every 90 days.