How to Disable Security Defaults in Microsoft 365?

6.2K

Security Defaults are a set of policies that provide baseline identity security for Microsoft 365 tenants. They replaced the older Baseline Protection policies.

As excellent as it is, the Security Defaults are not a one-size-fits-all set of policies. In most cases, organizations prefer to customize their security policies, which requires disabling the Security Defaults. And that’s what we’ll show you in this article.

What Protections Do the Security Defaults Provide?

Security Defaults enable the following settings in the Microsoft Entra tenant:

• Multi-factor authentication for admins and users (a request to configure MFA appears on each user sign-in);
• Legacy authentication protocols are blocked, preventing clients and applications that do not support modern authentication from accessing Microsoft Entra-protected resources;
• Device code flow is blocked;
• Force MFA for privileged accounts in Microsoft Entra ID when accessing management tools that use Azure Resource Manager (ARM), such as the Microsoft Azure portal, Azure PowerShell, and Azure CLI.

Why Disable the Security Defaults?

If the Security Defaults are an excellent way to protect your tenant and users, why would you disable them?

Unfortunately, Security Defaults offer an all-or-nothing approach when enforcing policies. Not every organization will find this kind of policy enforcement suitable.

Legacy Applications and Authentication

Note that some legacy apps may not support modern authentication/Conditional Access requirements. Before disabling Security Defaults, you should identify these apps and determine whether they can be upgraded, replaced, or migrated to a supported authentication method.

You should not treat disabling Security Defaults should as a recommendation to restore legacy authentication. Legacy authentication does not support modern MFA controls and remains a significant identity security risk.

In case a legacy app cannot immediately be modernized, document the dependency and evaluate an appropriate migration/compensating-control strategy.

Microsoft-managed Conditional Access Policies

In case you disable Security Defaults, we recommend you to immediately replace their protections with Conditional Access policies.

For organizations with Microsoft Entra ID P1 or P2, Microsoft provides Microsoft-managed Conditional Access policies that can preserve the core protections provided by Security Defaults without requiring you to create every policy manually.

These policies can include:

• Block legacy authentication;
• Block device code flow;
• Require MFA for adms;
• Require MFA for all users;
• Require MFA for Azure management;
• Require phishing-resistant authentication for admins, where available.

Microsoft-managed policies are created and maintained by Microsoft and appear under Entra ID → Conditional Access → Policies. They can be reviewed and enabled by admins, and Microsoft continues to update them as security guidance evolves.

Before disabling Security Defaults, you should review the available Microsoft-managed policies and any existing custom Conditional Access policies. Ensure that the required protections are enabled before removing the Security Defaults baseline.

If you need more customization than a Microsoft-managed policy allows, you can duplicate the policy and config the copy as a standard Conditional Access policy.

Conditional Access Licensing Requirements

Keep in mind that Conditional Access requires Microsoft Entra ID P1/P2 licensing. The licensing requirement applies to the users covered by Conditional Access policies. 

Common Microsoft 365 plans that include Microsoft Entra ID P1 include Microsoft 365 Business Premium and Microsoft 365 E3. Microsoft 365 E5 includes Microsoft Entra ID P2.

Before disabling Security Defaults, you need to check if the required licenses are assigned to the users who will be covered by your Conditional Access policies.

Prepare an Emergency Access Account

Before disabling Security Defaults, we recommend to maintain two cloud-only emergency access (break-glass) accounts permanently assigned the Global Administrator role. You should reserve these accounts for emergency cases where normal admin accounts cannot sign in/have been accidentally locked out.

Here is how the best practices look like:

• Use two separate cloud-only accounts;
• Generate strong, unique credentials;
• Exclude the accounts from Conditional Access policies when required for emergency recovery;
• Store credentials securely;
• Monitor sign-ins and audit activity;
• Test the accounts periodically.

How to Disable Security Defaults in Microsoft 365 using the Microsoft Entra Admin Center

The first and most used method to turn on or off the Security Defaults is through the Microsoft Entra Admin Center, and here’s how you can do it.

1. Log in to the Microsoft Entra Admin Center.
2. Navigate to Identity → Overview → Properties and click the Manage security defaults link.
   

   

3. Select Disabled from the dropdown box, choose a reason for disabling, and click Save.
   

   

4. Click Disable on the confirmation prompt.
   

   

The Security Defaults status has changed to “Your organization is not protected by security defaults.”

You can go back to Identity → Overview → Properties at any time in order to check if Security Defaults are enabled/disabled.

What Happens After Disabling Security Defaults?

So, what happens when you disable Security Defaults?

• Multi-factor authentication (MFA) is no longer automatically enforced for users and administrators;
• Legacy authentication is no longer blocked by Security Defaults;
• Administrator accounts are no longer automatically protected by the built-in Security Defaults policies;
• Users may be able to sign in using less restrictive authentication methods unless other security controls are configured.

Important. If you disable Security Defaults, we recommend you to replace them with Conditional Access policies/other security controls to maintain the security of your Microsoft 365 tenant.

Note. Security Defaults and related authentication settings may require time to propagate across Microsoft 365 services. If you do not see the expected result immediately after enabling/disabling Security Defaults, give it some additional time for the changes to take effect before troubleshooting.

Deploy Conditional Access Gradually

If you plan to replace Security Defaults with Conditional Access policies, you should consider deploying the new policies in Report-only mode first.

Report-only mode allows you to evaluate how policies would affect users without actually blocking access.

After reviewing the sign-in logs and confirming that the policies work as expected, you can switch them to On mode and then disable Security Defaults.

Account Registration and SSPR

When replacing Security Defaults with Conditional Access, you should also review how Conditional Access applies to authentication-method registration and self-service password reset (SSPR).

