AD1.4 Conditional Access: Your First Three Policies

5-6 hours · Module 1 · Free

Operational Objective

Conditional access is the policy engine that controls every authentication to your M365 tenant. Instead of relying on Microsoft's risk engine to decide when to challenge for MFA (security defaults), you define the rules: who is required to do what, under which conditions, for which applications. This subsection walks you through building the three policies that replace security defaults and close the identity gaps — MFA for all users, block legacy authentication, and require compliant devices for sensitive applications. Each policy is built step by step with the exact portal clicks, the blast radius analysis, and the testing procedure.

Deliverable: Three production-ready conditional access policies deployed in your environment, with break-glass exclusions, tested from multiple devices, and validated through sign-in logs.

Estimated completion: 45 minutes

Figure AD1.4 — The three conditional access policies that replace security defaults. CA001 enforces MFA deterministically. CA002 eliminates the legacy auth bypass. CA003 blocks unmanaged devices from accessing sensitive apps. Together they provide stronger identity protection than security defaults with granular control over every authentication.

Building CA001: Require MFA for all users

Navigate to entra.microsoft.com → Protection → Conditional Access → Policies → New policy.

Name: CA001 - Require MFA - All Users

Assignments — Users: Click “Users” → Include → Select “All users.” Click Exclude → Select “Users and groups” → select your break-glass account group (the group containing your two emergency access accounts). This exclusion is critical — without it, if Microsoft Authenticator has an outage or your MFA methods stop working, you’ll have no way to sign in.

Assignments — Target resources: Click “Target resources” → Include → Select “All cloud apps.” Don’t try to be clever and only target Exchange or SharePoint — the attacker will find an unprotected app and use it as a pivot point. All cloud apps means every sign-in requires MFA.

Conditions: Leave all conditions at default. You don’t want to filter by location, device platform, or client app for this policy — MFA should be required everywhere, always, on everything.

Grant: Click “Grant” → Select “Require multifactor authentication.” Click “Select.”

Session: Leave at default.

Enable policy: If you’ve completed the registration campaign from AD1.3, set this to “On.” If you want to verify the impact first, set it to “Report-only” and check the sign-in log for what would have been enforced before switching to “On.”

Click “Create.”

One important detail about the policy naming convention: prefix every policy name with “CA” followed by a three-digit number. This ensures your policies sort predictably in the portal list and gives you a clear reference when discussing policies with colleagues or documenting them in your policy register. CA001, CA002, CA003 is the pattern. If you add more policies later, continue the sequence — CA004 for named location restrictions, CA005 for application-specific controls.

The moment this policy is active, security defaults will be automatically disabled. Every sign-in to any cloud app by any user (except your break-glass accounts) will require MFA. Users who have already registered will be prompted with their configured method. Users who haven’t registered will be forced to register before they can proceed.

Verification: Sign out and sign back in. You should be prompted for MFA. Check the sign-in log for your sign-in and look for “Conditional access: CA001 - Require MFA - All Users” in the conditional access evaluation. The status should show “Success” with “Grant control: Require multifactor authentication: Satisfied.”

Testing your policies thoroughly

Deploying a conditional access policy and hoping it works is not validation. You need to test each policy from multiple angles to confirm it behaves correctly in every scenario your users will encounter.

Test 1 — Standard user sign-in. Sign in from your corporate device using a standard user account (not an admin). You should be prompted for MFA by CA001. After completing MFA, you should have full access. Check the sign-in log: CA001 should show “Success” with MFA satisfied.

Test 2 — Break-glass account. Open a private browser window. Sign in with one of your break-glass accounts. You should NOT be prompted for MFA — break-glass accounts are excluded from all policies. Check the sign-in log: CA001 should show “Not applied” because the break-glass account is in the exclusion group. If CA001 shows “Success” with MFA required, your exclusion is misconfigured — fix it immediately before you get locked out.

Test 3 — Legacy authentication. If you have a way to test IMAP authentication (Thunderbird configured for IMAP, or a PowerShell script using basic auth), try it after deploying CA002. The connection should fail with an authentication error. Check the sign-in log filtered by “Client app: IMAP4” — you should see CA002 with status “Failure: Blocked by conditional access.”

If you can’t test IMAP directly, monitor the sign-in log for 48 hours after deploying CA002. Filter by legacy client apps. Any entries showing “Failure: Blocked by conditional access” confirm the policy is working. Any entries showing “Success” via a legacy protocol mean the policy has a gap — recheck the client app condition settings.

Test 4 — Report-only policy. After deploying CA003 in report-only mode, sign in from a device that isn’t enrolled in Intune (a personal phone or tablet). Check the sign-in log: CA003 should show “Report-only: Would have blocked” or “Report-only: Would have required compliant device.” This tells you the policy would enforce if it were active — without actually blocking the user. Review these “would have blocked” entries over 14 days to understand your enforcement blast radius before switching CA003 to “On.”

