Last week, Microsoft announced that the Azure AD conditional access baseline policies will not make it out of their current preview status. The functionality of the baseline policies will be made in available in a new feature called “Security Defaults”, Microsoft will remove the baseline policies on February 29th, so if you are using them you need to take action in order to make sure to keep their functionality in place. Here is what you need to know.

I’ve discussed the baseline policies in part 5 of my blogpost series “Conditional Access Demystified“, while they provided a welcome addition, one of the main disadvantages of the baseline policies in its current preview form was that there was no option to exclude accounts from the policy, which was in contradiction with the best practice for break glass accounts and therefore made the policies not usable in some scenario’s.

If you browse to the Conditional Access Policies page now you will now receive the following notification

Warning displayed on the conditional access policies page

As a “replacement” for the intent of the baseline policies Microsoft has introduced the concept of Security Defaults, which are enabled by default for each newly created tenant already.

Microsoft explains the security defaults as following: “Security defaults provide secure default settings that we manage on behalf of organizations to keep customers safe until they are ready to manage their own identity security story.” For now when the security defaults are enabled the following security settings are enforced:

  1. Requiring all users and admins to register for MFA.
  2. Challenging users with MFA – mostly when they show up on a new device or app, but more often for critical roles and tasks.
  3. Disabling authentication from legacy authentication clients, which can’t do MFA.

Since security defaults are enabled for newly created tenants by default they will provide a good security baseline for new customers, which is actually good news since many customers are still not using any form of MFA and have the “old” default option (which is nothing at all) enabled.

If you want to create advanced scenario’s though, for example by introducing the concepts I explained in my “Conditional Access Demystified” blogpost series, Security Defaults isn’t the solution for you. Microsoft in that case recommends to disable the security defaults, and to use Conditional Access to create similar (and more advanced) functionality.

Enabling or disabling the security defaults

You can find the option to enable or disable security defaults hidden as a link under your Azure AD Active Directory properties.

Machine generated alternative text:
Enable Security defaults 
Security defaults is a set of basic identity security mechanisms 
recommended by Microsoft. When enabled, these 
recommendations will be automatically enforced in your 
organization. Administrators end users will be better protected 
from common identity related attacks. 
Learn more 
Enable Security defaults 
Enable or disable Security defaults

If you already have Conditional Access policies created within your environment and try to enable the Security defaults you’ll be presented with the following error: “It looks like you have custom Conditional Access and Classic policies enabled. Enabling these policies prevents you from enabling Security defaults.

Error when enabling security defaults if CA policies are active

Replacing your Security baseline policies with self-created conditional access policies

The following baseline policies will be removed by Microsoft, and should be replace by your self-created equivalent:

  1. Baseline policy: Require MFA for admins (Preview)
  2. Baseline policy: Require MFA for Service Management (Preview)
  3. Baseline policy: Block legacy authentication (Preview)
  4. Baseline policy: End user protection (Preview)

In order to transform from the baseline policies to your self-created policies you can use the guidance to create them yourself provided by Microsoft:

  1. Conditional Access: Require MFA for administrators
  2. Conditional Access: Require MFA for Azure management
  3. Conditional Access: Block legacy authentication
  4. Conditional Access: Risk-based Conditional Access

I recommend creating the policies, and to enable the “Report-only” functionality first before deciding to enable your newly created policies and disabling the baseline policies. I’ve blogged about the report only functionality here: Report-only mode, and some more handy reporting functionality for Conditional Access and Azure AD


While having security defaults enabled by default for newly created tenants is a must have nowadays, the fact that Microsoft is deprecating the baseline policies brings up some mixed feelings. Personally I would prefer to have the common conditional access policies already created but not enabled in all tenants as baseline policies.

If you are using the baseline policies you need to start planning the transition to self-created policies as soon as possible. Be careful here and make sure that you reduce the impact by testing the possible outcome of your created policies first by using the report only option first.