How to Disable Security Defaults in Microsoft Entra

Security defaults in Microsoft Entra provide a foundational level of identity protection by automatically enforcing multi-factor authentication (MFA) for all users and blocking legacy authentication protocols. In managed environments, moving to advanced, granular identity controls requires turning off this baseline feature. With the Microsoft Entra admin center, you can initialize this modification centrally from the tenant properties.

This guide walks through safely disabling security defaults—including mandatory preparation steps—to prepare your environment for custom Conditional Access deployments.

CRITICAL WARNING – READ THIS FIRST

Disabling security defaults is not a casual configuration change. It is a security-critical operation that, if done incorrectly, can:

1. Lock you out of your own tenant (if your replacement Conditional Access policies are misconfigured).
2. Leave your tenant completely unprotected (if you disable defaults before your new policies are active).

You should only proceed if you have read and understood the entire guide. Do not skip steps.

Prerequisites

Before beginning this migration, ensure you have the following:

• Role: Your account must hold the Global Administrator role.
• Licensing: You must have Microsoft 365 Business Premium or standalone Entra ID P1 licenses assigned to unlock full Conditional Access capabilities.

Why Disable Security Defaults?

Controlling baseline security states at the tenant level helps with:

1. Conditional Access migration: Security defaults cannot coexist with Conditional Access. You must disable the defaults to build and enforce custom, context-aware access policies tailored to your organization.
2. Break-glass accounts: Security defaults force MFA on all administrative accounts without exception. Disabling them allows you to configure securely excluded emergency access (break-glass) accounts via Conditional Access.
3. Service account compatibility: Certain legacy service accounts or third-party API integrations may require specific exclusions from MFA prompts, which is impossible under the rigid structure of security defaults.

Important Licensing & Deadline Information

There are critical upcoming Microsoft deadlines regarding baseline security and authentication protocols:

What You’ll Configure

You will:

1. Prepare your tenant by creating emergency break-glass accounts and staging replacement policies in safe “Report only” mode.
2. Verify everything is working.
3. Disable security defaults.
4. Activate your new Conditional Access policies.

Before You Begin: Understand the Risk

If you disable security defaults without a working replacement policy, your tenant will have NO MFA enforcement and NO legacy authentication blocking. This can happen within seconds of clicking “Save”. Your new Conditional Access policies may take 15–60 minutes to become active, leaving a dangerous gap.

The safe approach is to stage and test your policies before disabling defaults, then flip the switch with minimal exposure.

Step 1: Create Break-Glass Accounts (Do This First)

Break-glass accounts are emergency access accounts that can bypass all Conditional Access policies. You must create at least two of them and store the credentials securely.

Best Practice: Use a .onmicrosoft.com domain for these accounts and ensure they are cloud-only (not synced from on-premises AD). This guarantees access even if your AD Connect or federation services fail.

Why two? Microsoft recommends at least two break-glass accounts. If one fails or is compromised, you have a backup.

Using PowerShell (Recommended)

Open an elevated PowerShell 7 session and run the following script:

# Connect to Microsoft Graph with necessary permissions
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All", "Policy.ReadWrite.ConditionalAccess"

# Create first break-glass account (replace with your tenant name)
# Ensure this password meets your tenant’s default complexity requirements (typically 14+ characters)
$password = "YourVeryStrongComplexPassword123!@#"   # Change this!

$user1Params = @{
    AccountEnabled = $true
    DisplayName = "Emergency Access 1"
    MailNickname = "emergency1"
    UserPrincipalName = "emergency1@yourtenant.onmicrosoft.com"
    PasswordProfile = @{
        Password = $password
        ForceChangePasswordNextSignIn = $false
    }
}
New-MgUser @user1Params

# Add the account to the Global Administrator role
$role = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
$userId = (Get-MgUser -Filter "userPrincipalName eq 'emergency1@yourtenant.onmicrosoft.com'").Id

$DirObject = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
}
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

# Repeat the above steps for a second account (e.g., emergency2@yourtenant.onmicrosoft.com)

# Connect to Microsoft Graph with necessary permissions
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All", "Policy.ReadWrite.ConditionalAccess"

# Create first break-glass account (replace with your tenant name)
# Ensure this password meets your tenant’s default complexity requirements (typically 14+ characters)
$password = "YourVeryStrongComplexPassword123!@#"   # Change this!

