Conditional Access Baseline for Every Tenant

Introduction

In today's interconnected digital landscape, identity is the new perimeter. Protecting access to your organization's resources is paramount, and Microsoft Entra Conditional Access (CA) stands as a foundational pillar in achieving this goal. This article outlines a practical and comprehensive Conditional Access baseline that every Microsoft Entra ID tenant administrator should implement. It aims to establish a robust security posture, moving beyond basic multifactor authentication (MFA) to address modern identity threats.

This guide is for IT professionals, security architects, and tenant administrators responsible for securing Microsoft 365, Azure, and other SaaS applications integrated with Microsoft Entra ID. Whether you're just starting your Conditional Access journey or looking to refine your existing policies, the principles and steps outlined here provide a actionable framework for enhanced security. Our focus will be on creating a set of policies that are both effective in mitigating risks and manageable for ongoing operations.

Why this matters

Implementing a Conditional Access baseline isn’t merely a best practice; it's a strategic imperative with tangible benefits across multiple dimensions. From a security perspective, it significantly reduces the attack surface by enforcing strong authentication and access controls based on real-time signals. This directly combats phishing, password spray attacks, and unauthorized access attempts, which are among the most common initial compromise vectors.

Beyond security, Conditional Access delivers substantial business value. It aids in achieving compliance with various regulatory frameworks (e.g., GDPR, HIPAA, CMMC) by providing auditable controls over resource access. The cost implications of a security breach, including reputational damage, financial penalties, and operational disruption, far outweigh the investment in proactive security measures like CA. Furthermore, by ensuring that legitimate users can access resources securely and efficiently, CA contributes to productivity. It strikes a balance between security and user experience by dynamically adjusting access requirements based on risk, preventing unnecessary friction for trusted users while imposing stricter controls when suspicion arises, aligning perfectly with Zero Trust principles.

Key concepts

• Microsoft Entra Conditional Access (CA): A policy-based access control engine that evaluates various signals (e.g., user, location, device) to make real-time decisions on whether to grant, deny, or restrict access to resources.
• MFA (Multifactor Authentication): A security system that requires two or more independent methods of verification to grant access to a resource. Conditional Access is key to enforcing MFA in a granular way.
• Named Locations: Predefined IP address ranges or countries/regions that can be marked as trusted or untrusted and used as conditions in CA policies. This helps in controlling access based on geographic origin.
• Compliance Policy (Intune/Microsoft Purview): Rules defined in Microsoft Intune or Microsoft Purview that devices must meet to be considered "compliant." CA can then require compliant devices for access.
• Terms of Use: A prompt presented to users before accessing specific applications, requiring them to accept the terms before proceeding. CA policies can enforce this.
• Session Controls: Actions that can be enforced after a user gains access, such as requiring app enforced restrictions (e.g., block downloads) or using Microsoft Defender for Cloud Apps session policies for real-time monitoring and control.
• Report-only Mode: A deployment option for CA policies that allows administrators to evaluate the impact of policies without enforcing them. This is crucial for testing and preventing unintended access issues.

Step-by-step implementation

1. Plan and document existing access patterns: Before implementing, understand who needs access to what, from where, and on which devices. Use the Conditional Access "Report-only" mode and the Workbook for Conditional Access insights to gather data on current access patterns.
2. Define named locations:

Navigate to the Entra admin center (`https://entra.microsoft.com`). Go to Protection > Conditional Access > Named locations. Create `IP ranges locations` for your corporate network(s) and any trusted VPN exit points. Consider creating Countries/Regions locations to block access from high-risk or unnecessary geographies.

1. Establish a baseline MFA policy:

Create a policy requiring MFA for all users (excluding emergency access accounts) and all cloud apps. Exclude your designated emergency access (break-glass) accounts from this policy. Initially deploy in Report-only* mode for monitoring.

1. Implement device compliance/hybrid Azure AD join requirement:

Configure device compliance policies in Microsoft Intune or ensure your devices are Hybrid Azure AD joined. Create a Conditional Access policy requiring access from compliant devices or Hybrid Azure AD joined devices for sensitive applications or when outside trusted networks.

1. Block legacy authentication:

Create a policy applying to All users and All cloud apps, but specifically targeting Client apps > Other clients. Set the Grant control to Block access. This prevents authentication from older protocols susceptible to attacks.

1. Require reauthentication frequency:

* Create a policy for sensitive apps (e.g., Exchange Online, SharePoint Online) that enforces a maximum sign-in frequency. This can significantly reduce the duration of an active session if a user's token is compromised.

1. Emergency Access (Break-Glass) Account Exclusion: Always exclude a small, strictly controlled set of emergency access accounts from all Conditional Access policies. These accounts should be highly monitored and only used in emergencies.

