How to choose the right MFA for your organization?
Microsoft MFA has become a major focus for me as phishing and spear phishing activity has been on the rise and the attackers are getting increasingly sophisticated in their attacks.
When you create a new tenant at Microsoft 365 (and license with any package that includes Microsoft Defender) one feature is enabled by default – Security Defaults.
Security Defaults automatically enables MFA for all accounts in the tenant, enforcing modern authentication while disabling legacy authentication protocols while also setting baseline email protection policies (anti-phish, anti-spam policies.
On one hand this is a great feature. It forces you to at least consider how you’re going to implement MFA security to your organization. If you go into Azure AD though, and select the Multi-Factor Authentication above the users, a list of all users shows up showing “Disabled”. This is confusing.
The policy enabled by the Security Defaults is a sweeping policy that includes Anti-Spam and Anti-Phishing policies as well as a global MFA policy giving users 2 weeks after initial sign-in to set up MFA for their account.
There are two avenues to consider:
- Conditional Access Policies – MFA set up through Conditional Access Policies where you can set home locations, block login from outside the country (or even restrict login to specific locations), and set security layers on what users can access and when MFA is being applied. Best practice is to *always* apply but it can get noisy for the users so it pays to be judicious in how this is implemented. The downside to this option is users must hold an Entra ID P1 license in their bundle to remain compliant.
- MFA Per User – This approach gives a basic Multi-Factor Authentication option and can be enabled/disabled per user. This would be a less standardized approach and require the most administration.
It’s important to note – Per User MFA overrides a lot of Conditional Access Policies, so if you are using Conditional Access Policies ensure the user(s) have Per User MFA set to “disabled”.
You can use both, for users who don’t hold an Entra ID P1 license you can enable the Per-User MFA, but expect conflicts.
In my opinion, the best option is to use Conditional Access Policies. It ensures protection is automatic across the tenant, protection is standardized and enforced, and gives the most flexibility for management.
It’s also important to note – Management of Conditional Access doesn’t require an Entra ID P2 license, but it’s recommended. Most of the really useful features of Microsoft Conditional Access (such as Risky Sign-ons, Risky-Users, etc.) require at least one Entra ID P2 license holder.
In future posts I’ll cover the options for each method.
If you are not licensed for Conditional Access it’s recommended to leave the Security Defaults option enabled and manage users through the Per User MFA Console.
If you are licensed for Conditional Access with Entra ID P1/P2 licensing, the first thing to do is disable the Security Defaults so you can manage this yourself.
Microsoft provides updated instructions for this here:
https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults
Real-world Tip:
When piloting MFA with Conditional Access, start with report-only Conditional Access policies to measure impact before enforcing. You can review logins to see how the policies would have reacted had they been enabled and adjust accordingly before rolling out enforcement.Also, roll out enforcement by department (staged deployment) to avoid user revolt and ensures helpdesk isn’t flooded.
With Security Defaults Enabled:
The user setup itself is fairly easy and there are still plenty of options.
Navigate to the Admin console (https://admin.microsoft.com) and click on Users -> Active Users
Click on Multi-factor Authentication on the top menu bar – this open entra.microsoft.com to appropriate location.
Select the users you wish to administrate and click on Enable MFA.
The status of these users will switch from disabled to enabled and users will be prompted on next login to register and set up their MFA options.
Users who are already set to Enforced have already gone through the process and are using MFA.
The next thing to look at are the Service Options (top menu bar of the pane shows Users | Service Options). Click on Service Options.
These are the options the users will be able to set themselves (except Trusted IPs) so it’s strongly recommended you have a corporate security policy to guide you through which options should be enabled for each user.
App Passwords
App Passwords allow users to generate a long password that can be used to authenticate their account to automatically bypass MFA. I do not recommend this, and I always turn this off. App Passwords are dangerous. Anything that can be used to immediately bypass security function is strongly frowned upon. If you find yourself in a situation where your users need App Passwords, you should be re-evaluating your options.
Trusted IPs
Trusted IP’s can also skip MFA but conditionally (Hybrid or ADFS environments). Users do not see this option, so it’s safe to use local IP segments, common locations, such as the Office network, to bypass the MFA process. However, this is the Per-User MFA option only – Conditional Access utilizes Named Locations.
Personally I never use this option unless there is a lot of pushback from Management that MFA is being too noisy and intrusive to the daily operations of the staff, and only if the organization has a Static Public IP address (this should be mandatory). Recommendation – use it if necessary, but look for ways to limit session times to force users to authenticate with MFA at least once a week. Session limits can also be set on this page – explained below.
Verification Options
Call to phone – The user is ‘called’ to the registered phone number on the user account to validate that MFA is being authorized
– This is not secure but sometimes the only option for staff who refuse to allow the user of corporate apps on their personal devices
Text message to phone – Same as with Call to phone, this is not secure. For example, a user has both a phone and a tablet using the same Apple ID – the SMS will come up on both. Same as with Call to phone, this may be the only option for some reluctant users
Notification through mobile app – this is more secure, though as demonstrated with the Text message to phone option, it can come up on multiple devices.
Verification code from mobile app or hardware token – by far the most secure option. MS Authenticator would be the app of choice here, and the user would be prompted to enter the number presented on the screen to the App to validate the connection. This is per device registration so only the device authorized will be notified to push the notification to the user.
Remember multifactor authentication on trusted device
This is the session limiting you can use directly to ensure that users are validating their credentials from trusted locations/devices at least once per week. You can set the number of days users can trust device anywhere from 1 to 365 days (1 year). Recommend 7 days (at least weekly).