$user1Params = @{
    AccountEnabled = $true
    DisplayName = "Emergency Access 1"
    MailNickname = "emergency1"
    UserPrincipalName = "emergency1@yourtenant.onmicrosoft.com"
    PasswordProfile = @{
        Password = $password
        ForceChangePasswordNextSignIn = $false
    }
}
New-MgUser @user1Params

# Add the account to the Global Administrator role
$role = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
$userId = (Get-MgUser -Filter "userPrincipalName eq 'emergency1@yourtenant.onmicrosoft.com'").Id

$DirObject = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
}
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

# Repeat the above steps for a second account (e.g., emergency2@yourtenant.onmicrosoft.com)

Store these credentials safely – write them down and keep them in a locked safe or a trusted password manager that is accessible even if your Entra ID is locked.

Step 2: Stage Your Conditional Access Policies in Report Only Mode

Before disabling security defaults, build your replacement policies in a safe, non-enforcing mode.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Identity → Protection → Conditional Access.
3. Click + New policy.
4. Under Enable policy, select Report only (this is critical – it will not block anyone).
5. Configure your policy settings. At a minimum, create the following two policies:

6. Exclude your break-glass accounts from every policy. Under Users → Exclude, select your two emergency access accounts.
7. Save the policy.

Testing: Run the policies in Report-only mode for 24–48 hours. Navigate to Conditional Access → Insights and reporting → Report-only to review the potential impact before enforcement. This is your safety net.

Alternative Step 3: Use Microsoft Managed Policies (Optional)

If you want a middle ground between basic security defaults and building everything from scratch, Microsoft now offers Microsoft managed Conditional Access policies.

Note: If you choose to use managed policies, you can skip building the custom policies in Step 2.

1. In the Conditional Access blade, look for the Microsoft managed policies tab.
2. Review the pre-configured policies (e.g., “Require MFA for admin portals”, “Block legacy authentication”).
3. Enable the ones that match your needs. These policies are already optimized for most tenants.

Step 4: Verify the Security Defaults Status

Before making any change, check your current status via PowerShell:

# Connect to Microsoft Graph (if not already connected)
Connect-MgGraph -Scopes "Policy.Read.All"

# Get current Security Defaults status
$securityDefaults = Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy
Write-Host "Security defaults are currently: $($securityDefaults.IsEnabled)"

# Connect to Microsoft Graph (if not already connected)
Connect-MgGraph -Scopes "Policy.Read.All"

# Get current Security Defaults status
$securityDefaults = Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy
Write-Host "Security defaults are currently: $($securityDefaults.IsEnabled)"

If the output is True, you are ready to proceed with the migration.

Step 5: Disable Security Defaults

Only perform this step after your replacement policies are staged, tested, and ready to be turned on.

1. In the Entra admin center, go to Identity → Overview → Properties.
2. Scroll to the bottom and click Manage security defaults.
3. In the flyout pane, change the toggle from Enabled to Disabled.
4. Select a reason (e.g., “My organization is using Conditional Access”).
5. Click Save.

Step 6: Immediately Turn On Your Conditional Access Policies

Do not leave MFA enforcement disabled for longer than necessary. There will be a brief window (typically 5–15 minutes) where neither security defaults nor your new policies are active – minimize this by acting quickly.

1. Go back to Protection → Conditional Access.
2. For each policy you staged, open it and switch Enable policy from Report only to On.
3. Click Save for each policy.

Step 7: Verify the Migration

Test with a non-administrator test user (do not use your break-glass accounts):

1. Sign in from a new browser or private window. You should be prompted for MFA.
2. Attempt to authenticate using a legacy protocol (e.g., an old Outlook client without modern auth). It should be blocked.
3. Check the Conditional Access Sign-in logs in Entra admin center → Monitoring → Sign-in logs to verify the policy results.

Troubleshooting: What If Something Goes Wrong?

Wrap Up

You can safely disable security defaults for your Microsoft 365 tenant by first creating break-glass accounts, staging replacement Conditional Access policies in Report-only mode, and only then modifying the tenant-wide baseline settings. Ensure you hold Global Administrator rights and understand the upcoming Microsoft deadlines (June 30, 2026, for mandatory security defaults on new tenants; December 31, 2026, for legacy authentication deprecation).