Conditional Access is one of the most important security controls available in Microsoft 365. It sits between your users and every cloud app in your tenant - deciding whether to allow access, require MFA, block entirely, or apply other conditions based on signals like sign-in risk, device compliance, location, and which app is being accessed.
A tenant with no Conditional Access policies is relying entirely on passwords to protect everything. Given how often credentials get stolen through phishing, that is not a position you want to be in. This guide walks through setting up the policies that matter most, in the right order, without locking anyone out in the process.
How Conditional Access Works
💡 ConceptsEvery Conditional Access policy is built from the same structure: assignments (who and what the policy applies to) and access controls (what happens when the conditions are met). When a user signs in, Entra ID evaluates every enabled policy and applies the most restrictive grant control that matches.
Policies are evaluated at the point of authentication, not at set-up time. Adding a policy takes effect immediately for any new sign-in attempts - existing sessions are not affected until the token refreshes.
Before You Start
📋 PrerequisitesConditional Access requires Microsoft Entra ID P1 at minimum (included in Microsoft 365 Business Premium, E3, E5). Risk-based policies require P2 (E5 or Microsoft Entra ID P2 add-on).
Before enabling any policy in enforcement mode, confirm:
- MFA registration is complete for all users (or at least near-complete). A policy requiring MFA will block anyone who has not registered yet.
- You have a break-glass account excluded from all policies.
- Service accounts and shared mailboxes used by automation are identified - they need separate handling or exclusions.
Policy 1: Require MFA for All Users
🔒 MFA EnforcementThis is the baseline. Every sign-in to any cloud app requires MFA unless already satisfied by a compliant device or other trusted signal.
Policy 2: Block Legacy Authentication
🚫 Block Legacy AuthLegacy authentication protocols (SMTP AUTH, IMAP, POP3, older Office clients) cannot perform MFA. Any attacker with a stolen password can authenticate through these protocols regardless of your MFA policy. Block them.
Policy 3: Block High-Risk Sign-Ins
🚫 Risk PolicyRequires Entra ID P2. When Entra ID Identity Protection detects a high-risk sign-in (anonymous proxy, impossible travel, known malicious IP), block it outright or require MFA plus password change.
Policy 4: Require Compliant Device
🛠️ Device ComplianceRequires Intune device compliance policies to be in place. Once configured, this policy only allows access to company resources from devices that pass compliance checks (BitLocker enabled, AV running, OS patch level met, etc.).
Policy 5: Protect Admin Accounts
🛡️ Admin ProtectionAdmin accounts are the highest-value target in any Microsoft 365 tenant. Apply stricter controls to anyone holding a privileged role - require a compliant device, no persistent browser sessions, and always-on MFA regardless of trusted location.
Always Use Report-Only Mode First
✅ TestingEvery policy should be created in Report-only mode before switching to enforcement. Report-only evaluates what the policy would have done without actually blocking or requiring anything. Review the results in the Sign-in logs under the "Conditional Access" tab for each entry.
A typical test cycle: create in report-only, leave for 48-72 hours, review logs for unexpected blocks (look for legitimate users who would have been denied), adjust exclusions, then switch to On.