How many Conditional Access policies you can create?

Is there a reason for this article?

There is always a reason to write on Conditional Access but for this specific topic, decided to write when I got results from a Poll I created out of the blue, asking the following.

And after I saw the results, decided to explore this deeper in this article. From the numbers we can see that the answers were divided between the choices surprisingly evenly.

Well, first let’s see those Managed policies and how they fit the play.

Microsoft-managed policies

By default you have two Microsoft-managed policies and one more if you have Entra ID Plan 2

Here is a list of the policies and what they do.

Policy	Who it’s for	What it does
Require multifactor authentication for admin portals	All customers	This policy covers privileged admin roles and requires multifactor authentication when an admin signs into a Microsoft admin portal.
Require multifactor authentication for per-user multifactor authentication users	Existing per-user multifactor authentication customers	This policy applies to users with per-user multifactor authentication and requires multifactor authentication for all cloud apps. It helps organizations transition to Conditional Access.
Require multifactor authentication for high-risk sign-ins	Microsoft Entra ID Premium Plan 2 customers	This policy covers all users and requires multifactor authentication and reauthentication during high-risk sign-ins.

Removing them all

When we have a tenant with policies, it’s great but if we want to remove them all, it’s ClickOps, except it isn’t.

Thanks to DCToolbox and Remove-DCConditionalAccessPolicies module.

When you install it run the command, you can use a Prefix or Suffix filter.

Note! the filter is case sensitive and the process is unreversible.

Let’s try it on those Managed policies.

No way, you cannot remove them with Graph.

You can also turn it Off or to Report-only mode, no removal from the Portal.

How many you can?

Let’s see how many first, I’ll do it a bit easier and not with Entra portal.

Next, let’s try to create the maximum number of policies we can. Csv file with over 195 numbers and a script which read from that file and loops them through.

First we install SignIns module and with force if you have previous ones installed

Then connect to Graph with following permissions

Then we just wait, it won’t take long, ID will be generated by the command and DisplayName variable will come from the csv-file.

While it’s running, let’s check out the portal. We can see new Policies already

If you open the Audit log, you can see the process.

And even deeper, Graph client creates the policy element.

And Admin entity (super.admin) adds the Conditions inside the policy.

Then Graph client again updates the policy and combine the two.

Now the process is complete and we cWan see the limit was reached.

When you any Entra or Azure portals and try to create a new policy, you will get an error, should be saying something more than Failed to create. Nothing is even written to the Audit logs on this, maybe there should be.

So the maximum number is 195 and including 2 or 3 Microsoft-managed policies if You have Entra ID Plan 2 enabled

Let’s remove the obsolete ones then.

And now we are back to square one, all clear. Except those pesky Managed policies, just kidding. Excellent addition for your security stack with Conditional Access.

Policy Limit of 195

While the limit for Conditional Access policies is 195, it’s important to understand that this limit doesn’t refer to the content itself being “maximum.” Here’s a breakdown:

Policy Limit:

• This signifies the maximum number of Conditional Access policies you can create and store within your Entra ID tenant using Microsoft Graph and through the portal.
• There’s no inherent restriction on the complexity of each policy within this limit.

Content and Complexity:

• Each policy can have varying levels of complexity depending on the configured elements:
  • Conditions: Specify locations, user groups, devices, applications, or risk levels to trigger the policy.
  • Controls: Define access behavior like requiring MFA, device compliance, or session limitations.
  • Additional Options: You can configure session control settings, approval workflows, or continuous access evaluation (advanced).

Impact on Storage:

• The storage space for these policies in Microsoft Graph depends on the complexity of the JSON data representing each policy.
• More complex policies with numerous conditions, controls, and settings will require more storage compared to simpler policies.

Example:

Imagine two policies:

• Policy A: Requires MFA for all users accessing Microsoft 365 from unknown locations (simple).
• Policy B: Enforces MFA, device compliance, and app protection for specific user groups accessing sensitive data across various locations and applications (complex).
• Policy B will likely have a larger JSON representation due to its additional conditions and controls, resulting in slightly higher storage usage in Microsoft Graph.

Here are two approaches to get a ballpark figure, acknowledging the limitations:

Estimations

• Consider a complex policy averaging 500 bytes in JSON format. This is a hypothetical value based on examples and might be higher or lower in your environment.
• Account for some overhead (20%) for commas, brackets, and quotes, leading to an estimated size of 600 bytes per policy.
• Calculate the total storage space:

• Convert bytes to megabytes (MB):

So 195 policies would make 0.11 MB and if you count that with rounded imaginary number of 100 million, you would get 11 Terabytes.

In summary:

• The 195 policy limit focuses on the total number of policies, not the content complexity.
• Each policy can have varying complexity levels impacting its storage footprint.

Here’s what the 195 limit doesn’t mean:

• It doesn’t restrict the number of conditions, controls, or settings you can configure within a single policy.
• It doesn’t enforce a maximum size for the JSON data representing each policy.

Closure

First Microsoft is reserving from that limit of 195 a place for their Managed policies. And it seems that 195 is only artificial limit not a real one. There is no reason it should be more than 195 in my opinion. If one want’s to guess the reason could be data size but Microsoft doesn’t publicly disclose storage details for Conditional Access policies. Or maybe as performance protection as Microsoft Graph serves a vast number of Entra ID tenants, each with its own set of policies. A very high policy limit could potentially impact performance and scalability for all users.

As end conclusion, the correct answer is 195 minus Any Microsoft-managed policies.

It’s important to remember:

• The focus is on implementing effective security controls, not necessarily the number of policies.
• A well-structured set of fewer policies can achieve the same level of security as a large number of complex ones.

In the future posts we will discover how policies work and what kind of policies you should create and who to trust.