Microsoft 365: Conditional Access Policies That Block Real Attacks

Conditional Access (CA) in Microsoft Entra ID (formerly Azure Active Directory) provides granular control over resource access based on various signals.…

Conditional Access (CA) in Microsoft Entra ID (formerly Azure Active Directory) provides granular control over resource access based on various signals. These signals include user identity, device state, location, application, and real-time risk. Properly configured CA policies are a fundamental pillar of a robust security posture in Microsoft 365 environments, actively preventing common attack vectors such as password spray, phishing, and compromised credentials.

This article details five critical Conditional Access policies designed to block real-world attacks, along with practical implementation guidance, configuration specifics, and best practices for safe deployment.

1. Block Legacy Authentication for All Users

Legacy authentication protocols (e.g., POP, IMAP, SMTP, older versions of ActiveSync) do not support modern security features like multi-factor authentication (MFA). This makes them a primary target for password spray and brute-force attacks. Blocking these protocols significantly reduces the attack surface.

Policy Configuration:

• Name: Block Legacy Auth - All Users
• Assignments:
  • Users or workload identities: All users
  • Cloud apps or actions: All cloud apps
• Conditions:
  • Client apps: Configure > Yes > Select "Exchange ActiveSync clients" and "Other clients (e.g., POP, IMAP, SMTP)"
• Grant: Block access
• Session: (Not configured)
• Enable policy: Report-only (initial deployment), then On.

Impact and Considerations:

• This policy will prevent older mail clients or applications that rely solely on basic authentication from connecting. Users must transition to modern authentication-capable clients (e.g., Outlook 2013 SP1+, Outlook for iOS/Android, native mail apps on recent OS versions).
• Ensure your Exchange Online organization has modern authentication enabled. This is the default for new tenants, but older tenants might need verification. Use PowerShell: Get-OrganizationConfig | Format-Table Name,OAuth2ClientProfileEnabled. If OAuth2ClientProfileEnabled is False, enable it with Set-OrganizationConfig -OAuth2ClientProfileEnabled $true.
• Communicate changes to users well in advance, providing guidance on updating their mail clients or application configurations.

2. Require MFA for All Administrative Roles

Privileged accounts are prime targets. Requiring MFA for all administrative roles is non-negotiable for security, significantly mitigating the impact of compromised admin credentials.

Policy Configuration:

• Name: MFA for Admin Roles
• Assignments:
  • Users or workload identities: Select "Directory roles" > Choose all relevant administrative roles (e.g., Global Administrator, SharePoint Administrator, Exchange Administrator, User Administrator, Application Administrator, Security Administrator, Conditional Access Administrator).
  • Cloud apps or actions: All cloud apps
• Conditions: (Optional, consider adding "Device platform" > "Any device" to ensure consistency)
• Grant: Grant access > Require multi-factor authentication
• Session: (Not configured)
• Enable policy: Report-only (initial deployment), then On.

Critical Considerations:

• Always exclude at least one "break-glass" Global Administrator account from all Conditional Access policies. This account should be highly secured, rarely used, and monitored, providing access in case of an MFA outage or configuration lock-out.
• Regularly review which users are assigned to administrative roles.

3. Require Compliant or Hybrid Azure AD Joined Device for M365 Access

This policy ensures that users can only access Microsoft 365 resources from devices that meet specific organizational security standards. A "compliant" device is registered and compliant with Intune policies; a "Hybrid Azure AD Joined" device is joined to on-premises AD and registered with Azure AD.

Policy Configuration:

• Name: Require Compliant/HAADJ Device for M365
• Assignments:
  • Users or workload identities: All users (or specific groups if phased rollout is desired)
  • Cloud apps or actions: Select "Office 365" (this covers most core M365 services)
• Conditions:
  • Device platforms: Configure > Yes > Select "Any device" (or specific platforms like Windows, macOS, iOS, Android if managed)
• Grant: Grant access > Require device to be marked as compliant & Require Hybrid Azure AD joined device (select both, then choose "One of the selected controls")
• Session: (Not configured)
• Enable policy: Report-only (initial deployment), then On.

Prerequisites and Impact:

• Device Enrollment: Users' devices must be enrolled in Microsoft Intune and comply with a defined Intune compliance policy (e.g., requiring anti-malware, OS patch level, disk encryption).
• Hybrid Azure AD Join: For Windows domain-joined devices, Hybrid Azure AD Join must be configured and functional.
• User Impact: Users accessing M365 from unmanaged personal devices or non-compliant corporate devices will be blocked. Clear communication and self-service enrollment instructions are essential.

4. Block Sign-ins from High-Risk Countries (Named Locations)

Preventing access from countries where your organization has no legitimate business operations significantly reduces the risk of geographically-based attacks, especially from known threat actor regions.

Policy Configuration:

1. Define Named Locations:
   • Navigate to Microsoft Entra admin center > Protection > Conditional Access > Named locations.
   • Create a new "Countries/Regions location" list. Name it something descriptive, like "Blocked Countries".
   • Add specific countries from which your organization expects no legitimate sign-ins.
2. Create Conditional Access Policy:
   • Name: Block Sign-ins from High-Risk Countries
   • Assignments:
     • Users or workload identities: All users
     • Cloud apps or actions: All cloud apps
   • Conditions:
     • Locations: Configure > Yes > Exclude > Select "Any location" > Include > Select "Selected locations" > Choose your "Blocked Countries" list.
   • Grant: Block access
   • Session: (Not configured)
   • Enable policy: Report-only (initial deployment), then On.

Trade-offs and Refinements:

• This policy can cause legitimate users traveling internationally to be blocked. Consider excluding specific user groups (e.g., executives who travel) or implementing a complementary policy that requires MFA for sign-ins from "risky" but not outright "blocked" countries.
• Regularly review sign-in logs for blocks from unexpected countries to refine your "Blocked Countries" list.
• Microsoft Entra ID Protection risk policies (e.g., "Sign-in from unfamiliar locations") can dynamically flag and respond to suspicious sign-ins, which is more adaptive than static geographic blocks. This CA policy complements, rather than replaces, ID Protection.

5. Require Phishing-Resistant MFA for Privileged Roles

Standard MFA (e.g., SMS, authenticator app push notifications) can be susceptible to advanced phishing and man-in-the-middle (AiTM) attacks. Phishing-resistant MFA (e.g., FIDO2 security keys, certificate-based authentication) offers a higher level of assurance, especially for critical accounts.

Policy Configuration:

• Name: Phishing-Resistant MFA for Privileged Roles
• Assignments:
  • Users or workload identities: Select "Directory roles" > Choose highest privilege roles (e.g., Global Administrator, Application Administrator, Conditional Access Administrator, Security Administrator).
  • Cloud apps or actions: All cloud apps
• Conditions: (Optional)
• Grant: Grant access > Require multi-factor authentication > Select "Require phishing-resistant multi-factor authentication".
• Session: (Not configured)
• Enable policy: Report-only (initial deployment), then On.

Prerequisites and Implementation:

• FIDO2 Security Keys: Users must be provisioned with FIDO2 security keys (e.g., YubiKey, Feitian) and have them registered in their security info.
• Authentication Methods Policy: Ensure FIDO2 Security Key authentication method is enabled in the Microsoft Entra admin center > Protection > Authentication methods > Policies.
• This policy demands a higher level of user education and hardware distribution. It's typically implemented for a smaller, high-impact group initially.
• Consider a phased rollout, starting with Global Admins and then expanding.

# Example PowerShell to enable FIDO2 Security Keys as an authentication method
# Requires AzureADPreview module (Install-Module AzureADPreview)
# Connect-AzureAD

$fido2Policy = Get-AzureADMSAuthenticationMethodPolicy -AuthenticationMethod Fido2

if ($fido2Policy -ne $null) {
    if ($fido2Policy.State -ne "Enabled") {
        # Enable the FIDO2 policy for all users
        Set-AzureADMSAuthenticationMethodPolicy -AuthenticationMethod Fido2 -State Enabled -IncludeTargetTypes "All"
        Write-Host "FIDO2 Security Key authentication method policy enabled."
    } else {
        Write-Host "FIDO2 Security Key authentication method policy is already enabled."
    }
} else {
    Write-Host "FIDO2 policy not found or an error occurred."
}

Common Pitfalls and Troubleshooting

• Exclusion of Break-Glass Accounts: Forgetting to exclude at least one highly secured "break-glass" Global Administrator account can lead to tenant lock-out if policies are misconfigured or external services (like MFA providers) experience issues.
• "Report-only" Mode Neglect: Rushing to "On" mode without sufficient time in "Report-only" mode. Always monitor sign-in logs for a minimum of one week to identify unexpected blocks.
• "What If" Tool Underutilization: The "What If" tool in Conditional Access is invaluable for simulating policy outcomes before deployment. Use it to test scenarios for different users, devices, locations, and client apps.
• Overlapping Policies: Multiple policies applying to the same user and app can lead to unexpected "block" or "grant" outcomes. Conditional Access applies all applicable policies. If any policy results in a "block," the access is denied. If multiple policies require different grant controls, all required controls must be satisfied.
• Client App Selection Confusion: Understanding the difference between "All cloud apps," "Office 365," and individual apps like "SharePoint Online" is crucial. "Office 365" is a bundle of related apps.
• Poor User Communication: Changes to access requirements (especially MFA, device compliance) without prior warning and clear instructions lead to helpdesk tickets and user frustration.
• Ignoring Microsoft Entra ID Protection Risks: While static policies are good, integrating Conditional Access with Identity Protection's user and sign-in risk detections (e.g., requiring MFA for medium/high sign-in risk) provides a dynamic, adaptive layer of security.