Exercise - Build and verify a risk-based, device-compliant Conditional Access policy

  • 12 minutes

Woodgrove Bank's security review deadline is here, and you're finishing the front-door lockdown for Relecloud's engineering team: a Conditional Access policy that only lets compliant, MFA-verified sign-ins through. You've just learned how multiple Conditional Access policies interact and how modern vs. legacy authentication clients get treated differently—now build the policy and prove a legacy-auth client can't quietly bypass it.

Important

Prerequisites for this exercise:

  • A Microsoft 365 E5 tenant (or equivalent Microsoft Entra ID P2 licensing) with Conditional Access Administrator access (plus at least Reports Reader for the Sign-in logs and diagnostic).
  • The same engineering team test security group from the previous exercise, with test user accounts.
  • A test device enrolled and marked compliant (for example, via Microsoft Intune).
  • Access to both a modern authentication client (for example, a supported browser or the Outlook desktop app) and a legacy authentication client (for example, Exchange ActiveSync) for the same test user.

If your lab tenant doesn't have a legacy-auth client available to test with, complete Task 1 and Task 2's modern-client test, then read through the legacy-client comparison in Task 3.

Task 1: Build the Conditional Access policy

  1. Sign in to the Microsoft Entra admin center at entra.microsoft.com with your Conditional Access Administrator account.
  2. Select Protection > Conditional Access > Policies, then select New policy.
  3. Name the policy Engineering – Require MFA and compliant device.
  4. Under Users, include the engineering team test security group.
  5. Under Target resources, include All cloud apps.
  6. Under Grant, select Require multifactor authentication and Require device to be marked as compliant, then set For multiple controls to Require all the selected controls.
  7. Set Enable policy to Report-only first if you want to validate before enforcing, or On to enforce immediately. Select Create.

Task 2: Test with a modern authentication client

  1. Sign in as your test user from the compliant device using a modern authentication client (for example, a supported browser).
  2. Confirm the sign-in succeeds after satisfying MFA—the policy recognizes the compliant device and the MFA claim together.
  3. In the Microsoft Entra admin center, select Monitoring & health > Sign-in logs, find this sign-in event, and open its Conditional Access tab. Confirm your new policy shows as Success.

Task 3: Test with a legacy authentication client and confirm the block

  1. Attempt to sign in as the same test user using a legacy authentication client (for example, Exchange ActiveSync configured for basic authentication).
  2. Confirm the sign-in fails or is blocked—legacy authentication clients can't satisfy modern grant controls like device compliance or interactive MFA, so the policy denies them outright rather than silently letting them through.
  3. In the Sign-in logs, locate the failed event and open the Sign-in diagnostic. Confirm the diagnostic identifies the legacy authentication protocol as the reason the sign-in couldn't satisfy the policy's grant controls.
  4. Open the Conditional Access What If tool (Protection > Conditional Access > What If), configure it with the same user, app, and a legacy client platform, and run the evaluation. Confirm the What If tool reports the same policy as applying and blocking the sign-in—before you'd even need a real failed attempt to know it.
  5. Reflect: the Sign-in logs show you what already happened; the What If tool shows you what would happen for any hypothetical combination. Together they're how you prove to Woodgrove's reviewers that legacy auth can't quietly bypass the policy—not by assertion, but by evidence from both tools.

You've now built a Conditional Access policy requiring both MFA and device compliance, confirmed a modern client sails through it, and used the Sign-in logs, Sign-in diagnostic, and What If tool together to prove a legacy-auth client is blocked—Relecloud's front door is locked down for Woodgrove's review.