AD0.4 Security Defaults vs Conditional Access

What security defaults actually do

Security defaults are Microsoft’s answer to the problem of tenants running with no MFA at all. Before security defaults existed (they were introduced in 2019), new M365 tenants had no MFA enforcement unless the administrator explicitly configured it. Millions of tenants ran without any second-factor authentication for years. Security defaults changed that by providing a pre-configured set of identity protections that activate automatically.

When security defaults are enabled, every user in the tenant is required to register for MFA within 14 days of their first sign-in. Users are prompted for MFA when Microsoft’s risk engine determines a sign-in is risky — which includes sign-ins from new devices, new locations, and after detected credential leaks. All users with administrator roles are required to complete MFA on every sign-in. And certain legacy authentication protocols that can’t support MFA are blocked.

This is genuinely useful. Security defaults prevent the majority of commodity credential attacks — password spraying, credential stuffing from breach databases, and basic phishing. Microsoft reports that tenants with security defaults enabled experience 99.9% fewer compromised accounts than tenants without any MFA. That’s a real and significant improvement from a zero-configuration control.

The gaps security defaults leave

The problem is what security defaults don’t do. They provide probabilistic MFA enforcement, not deterministic. Microsoft’s risk engine decides when to challenge for MFA, which means some sign-ins from compromised credentials might not trigger a challenge. You have no control over this decision — Microsoft’s algorithms make it, and you can’t see or influence the criteria.

Security defaults don’t enforce device compliance. An attacker who passes MFA from an unmanaged personal device gets the same access as an employee on a corporate laptop. There’s no requirement for the device to be encrypted, up to date, or managed by Intune. This means a stolen session token can be replayed from any device anywhere in the world.

Security defaults don’t block all legacy authentication. They block some legacy protocols for some scenarios, but the blocking is not comprehensive. Conditional access provides a deterministic “block all legacy authentication” policy that catches every protocol that doesn’t support modern authentication — IMAP, POP3, SMTP Basic Auth, Exchange ActiveSync with basic auth, and older Office clients.

Security defaults don’t provide location-based controls. You can’t restrict sign-ins to specific countries, block sign-ins from known-bad IP ranges, or require additional verification for sign-ins from outside your office network. Conditional access provides all of these through named locations and location-based policy conditions.

Security defaults can’t be customised per group, per application, or per user. They apply uniformly to the entire tenant. If a particular application needs stricter access controls, or a particular user group needs different MFA requirements, security defaults can’t accommodate that. Conditional access policies can target specific users, groups, applications, and conditions.

When to graduate from security defaults to conditional access

The short answer: as soon as possible. Security defaults are the safety net. Conditional access is the actual security architecture. Every day you run on security defaults is a day your tenant has gaps that conditional access would close.

The practical answer: graduate when you can commit 2-3 hours to build three initial conditional access policies and test them. That’s the time investment in Module AD1. You don’t need to build a complex policy set on day one. Three policies — require MFA for all users, block legacy authentication, and require compliant devices for sensitive applications — cover the majority of the gap between security defaults and a properly configured tenant.

The prerequisite is understanding your environment well enough to know what will break. Before you disable security defaults and enable conditional access, you need to know which users are still using legacy email clients (they’ll be blocked), which applications require legacy authentication (they’ll stop working), and which devices aren’t enrolled in Intune (they won’t be compliant). This is the operational knowledge that Module AD1 teaches you to gather before you make the switch.

Pre-transition verification: the four checks

Before you touch security defaults, run these four checks to understand your environment’s readiness.

Legacy authentication audit. This is the check that prevents the most breakage. In PowerShell:

1
2
3
4
5
6
7
8

Connect-MgGraph -Scopes "AuditLog.Read.All"
$start = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $start" -Top 500 |
    Where-Object { $_.ClientAppUsed -in @("exchangeActiveSync","imap4","pop3",
        "smtp","authenticatedSmtp","other") } |
    Group-Object UserPrincipalName |
    Select-Object Name, Count |
    Sort-Object Count -Descending

Each user in this output is using a legacy protocol that doesn’t support MFA. Before you block legacy auth, each one needs migration: upgrade their email client, reconfigure their application, or plan an exception.

MFA registration gaps. Check which users haven’t registered:

1
2
3

$report = Get-MgReportAuthenticationMethodUserRegistrationDetail
$report | Where-Object { $_.IsMfaRegistered -eq $false -and $_.UserType -eq "member" } |
    Select-Object UserPrincipalName, IsMfaRegistered, DefaultMfaMethod

Each unregistered user will be forced to register on their first sign-in after conditional access is enabled. Contact them proactively to avoid helpdesk calls.

Intune enrollment gaps. Check device enrollment in the Intune admin center → Devices → All devices. Compare the enrolled count against your total device count from the M365 Admin Center → Devices → Active devices. The gap represents devices that won’t meet the “compliant device” requirement if you enable CA003 in enforcing mode.

Admin account inventory. List all privileged role holders:

1
2
3
4
5
6
7
8

$roles = Get-MgDirectoryRole
foreach ($role in $roles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
    if ($members.Count -gt 0) {
        Write-Host "`n$($role.DisplayName):" -ForegroundColor Cyan
        $members | ForEach-Object { Write-Host "  $($_.AdditionalProperties.userPrincipalName)" }
    }
}

Review every account with an admin role. Remove roles from accounts that don’t need them. Disable accounts that belong to former employees or expired consultants. This is a zero-cost security improvement you should do before building conditional access.

The transition itself is a single switch: when you create your first conditional access policy and enable it, Microsoft automatically disables security defaults. There’s a brief moment where both systems are technically active during the transition, but the key point is that once conditional access is on, security defaults are off. Your conditional access policies must cover everything that security defaults previously provided — specifically, MFA enforcement. If you enable a conditional access policy that only targets admins and forget to create one for all users, you’ve just removed MFA for everyone except admins.

The three policies that replace security defaults

When you graduate from security defaults to conditional access, you need three policies at minimum to maintain the protection security defaults provided and close the gaps it left. Module AD1 walks through building each of these step by step, but understanding what they are now helps you plan the transition.

Policy one: require MFA for all users, all cloud apps, all conditions. This replaces the MFA enforcement that security defaults provided. The difference is that conditional access enforces MFA deterministically on every sign-in, not probabilistically based on Microsoft’s risk assessment. You control the policy, you can see who’s challenged and who’s not, and there are no gaps based on risk engine decisions.

Policy two: block legacy authentication for all users, all cloud apps. This closes the biggest gap in security defaults. Legacy protocols like IMAP, POP3, and SMTP Basic Auth don’t support MFA. An attacker with a phished password can authenticate via IMAP and bypass MFA entirely. Blocking legacy authentication eliminates this bypass completely. Before enabling this policy, you need to check your sign-in logs for any users or applications still using legacy protocols — Module AD1 shows you how.

Policy three: require compliant or managed devices for sensitive applications. This adds a control that security defaults don’t provide at all. Even if an attacker has valid credentials and completes MFA, they can’t access Exchange Online, SharePoint, or Teams from a device that isn’t enrolled in Intune and meeting your compliance requirements. This stops token theft, session replay, and access from stolen devices.

Together, these three policies provide stronger protection than security defaults across all three dimensions: identity (deterministic MFA), protocol (legacy auth blocked), and device (compliance required). The investment is 2-3 hours of configuration and testing. The return is a fundamentally more secure environment.