As you hopefully already know, Entra ID Conditional Access (CA) is the primary tool for managing Identity security in Entra ID. Conditional Access is a security feature that evaluates various signals (user identity, device health, location, application and several other sources) to determine whether to grant or restrict access to resources. Think of it as an “if-then” function: if certain conditions (signals) are met, then a decision is made and access is allowed, or additional security measures are enforced. This helps ensure that only authorized users and compliant devices can access sensitive data, enhancing overall security. This process is depicted by Microsoft below.

Conditional Access can access signals from Microsoft Intune, Entra Identity protection, Purview and many other products to perform this evaluation. However, it has one fundamental flaw, I’ll explain it and show you how to address it.

😱The fundamental problem!

Conditional Access’s main flaw is that it allows all logins by default without additional protection. So in short: If you attempt to log in to M365, with no Conditional Access policies, you can log in from anywhere in world, from any device, access any application/information with no protection except your username and password. This emphasizes the critical necessity of ensuring that every login is covered by at least one Conditional Access policy, as any login outside the scope of these policies remains unprotected.

Let me elaborate:

By default, no Conditional access rules exist. So typically an admin starts creating several policies to meet different challenges or requirements, for example:

• Require MFA on all Admin accounts
• Block legacy protocols
• Require MFA on user accounts
• Require MFA for guest accounts (They need MFA too!)
• etc.

Microsoft also provide some templates for Conditional Access policies to help you get started. Although it’s a decent beginning, it doesn’t address the core problem: Unless you are VERY meticulous in scoping your policies, you will have gaps in your policy coverage. And because of the default behavior: Gaps in policy coverage = no protection

☠️ And to make matters even worse….

…please be aware that if a user is not affected by any Conditional Access policies, they will by default never be asked to set up MFA on their account! (Unless SSPR or other services provide this requirement.) This will leave their account extremely susceptible for hijacking, and I’ve been to so many customers where I find exactly this scenario! The criticality of the MFA adoption in your tenant can not be overstated!

So what is “MFA adoption” and how do I check it?

To help illustrate MFA adoption, think of it like this:

Imagine you have top-secret physical documents that need to be stored securely in a room. You must close and lock every door leading into this room. Each door represents one of your user/guest accounts. So, if you have 500 users and guests in your tenant, it’s as if the room has 500 doors that all need to be locked.

Depending on if a user or guest has an MFA method set up or not on their account, the door looks like this:

WITH MFA:

WITHOUT MFA:

Notice that the door representing a user with MFA is still open, and this is a very important point: Configuring an MFA method on the account is only the first step! You still need to close the door and then lock it! And this is the job of Conditional Access policies!

Now, luckily it is very easy to do a quick check of the MFA adoption in your tenant. Just log in to the Entra portal and navigate to Protection -> Authentication Methods -> Activity or use this direct link. Look for “Users capable of Azure multifactor authentication” which will give you an easy statistic of how many of your users and guests who has MFA configured on their account. This should give you a rough idea of your situation.

❓What does this number mean❓

Now using this example in the analogy from above, this means that the imaginary room with the top-secret physical documents has 5503 doors (accounts including guests) leading into it, and only 2753 of those doors can be locked (the left picture). The remaining 2750 doors can’t be locked (the right picture).

This illustrates how critically important it is to secure ALL accounts, and without a complete Conditional Access policy coverage you will have “doors” which can’t be locked at all. And yes, a guest account is also a “door” which must be closed and locked.

The solution (short version):

Since the underlying issue is the default behavior, then the solution is to change the default behavior. Unfortunately, there are no settings to change the default behavior of Conditional Access, so we have to be a little creative with our policies to achieve the same effect. Here I like to cast a quick glance to common setup of firewalls: They lock down everything by default and only allowed traffic (exceptions) can pass through. So why don’t we apply the same principal to our Conditional Access design?

In short we will change: “Unless anything else is specified, any user can log on from anywhere, on any device, access any resource without MFA.” to “Unless anything else is specified, you are blocked from logging in.” And all we need is some clever use of Conditional Access policies, some Entra ID security groups and a Restricted admin unit (RAU)

To help us with this, I’ve used Microsoft’s own framework for Conditional access and applied it to my own solution, which gives us a similar framework which is better in several ways:

• It is much better scaled for smaller environments, Microsoft tend to focus on very large enterprise environments.
• It implements a default rule which will block ALL sign-ins unless explicitly granted access
• Each exception from the “block-all” rule, is systematically assigned one or more policies to enforce at least one policy for every single login to the tenant. This is what I refer to as a “baseline” policy and I explain it more in part 2.
• You must specify the user accounts who are allowed to log in to your tenant. If you want and/or need, you can grant this access on a per-user basis resulting in total control over which accounts can log in. Access to your tenant can be like a turnstile on the picture below.

All you need is 5 simple steps and they are:

1. Identify your personas and set your naming standard
2. Establish corresponding Entra ID groups
3. Configure the block-by-default rule (without locking yourself out)
4. Systematically assign policies to the personas and exceptions
5. Hardening using Restricted Administrative Units (RAU)

Conclusion

In conclusion, setting up Conditional Access correctly is vital for enhancing your security posture, especially since it directly affects your MFA adoption. However, its default behavior can cause unexpected and undesirable results.

So stay tuned for Part 2 which will be published in just a few days. I’ll walk you through how to harden your Conditional Access setup through the 5 steps I just mentioned.

Until then:

• Check your MFA adoption! Don’t assume, use the link provided earlier and verify it!
  • How many “doors” do you have and how of those many can be locked?
• Start thinking about your tenant, what different kind of users do you have and what requirements can and must be applied to them?
• If you haven’t already: Back up your Conditional Access policies!
• Stay tuned to agderinthe.cloud and consider subscribing (it’s free) so you don’t miss out!

SEE YOU IN PART 2