# Connect to Microsoft Graph PowerShell using the correct scope
# Ensure you have the Microsoft.Graph.Identity.SignIns module installed: Install-Module Microsoft.Graph.Identity.SignIns

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Application.Read.All", "Directory.Read.All", "User.Read.All"

# Define a baseline MFA policy (example: All users, All apps, require MFA)
# This example creates a policy to enforce MFA for all users on all cloud apps
# Deploy in Report-only mode first!

$locations = Get-MgIdentityConditionalAccessNamedLocation | Where-Object {$_.DisplayName -eq "All Locations"} # Or specify your trusted locations
$allApps = Get-MgServicePrincipal -Filter "appId ne null" # Get all cloud apps

$policyName = "CA001 - Require MFA for All Users and Apps (Report-only)"
$policyDescription = "Baseline policy to enforce MFA for all users interacting with all cloud applications, excluding break-glass accounts."

$conditions = @{
    users = @{
        includeUsers = @("All")
        excludeUsers = @("$((Get-MgUser -Filter "UserPrincipalName eq 'breakglassadmin@yourtenant.onmicrosoft.com'").Id)") # Replace with your break-glass account UPN
    }
    applications = @{
        includeApplications = @("All")
    }
    clientAppTypes = @("all")
}

$grantControls = @{
    operator = "OR"
    builtInControls = @("mfa")
}

$policy = @{
    displayName = $policyName
    description = $policyDescription
    state = "reportOnly" # Set to "enabled" after thorough testing
    conditions = $conditions
    grantControls = $grantControls
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $policy
Write-Host "Conditional Access policy '$policyName' created in Report-only mode."

Example configuration

This JSON snippet illustrates a Conditional Access policy tailored to block legacy authentication protocols. This is a critical security measure as these protocols often lack support for modern authentication features like MFA and are highly vulnerable to credential stuffing and brute-force attacks.

{
  "displayName": "CA002 - Block Legacy Authentication",
  "description": "Blocks access from applications using legacy authentication protocols (e.g., Exchange ActiveSync, POP, IMAP).",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": [
        "All"
      ]
    },
    "applications": {
      "includeApplications": [
        "All"
      ]
    },
    "clientAppTypes": [
      "other"
    ]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ]
  }
}

Common pitfalls

• Excluding Too Many Users/Groups: Overly broad exclusions, especially for administrative roles, create significant security gaps. granularly apply exclusions only where absolutely necessary.
• Not Using Report-Only Mode: Deploying policies directly to "Enabled" without prior testing using "Report-only" mode can lead to accidental lockouts for legitimate users, causing operational disruption.
• Ignoring Emergency Access Accounts: Failing to define and exclude break-glass accounts from all CA policies can lead to a complete tenant lockout if an unforeseen issue with CA or other services occurs.
• Overlapping or Conflicting Policies: Multiple, poorly planned policies can unintentionally conflict, leading to unpredictable access behavior or users being locked out. Use logical naming conventions and test thoroughly.
• Neglecting to Address Legacy Authentication: Leaving legacy authentication enabled is a major security vulnerability, as these protocols are often unable to enforce MFA and are prime targets for attack.
• Assuming Mobile Device Management (MDM) Alone is Enough: While MDM is important for device health, Conditional Access needs to explicitly check for device compliance state or Hybrid Azure AD Join status through its own conditions for robust security.

Best practices

• Implement a phased rollout: Always start with "Report-only" mode, analyze the impact, then slowly roll out to small user groups before full deployment. This aligns with the "assume breach" and "assume compromise" principles of Zero Trust.
• Define emergency access accounts: Create 2-3 highly privileged, cloud-only accounts, exclude them from all CA policies, store their credentials securely, and monitor their usage rigorously (Microsoft Learn: Emergency Access Accounts).
• Utilize a naming convention: Establish a clear and consistent naming convention for your CA policies (e.g., CA001 - PolicyName - Scope - Action) to improve management and troubleshooting.
• Regularly review and refine policies: Security and business requirements evolve. Periodically review your CA policies (at least quarterly) to ensure they remain relevant and effective. Leverage the Conditional Access Workbook in Azure Monitor.
• Educate users: Inform users about MFA, device compliance requirements, and why these policies are in place to foster understanding and adherence, reducing help desk calls.
• Block legacy authentication: As a fundamental Zero Trust principle, explicitly block legacy authentication protocols to remove a common attack vector (Microsoft Learn: Block Legacy Authentication).

Further reading

• What is Conditional Access?
• Plan a Conditional Access deployment
• Conditional Access common policies
• Configure emergency access administrators
• Using report-only mode for Conditional Access