Microsoft has updated Entra ID so that Conditional Access policies are enforced more consistently during credential registration. You should therefore test not only normal app sign-ins, but also:

• MFA and authentication-method registration;
• passkey registration;
• password reset and SSPR;
• registration of authentication methods on managed and unmanaged devices;
• identify applications and devices that use device code flow;
• verify that blocking device code flow does not interrupt legitimate business cases;
• config narrowly scoped Conditional Access exceptions only when required.

Include these cases in your Report-only testing before enabling the production Conditional Access policies.

How to Disable Security Defaults in Microsoft 365 using Microsoft Graph PowerShell

If you prefer to do things in PowerShell, you can also disable the Security Defaults using the Microsoft Graph PowerShell.

1. Install the Microsoft Graph PowerShell module on your computer. Skip this step if it is already installed.
   

   # Install for the current user profile
   
   Install-Module Microsoft.Graph -Scope CurrentUser

   
   

   # Install for all users
   
   Install-Module Microsoft.Graph -Scope AllUsers

2. Connect to the Microsoft Graph PowerShell:
   

   Connect-MgGraph -TenantId "contoso.onmicrosoft.com" -Scopes Policy.ReadWrite.SecurityDefaults,Policy.Read.All

   Before querying or modifying Security Defaults, check if your Microsoft Graph session is active:
   

   Get-MgContext

   Alternatively, you can run the command:
   

   Get-MgOrganization

   
3. Run this command to get the current state of the Security Defaults:
   

   Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Format-List

   

   As you can see below, the IsEnabled value is True, which means that Security Defaults is enabled.

4. Run this command to disable the Security Defaults:
   $params = @{
   IsEnabled = $false
   }
   Update-MgPolicyIdentitySecurityDefaultEnforcementPolicy -BodyParameter $params
   

   The command returns nothing if the operation is successful.

5. Further, confirm by getting the current Security Defaults status:
   

   Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Format-List

   

Checking Security Defaults Status Only

If you only need to check if Security Defaults are enabled/disabled, you can return just the status value:

(Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy).IsEnabled

The command returns one of the following values: True (Security Defaults are enabled) or False (Security Defaults are disabled).

You can use this method in PowerShell scripts, for monitoring, and during quick tenant security audits.

Re-Enabling Security Defaults

If you need to restore the default Microsoft Entra security protections, you can re-enable Security Defaults using Microsoft Graph PowerShell:

$params = @{
    IsEnabled = $true
}

Update-MgPolicyIdentitySecurityDefaultEnforcementPolicy -BodyParameter $params

The command returns no output if the operation is successful.

You can also check the current status by running:

(Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy).IsEnabled

If the command returns True, Security Defaults are enabled.

Note. Keep in mind that re-enabling Security Defaults may affect existing authentication and Conditional Access configs. You should review your tenant security settings before making changes.

Monitor Sign-Ins After Disabling Security Defaults

After disabling Security Defaults, you should closely monitor authentication activity in your tenant.

Here are the recommended monitoring tasks:

• Reviewing Microsoft Entra sign-in logs;
• Monitoring failed sign-in attempts;
• Identifying legacy authentication usage;
• Reviewing Conditional Access policy impact;
• Monitoring risky users and risky sign-ins if Identity Protection is available.

Regular monitoring helps you to ensure that disabling Security Defaults does not introduce unintended security gaps.

Microsoft MFA Requirements

Microsoft continues to expand mandatory MFA requirements for admin access to Microsoft cloud services.

Even if Security Defaults are disabled, you may still be subject to Microsoft-enforced MFA requirements for certain management operations and services.

Because of this, you should not view disabling Security Defaults as removing all MFA requirements from the tenant.

Note. Disabling Security Defaults doesn’t bypass Microsoft’s mandatory MFA enforcement for supported admin portals. If your tenant is included in Microsoft’s rollout, you may still be required to complete MFA when accessing those services.

Passkeys and the changing MFA experience

Microsoft is moving Microsoft Entra ID toward phishing-resistant authentication. Starting September 1, 2026, Microsoft began rolling out passkeys as the default phishing-resistant authentication experience for users who are enabled for SMS or voice authentication. As the rollout reaches a tenant, eligible users may be prompted to register a passkey during MFA registration or sign-in.

Therefore, you should not treat disabling Security Defaults as a decision about whether the organization should use passwords, SMS, or voice MFA. You should plan their authentication strategy around phishing-resistant methods (such as passkeys or FIDO2 security keys) and use Conditional Access authentication strength policies where appropriate.

SMS and Voice MFA Changes

Microsoft is also changing how SMS and voice-based MFA is delivered. In case your organization still require SMS or voice authentication for regulatory, technical, or operational reasons, you should plan for the new telecom-provider model. Starting October 30, 2026, organizations that need to continue using SMS/voice authentication must select and config a supported telecom provider through the Microsoft Security Store.

In case your organization relies on SMS/voice MFA, you need to identify affected users and apps, select a supported provider, and test the new config before the transition deadline.

You should prefer phishing-resistant authentication methods (such as passkeys or FIDO2 security keys where possible) for new deployments.

Enterprise note. In case your organization uses Conditional Access Custom Controls to integrate a third-party MFA provider, you should plan to migrate to External MFA. Microsoft is retiring Custom Controls on September 30, 2026, with end of life planned for May 2027. Existing Custom Controls configs continue to work during the transition period, but in new deployments you should use External MFA instead.

Wrapping up

While the Security Defaults offers optimal access policies for your Microsoft 365 users and apps, it is not for everyone. Some organizations will need to customize their access policies and cannot do so until Security Defaults are disabled.

The good news is it is relatively simple to disable the Security Defaults, whether in the Entra Admin Center or from the Microsoft Graph PowerShell.