Portfolio Post

Conditional Access: Require a Compliant Device

This lab blocks Microsoft 365 access unless the device is marked compliant, then tests the result with one compliant device and one non-compliant device.

Date

25 April 2026

Focus

Conditional Access, compliance, Microsoft 365

Platform

Microsoft Entra ID / Intune

Outcome

Compliant device allowed, non-compliant device blocked

Why this mattered: MFA and geoblocking are a good start, but they do not prove the device is safe. A user can still reach business data from a machine with weak security controls unless Conditional Access checks device compliance.

Summary

Most companies with Microsoft 365 Business Premium should already be using Conditional Access for at least the basics, such as MFA or location-based blocking. The issue is that this still may not be enough if the device itself is unhealthy.

For example, if a user signs in from a Windows 11 laptop with no BitLocker or Secure Boot, they may still be able to access business data unless a conditinal access is enforced. This lab adds that missing layer.

Goal

  • Create a Conditional Access policy that blocks access to Microsoft 365 apps when the device is not compliant.
  • Test the policy with one compliant device and one non-compliant device.
  • Use the existing compliance policy from my earlier tenant setup write-up.
  • Confirm that a device failing BitLocker and Secure Boot cannot access company data.

Policy setup

I went to entra.microsoft.com, opened Conditional Access, and created a new policy called CMW - Require Compliant Device for Microsoft 365 - User.

I did not want to roll this out to everyone in one go, so I scoped it to a pilot group first. In this test, that pilot group represents HR.

  • Users: selected pilot HR group.
  • Target resources: all cloud apps.
  • Grant: require device to be marked as compliant.
  • Testing users: Daniel Evans and Darren Smith.

Test scenario

Daniel and Darren are both in the HR pilot group, so the same Conditional Access policy applies to both of them. The difference is the device they are using.

  • Darren: using a brand new compliant machine.
  • Daniel: using a non-compliant computer that fails because of BitLocker and Secure Boot requirements.

Result

Darren was able to access his mailbox normally because his device met the compliance requirements. Daniel was blocked with a compliance message because his device did not meet the organisation's device requirements.

This is exactly the behavior I wanted. The policy protects Microsoft 365 data by checking both the user and the device state before allowing access.

Outcome

This lab showed why compliance-based Conditional Access is such a useful step beyond basic MFA. MFA can prove the user is likely who they say they are, but device compliance helps prove the endpoint is in a healthy enough state to handle company data.

It also reinforced why staged rollout matters. A policy like this can block users quickly if compliance is misconfigured, so testing with a pilot group first is the better way to build confidence before expanding to the whole company.

Screenshots

Click any screenshot to enlarge it.

Screenshot 1. Conditional Access policy configured to require a compliant device for Microsoft 365 access.
Screenshot 2. HR pilot group containing Daniel Evans and Darren Smith.
Screenshot 3. Daniel is blocked on a non-compliant device while Darren can access Outlook on a compliant device.