Test 5 — Combined policy evaluation. The sign-in log shows the evaluation result for EVERY enabled conditional access policy on every sign-in. A single sign-in from a corporate device should show: CA001 — Success (MFA satisfied), CA002 — Not applied (modern auth client, not legacy), CA003 — Report-only (device compliance status). All three policies are evaluated simultaneously, and all must pass for the sign-in to succeed.

Building CA002: Block legacy authentication

This is the policy that closes the biggest gap in security defaults. Legacy authentication protocols — IMAP, POP3, SMTP Basic Auth, Exchange ActiveSync with basic auth — don’t support MFA. An attacker with a phished password can authenticate via IMAP and bypass MFA entirely. This policy blocks all legacy authentication, eliminating the bypass.

Prerequisites: You must have resolved your legacy auth dependencies from the audit in AD1.3. If you still have users on Outlook 2013, printers using SMTP basic auth, or applications using IMAP, those will break when this policy is enabled. Resolve them first. If you can’t resolve them immediately, deploy this policy in report-only mode and track the impact.

Navigate to entra.microsoft.com → Protection → Conditional Access → Policies → New policy.

Name: CA002 - Block Legacy Authentication

Assignments — Users: Include → All users. Exclude → your break-glass account group.

Assignments — Target resources: Include → All cloud apps.

Conditions: Click “Conditions” → Client apps → Configure: Yes → Select ONLY: “Exchange ActiveSync clients” and “Other clients.” Deselect “Browser” and “Mobile apps and desktop clients.” This filter ensures the policy only applies to legacy authentication protocols, not modern authentication.

Grant: Select “Block access.” Click “Select.”

Enable policy: If your legacy auth audit showed zero usage in the last 30 days, set to “On.” If you found dependencies, set to “Report-only” and monitor for 14 days before switching to enforcement.

Click “Create.”

Verification: The best verification is the sign-in log. Navigate to Monitoring → Sign-in logs. Filter by “Client app” → select the legacy options. After enabling this policy, any legacy auth attempt should show “Conditional access: CA002 - Block Legacy Authentication” with status “Failure” and reason “Blocked by conditional access.” If you see successful sign-ins via legacy auth after enabling the policy, the policy configuration has an error — check the client app condition settings.

Building CA003: Require compliant device (report-only mode)

This policy is the defense against AiTM token replay. Even if an attacker captures a fully authenticated session token through an AiTM proxy, the token is useless if the conditional access policy requires the device to be enrolled in Intune and meeting compliance requirements — because the attacker’s device isn’t enrolled.

This policy starts in report-only mode because it has the highest blast radius. Any user signing in from a personal device, a new device that hasn’t been enrolled, or a device that’s fallen out of compliance will be blocked. You need data before enforcement.

Navigate to entra.microsoft.com → Protection → Conditional Access → Policies → New policy.

Name: CA003 - Require Compliant Device - Core Apps

Assignments — Users: Include → All users. Exclude → your break-glass account group.

Assignments — Target resources: Include → Select apps → search for and select: “Office 365 Exchange Online,” “Office 365 SharePoint Online,” and “Microsoft Teams.” Don’t target “All cloud apps” for this policy — that would block access to the My Apps portal and other registration endpoints, creating a chicken-and-egg problem where users can’t enroll their device because they can’t access the enrollment portal.

Conditions: Leave at default.

Grant: Select “Require device to be marked as compliant” OR “Require Microsoft Entra hybrid joined device.” Select the “Require one of the selected controls” option so either condition satisfies the requirement. This covers both Intune-enrolled cloud devices and hybrid-joined on-premises domain devices.

Enable policy: Set to “Report-only.” Do not enable enforcement until you have Intune compliance policies configured (covered in Module AD4) and you’ve validated that 95%+ of devices would pass.

Click “Create.”

Monitoring in report-only mode: Navigate to the sign-in log and add a filter for “Conditional access: Report-only: Failure.” This shows sign-ins that WOULD have been blocked if the policy were enforced. Review the list: how many users sign in from non-compliant devices? Are they corporate devices that need Intune enrollment, or personal devices that need an alternative access method (browser-only with app-enforced restrictions)? This data shapes your enforcement plan.

Expand for Deeper Context

The three policies you’ve built follow a principle called defense in depth — each one addresses a different attack vector, and together they create overlapping layers of protection. CA001 stops attackers who have the password but no MFA method. CA002 stops attackers who have the password and try to bypass MFA through legacy protocols. CA003 stops attackers who have the password AND have completed MFA (via AiTM) but are using an unmanaged device.

