Welcome to my series of DOs and DON’Ts in Entra ID. This is intended as a series of posts which is short and straight to the point.

This time I want to address something I see frighteningly often in customers tenants: MFA requirements for users in Conditional Access are only applied to specified users and groups, and only outside of the office network.

DO:

When configuring Conditional Access, make sure you have a “catch-all” rule to make sure the default behavior is MFA required for all users, any time, any place.

• Users: All users (if your accounts are synced from local AD you must exclude Directory sync service accounts)
• Target resources: All apps
• Grant: Require MFA
• Enable policy: ON

That’s all it takes to make sure users must have MFA configured unless something else is specified

DON’T:

Another thing I face all the time is the request to exempt office network from MFA requirement. While I can somewhat understand the reasoning behind it, it is very important to understand that when it comes to cloud services there are no “safe” networks to log in from. Whether your users log in to your tenant from behind a firewall or not is irrelevant. Their accounts is the single must important part to protect because practically all access is based on the account, not the network location.

Another reason why you should never exempt your office network from your Cond.Access rules is that if your end up with a large amount of accounts in the cloud where MFA is not configured, and they are therefore very susceptible for hijacking. Several times have I found accounts where MFA is configured to a phone number in a completely different part of the word, and the end-user is oblivious since he/she never needs to use MFA anyway.

Here are three examples of how this looks in the Microsoft Security center:

Or in percent if you prefer: 79%, 98% and 62% respectively of the user accounts are not protected and are practically up for grabs!

Yes, I know there are registration campaigns and MFA registration policies to help getting users to register their security confirmation without enforcing MFA, but in all honesty they don’t work as well as enforcing MFA through a Cond.Access policy. And users should anyway always be hit with a Cond.Access policy that may require MFA when they log in.