Compliance Policies

Define device health requirements that devices must meet to access corporate resources. Compliance policies work with Conditional Access to ensure only healthy, secure devices can access Microsoft 365 data.

Note: Compliance policies are essential for Zero Trust security. Combined with Conditional Access, they verify device health at every access attempt before granting access to corporate resources.

Compliance Policy List

Platform-Specific Requirements

Windows 10/11

Device Health:

• BitLocker encryption
• Secure Boot enabled
• Code integrity
• Require TPM

System Security:

• Firewall required
• Antivirus required
• Antispyware required
• Microsoft Defender Antimalware

Device Properties:

• Minimum OS version
• Maximum OS version
• Valid operating system builds

Defender for Endpoint:

• Require device at or below risk level
• Low, Medium, High, Clear risk scores

macOS

System Security:

• Require password
• Password complexity
• Minimum password length
• FileVault encryption

Device Properties:

• Minimum OS version
• Maximum OS version
• Minimum build version

iOS/iPadOS

Device Health:

• Jailbroken devices blocked
• Device threat level (MTD)

Device Properties:

• Minimum OS version
• Maximum OS version

System Security:

• Require passcode
• Simple passwords blocked
• Minimum passcode length

Android

Device Health:

• Rooted devices blocked
• Device threat level (MTD)
• Google Play Services
• SafetyNet attestation

System Security:

• Require password
• Password type required
• Minimum password length
• Encryption required

Creating a Compliance Policy

1. Select Platform

Choose the device platform. Each platform has different available settings.

2. Configure Compliance Settings

Define the requirements devices must meet. Enable only settings relevant to your security requirements.

3. Actions for Noncompliance

Define what happens when devices don’t meet requirements:

• Mark as noncompliant (immediate or delayed)
• Send push notification to user
• Send email to user
• Remotely lock device
• Retire noncompliant device

4. Assign to Groups

Assign to user groups or device groups. Can include and exclude groups.

Compliance States

• Compliant — Meets all requirements
• Not Compliant — Failed one or more checks
• In Grace Period — Time to remediate
• Not Evaluated — No policy assigned

Grace Period

Give users time to remediate before blocking access:

Example timeline:

1. Day 0: Device becomes noncompliant
2. Day 0: User notified via push notification
3. Day 3: Follow-up email sent
4. Day 7: Device marked as noncompliant (blocked by CA)
5. Day 14: Device remotely locked

Compliance + Conditional Access

Compliance policies define requirements. Conditional Access enforces them:

CA Policy Example: Require compliant device for Office 365

Target: All users
Apps: Office 365
Conditions: Any platform
Grant: Require device to be marked as compliant

When user tries to access Office 365, CA checks device compliance state. If not compliant, access is blocked until device is remediated.

Best Practices

• Start with baseline requirements — Begin with essential requirements (encryption, passcode) before adding strict settings.
• Use grace periods — Give users time to remediate before blocking. 7-14 days is common.
• Test with pilot group — Deploy to IT or early adopters first to validate settings don’t block legitimate use.
• Communicate to users — Ensure users know requirements and how to remediate before enforcement begins.

API Reference

• GET /api/devices/compliance-policies — List all compliance policies
• POST /api/devices/compliance-policies — Create compliance policy
• GET /api/devices/compliance-policies/:id/status — Get device compliance status for policy
• GET /api/devices/:id/compliance — Get compliance state for specific device