The layering matters because it raises the cost of attack at each step. Without MFA, the attacker needs only a password (cost: almost zero for spray/stuffing). With MFA, the attacker needs the password plus a way to bypass MFA (cost: AiTM toolkit, more sophisticated phishing). With device compliance, the attacker needs the password plus MFA bypass plus a managed device (cost: physical compromise of a corporate device or advanced malware that can inject into the device trust chain). Each layer doesn’t need to be perfect — it needs to make the attack significantly harder and more expensive.

Conditional access also provides a single point of policy enforcement that you can audit. Every sign-in is evaluated against every enabled policy, and the evaluation is logged in the sign-in log. You can answer the question “was MFA required for this sign-in?” by checking the log, not by hoping the risk engine made the right decision.

Compliance Myth: "Conditional access is too complex for a small IT team to manage"

You just built three policies in this subsection. That's the entire baseline. Once these three policies are active, you won't touch them again for months unless you're adding a new exception or responding to a specific issue. Conditional access complexity comes from organisations building 50+ granular policies for different user groups, applications, and conditions. Three policies covering all users, all apps, with break-glass exclusions is not complex — it's three rules that cover the entire identity attack surface. Maintenance is minimal: check the sign-in log weekly for unexpected blocks, review exceptions quarterly, and update policies when your environment changes.

Decision point

You’ve deployed CA001 (MFA for all users) and CA002 (block legacy auth). A developer reports that their automated testing pipeline, which authenticates to Microsoft Graph API using client credentials (client ID + client secret), has stopped working. They say “your MFA policy broke our CI/CD pipeline.” Is this true?

Option A: Yes — the MFA policy is blocking the service principal’s authentication. Exempt the service account from MFA.

Option B: No — client credential flow (service-to-service authentication) is not a user sign-in and is not affected by conditional access policies targeting users. The pipeline failure is caused by something else.

The correct answer is Option B. Conditional access policies targeting “All users” apply to user sign-ins, not service principal authentications using client credential flow. Service principals authenticate with app-only tokens using client secrets or certificates — there’s no user context, so user-targeted policies don’t apply. The developer’s pipeline failure is coincidental with your policy deployment. Investigate the actual error — it’s likely an expired client secret, a Graph API permission change, or a network connectivity issue. Don’t create unnecessary MFA exemptions based on an incorrect attribution.

Try it: Build your first conditional access policy

If you have an M365 E3 tenant with admin access, build CA001 right now. Navigate to entra.microsoft.com → Protection → Conditional Access → Policies → New policy.

Before you click “Create,” verify three things:

Your break-glass accounts exist and are in the exclusion group
The exclusion group is added to the “Exclude” section of the Users assignment
The policy is set to “Report-only” if you want to verify impact first, or “On” if you’ve completed the registration campaign

After creating the policy in report-only mode, sign in from a different browser or device. Check the sign-in log for your sign-in. Look for the “Conditional access” tab in the sign-in details — it should show CA001 with a result of “Report-only: Not applied” (because it’s in report-only mode) alongside what the result WOULD have been (“Would have required: Multifactor authentication”).

If you see this, your policy is working correctly and you can switch it to “On” when you’re ready to enforce.

You've enabled CA001 (MFA for all users) and CA002 (block legacy auth). A user signs in from their personal phone using the Outlook mobile app. Which conditional access policies apply?

CA001 applies (MFA required). CA002 does not apply because the Outlook mobile app uses modern authentication, not legacy authentication — Correct. The Outlook mobile app uses OAuth 2.0 (modern authentication), so it's not affected by the legacy auth blocking policy. The user is prompted for MFA by CA001 and, if they complete it, they can access their email. CA003 (device compliance) would apply if it were enabled — the personal phone may not be enrolled in Intune.

Both CA001 and CA002 apply — the user is blocked because their personal phone isn't compliant — No. CA002 only applies to legacy authentication client apps. The Outlook mobile app uses modern auth. CA003 (device compliance) is in report-only mode, so it wouldn't block even if it applied. Only CA001 applies, requiring MFA.

Neither policy applies because the user is on a mobile device — No. Conditional access policies apply regardless of device type. Mobile devices, desktops, and browsers are all subject to the policies you've configured.

CA001 applies and blocks the user because personal devices aren't allowed — No. CA001 requires MFA, not a specific device type. The user can complete MFA from a personal device. Device restrictions come from CA003 (when enforced) or from app protection policies in Intune.

Operational Artifact — Conditional Access Policy Configuration Reference

The three policies built in this subsection — CA001 (MFA), CA002 (legacy auth block), CA003 (device compliance in report-only) — are your baseline conditional access deployment. Document them in a policy register with: policy name, purpose, users included/excluded, apps targeted, conditions, grant controls, and the date deployed. Review this register quarterly. When anyone asks "what does our conditional access do?" the register answers the question without requiring a portal login. When you onboard a new IT team member, the register tells them what's in place and why.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous Next →