AD3.3 Building the Windows Compliance Policy

Creating the compliance policy step by step

Navigate to intune.microsoft.com → Devices → Compliance → Create policy → Platform: Windows 10 and later.

Name: "Windows Security Compliance — All Devices"

Compliance settings — configure each section:

Device Health:

• Require BitLocker: Require
• Require Secure Boot to be enabled on the device: Require
• Require code integrity: Require (validates the system hasn't been tampered with at boot)

Device Properties:

• Minimum OS version: Set to a version that's currently supported. For Windows 11, use 10.0.22631 (23H2) as the minimum. For environments still running Windows 10, use 10.0.19045 (22H2) — but note that Windows 10 22H2 reaches end of support in October 2025. Set the minimum to the oldest version you'll accept, not the latest version available.

Check your audit data from AD3.2 before setting this. If 15 devices are on an older version, set the minimum to the version just below the oldest currently deployed, give users 2 weeks to update, then tighten the minimum to the target version.

System Security:

• Firewall: Require
• Antivirus: Require
• Antispyware: Require
• Microsoft Defender Antimalware: Require
• Microsoft Defender Antimalware minimum version: Leave blank (any current version is acceptable)
• Microsoft Defender Antimalware security intelligence up-to-date: Require
• Real-time protection: Require

If any devices in your environment use a third-party antivirus product (Symantec, CrowdStrike, Sophos), the "Microsoft Defender Antimalware" check may fail because Defender enters passive mode when a third-party AV is installed. Check whether the third-party AV reports compliance through the Windows Security Center integration — most modern third-party AV products do, which satisfies the "Antivirus: Require" check even when Defender is in passive mode. The "Microsoft Defender Antimalware: Require" check specifically validates Defender, not third-party AV. If you use third-party AV, don't enable this specific check.

Actions for noncompliance:

This is where you configure what happens when a device fails the compliance check. Add these actions in order:

1. Mark device noncompliant: Set the grace period to 7 days. This gives users 7 days to remediate before the device is marked non-compliant and conditional access blocks access. During the grace period, the device shows as "In grace period" — the user receives notifications but isn't blocked yet.

1. Send email to end user: Configure a notification email that tells the user what's wrong and how to fix it. The email should say: "Your device doesn't meet our security requirements. Specifically: [list of failing checks]. You have 7 days to resolve these issues before access to company email and files is restricted. Contact the helpdesk if you need assistance."

1. Remotely lock the noncompliant device (optional): Only enable this for high-security environments. For most organizations, blocking M365 access via conditional access is sufficient — you don't need to lock the entire device.

Click "Create" to deploy the policy.

Verifying policy deployment

After creating the policy, verify it's evaluating devices correctly:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Check compliance status across all Windows devices
Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows'" |
    Select-Object DeviceName, ComplianceState, UserPrincipalName |
    Group-Object ComplianceState |
    Select-Object Name, Count

This shows how many devices are Compliant, NonCompliant, InGracePeriod, and Unknown. Run this 24-48 hours after deploying the policy (devices need to check in and be evaluated).

For a specific non-compliant device, check which settings are failing:

Navigate to intune.microsoft.com → Devices → All devices → click the non-compliant device → Device compliance. The compliance details show each check with a pass/fail status. This tells you exactly what the user needs to fix — BitLocker not enabled, OS version too old, firewall disabled, or antivirus not running.

The graduated deployment approach

Don't deploy all five checks simultaneously. Use a graduated approach:

Week 1: Deploy with firewall and Secure Boot checks only. These have near-zero blast radius — almost every modern Windows device passes both. This proves the compliance policy mechanism works without affecting any users.

Week 2: Add Defender Antivirus checks (antivirus active, real-time protection, signatures current). Most managed devices pass these. The few that fail are usually devices with disabled real-time protection — easily fixed.

Week 3: Add BitLocker requirement. This is the check with the highest blast radius. By this point, your BitLocker remediation from AD3.2 should be complete, and most devices should already be encrypted.

Week 4: Add minimum OS version. This is the check that requires the most user coordination — OS updates take time and require restarts. By deploying it last, you've resolved the other compliance issues first and only need to address the OS update gap.

This graduated deployment means you never have more than one compliance issue to troubleshoot at a time. If a user calls the helpdesk saying "my device is non-compliant," you know exactly which check was just added and can troubleshoot efficiently.

Connect-MgGraph -Scopes "BitlockerKey.Read.All"

# Check which devices have BitLocker recovery keys stored in Entra
Get-MgInformationProtectionBitlockerRecoveryKey -All |
    Select-Object Id, DeviceId, CreatedDateTime |
    Sort-Object CreatedDateTime -Descending |
    Format-Table -AutoSize