This chapter covers Intune Device Compliance and Configuration Policies, two core pillars of Microsoft 365 endpoint management. Understanding these policies is critical for the MS-900 exam, as they appear in approximately 15-20% of questions under Objective 3.3 (Implement and manage device compliance and configuration). You will learn how compliance policies enforce security baselines, how configuration policies customize device settings, and how they integrate with Conditional Access to protect corporate data. Mastery of these concepts ensures you can answer scenario-based questions about device management in Microsoft 365.
Jump to a section
Imagine a corporate office building with a strict security checkpoint at the entrance. Every employee must present their badge, which is scanned to verify identity, check expiration date, and confirm access level. Additionally, a security guard inspects each device: laptop must have antivirus running, screen lock enabled, and OS fully patched. If any requirement fails — say the antivirus is outdated — the guard denies entry and sends the employee to a remediation station where they must update the software before being allowed in. The guard logs every check and generates a report for IT. Similarly, Intune Device Compliance policies act as a security checkpoint for devices accessing corporate resources. The device presents its identity (enrolled in Intune), and Intune evaluates it against compliance rules like OS version, encryption status, and threat level. Non-compliant devices are blocked or granted limited access until they remediate. The compliance status is continuously reported and can trigger conditional access policies that enforce access controls at the application level. Just as the guard's log helps audit security, Intune provides detailed compliance reports to administrators.
What Are Intune Device Compliance Policies?
Intune Device Compliance Policies define the rules and settings that devices must meet to be considered compliant with your organization's security requirements. These policies are evaluated against enrolled devices to determine their compliance status: Compliant, Non-compliant, or Not evaluated. Compliance policies are a prerequisite for Conditional Access, which can block or restrict access to corporate resources for non-compliant devices.
How Compliance Policies Work Internally
When a device is enrolled in Intune, it receives assigned compliance policies. The Intune Management Extension on the device evaluates the policy settings and reports the status back to the Intune service. The evaluation occurs:
At device enrollment
Every 8 hours (default check-in interval) — can be changed via configuration
When the user triggers a manual sync from the Company Portal app
When a policy is updated or assigned
Intune compares the reported device attributes against the policy rules. For example, if a policy requires a minimum OS version, Intune checks the device's OS version against the specified threshold. If the device meets all rules, it is marked compliant. If any rule fails, it is marked non-compliant. A grace period can be configured (default 30 days) during which the device remains compliant while the user can remediate. After the grace period expires, the device becomes non-compliant and Conditional Access policies can take effect.
Key Components of Compliance Policies
Platform: Each policy targets a specific platform (Windows, iOS/iPadOS, Android, macOS) because settings are platform-specific.
Rules: Each rule checks a specific condition. Common rules include:
- Require BitLocker encryption (Windows) - Require a password/PIN with minimum length and complexity - Require device to be jailbroken/rooted-free - Require minimum OS version - Require maximum OS version (to avoid unsupported versions) - Require threat level from Microsoft Defender for Endpoint (MDE) to be 'Clean' or 'Low' - Action for noncompliance: You can define actions like marking device non-compliant, sending email notification to user, or retiring the device after a specified number of days. - Grace period: Configurable from 0 to 365 days. Default is 30 days. During grace period, the device is still considered compliant for Conditional Access. - Compliance status: Stored in Azure AD as a device attribute (compliant/non-compliant). This attribute is used by Conditional Access policies.
What Are Configuration Policies?
Configuration Policies (also known as device configuration profiles) allow administrators to configure settings on enrolled devices. Unlike compliance policies that only check and report, configuration policies actively change device settings. They can enforce settings like Wi-Fi profiles, VPN configurations, email settings, restrictions (e.g., disable camera), and more.
How Configuration Policies Work
Configuration policies are assigned to Azure AD groups (users or devices). When a device checks in, it downloads the applicable policies and applies the settings. The Intune Management Extension or platform-specific agents (e.g., Apple MDM protocol) handle the application. Policies can be: - Required: Settings are enforced; user cannot change them. - Allowed: Settings are configured but user can modify. - Not configured: No action taken.
Configuration policies support both device-level and user-level settings. For example, a device restriction policy might disable the camera for all users on that device, while a Wi-Fi profile might be user-specific.
Relationship Between Compliance and Configuration Policies
Compliance policies are evaluative — they check if a device meets a standard. Configuration policies are enforcing — they set the standard. They often work together: you might use a configuration policy to enforce BitLocker encryption and a compliance policy to verify that BitLocker is indeed enabled. If the configuration policy fails to apply, the compliance policy will detect the non-compliance and trigger alerts or Conditional Access blocks.
Integration with Conditional Access
Conditional Access policies in Azure AD can use the device compliance attribute as a condition. For example: 'Grant access to Exchange Online only if device is marked as compliant.' This creates a powerful security loop: the compliance policy defines the health requirements, and Conditional Access enforces them at the application level.
Default Values and Timers
Check-in interval for compliance: Devices check in every 8 hours by default. This can be changed via the 'Device check-in frequency' setting in Intune.
Grace period for non-compliance: Default 30 days. Can be set per policy from 0 to 365 days.
Retention period for retired devices: 30 days after a retire action, the device is removed from Intune.
Policy refresh interval for configuration policies: Typically 8 hours, but can be forced via manual sync.
Verification Commands and Tools
Administrators can verify compliance status via:
- Microsoft Endpoint Manager admin center: Devices > All devices > select device > Device compliance tab.
- Azure AD portal: Azure Active Directory > Devices > select device > Compliance tab.
- PowerShell: Use the Get-IntuneDeviceComplianceStatus cmdlet from the Microsoft Graph PowerShell module.
- Graph API: GET /deviceManagement/managedDevices/{deviceId}/deviceCompliancePolicyStates
For configuration policies, use:
- Endpoint Manager: Devices > Configuration profiles > select profile > Device status.
- Graph API: GET /deviceManagement/deviceConfigurations/{configurationId}/deviceStatuses
Interaction with Related Technologies
Microsoft Defender for Endpoint: Compliance policies can require a specific threat level from MDE. MDE reports the device risk score to Intune, which then determines compliance.
Windows Autopilot: Devices enrolled via Autopilot are automatically targeted by compliance and configuration policies.
Azure AD Join: Hybrid Azure AD joined devices can be managed by Intune and subject to compliance policies.
App Protection Policies: These are separate but complementary; they protect data at the app level, while compliance policies protect at the device level.
Common Settings in Compliance Policies
Windows: Require BitLocker, require Secure Boot, require code integrity, minimum OS version (e.g., 10.0.19041), password required, minimum password length (e.g., 6), password expiration (e.g., 90 days).
iOS/iPadOS: Require passcode, minimum passcode length, require device not jailbroken, minimum OS version, require encrypted backup, require limited ad tracking.
Android: Require device administrator, require encryption, require Google Play Services enabled, minimum OS version, require SafetyNet attestation.
macOS: Require password, require FileVault encryption, require gatekeeper enabled, require firewall enabled.
Monitoring and Reporting
Intune provides built-in reports for compliance and configuration: - Compliance reports: Show overall compliance percentage, per-policy status, and per-device details. - Configuration reports: Show success/failure rates for each profile. - Alerts: Can be configured to notify administrators when compliance drops below a threshold.
Best Practices
Use groups to target policies appropriately (e.g., different policies for executives vs. contractors).
Combine compliance and configuration policies for defense in depth.
Set realistic grace periods to allow users time to fix issues without losing productivity.
Regularly review compliance reports to identify trends and misconfigurations.
Use Azure AD Conditional Access as the enforcement mechanism, not just Intune policies alone.
Exam-Relevant Details
The exam expects you to know that compliance policies do NOT configure settings; they only check them.
Configuration policies are used to actually apply settings.
Both types of policies can target users or devices.
The default check-in interval is 8 hours.
The default grace period for non-compliance is 30 days.
Compliance policies are a prerequisite for Conditional Access to evaluate device health.
Microsoft Defender for Endpoint integration allows risk-based compliance.
You can create compliance policies per platform (Windows, iOS, Android, macOS).
The 'Mark device non-compliant' action can be immediate or after a grace period.
Configuration policies include settings for email, Wi-Fi, VPN, certificates, and restrictions.
Step-by-Step: Creating a Compliance Policy in Endpoint Manager
Sign in to the Microsoft Endpoint Manager admin center.
Navigate to Endpoint security > Device compliance.
Click Create policy.
Select a platform (e.g., Windows 10 and later).
Configure settings: System Security (require BitLocker, require Secure Boot), Password (require password, min length), etc.
Set actions for noncompliance: Mark device non-compliant after 30 days, send email notification.
Assign the policy to a group (e.g., All devices).
Review and create.
The policy will be evaluated on the next device check-in.
Step-by-Step: Creating a Configuration Profile
In Endpoint Manager, go to Devices > Configuration profiles.
Click Create profile > Windows 10 and later > Templates > Device restrictions.
Configure settings like disable camera, require password, etc.
Assign to a group.
Review and create.
The profile will be applied on the next check-in.
Conclusion
Intune Device Compliance and Configuration Policies are fundamental to managing endpoint security in Microsoft 365. Compliance policies define the security baseline and report on device health, while configuration policies enforce those settings. Together with Conditional Access, they create a robust security framework that protects corporate data on any device. For the MS-900 exam, focus on understanding the differences between the two policy types, their default values, and their integration with Conditional Access and Microsoft Defender for Endpoint.
Create Compliance Policy
In the Microsoft Endpoint Manager admin center, navigate to Endpoint security > Device compliance and click 'Create policy'. Select the target platform (e.g., Windows 10 and later). This step defines the rules that devices must meet. The policy includes settings like requiring encryption, password length, and minimum OS version. Each platform has its own set of available rules. The policy is created without assignment first, allowing you to configure all settings before targeting users or devices.
Configure Compliance Rules
Within the policy, configure specific rules such as 'Require BitLocker', 'Require Secure Boot', 'Minimum OS version' (e.g., 10.0.19041), and 'Maximum OS version' (e.g., 10.0.22000). For password, set 'Require password to unlock mobile devices' to Yes, 'Minimum password length' to 6, and 'Password expiration (days)' to 90. These rules are evaluated against device attributes reported by the Intune client. If a rule is not applicable (e.g., BitLocker on a device without TPM), the rule is considered compliant.
Set Actions for Noncompliance
Configure what happens when a device becomes non-compliant. Default actions include 'Mark device non-compliant' immediately or after a grace period (default 30 days). You can add actions like 'Send email to user' with a notification about the non-compliance and steps to remediate. More severe actions include 'Retire device' after a specified number of days. The actions are sequential; for example, first send a notification, then after 7 days mark non-compliant, then after 30 days retire. These actions are critical for exam questions about remediation workflows.
Assign Policy to Groups
Assign the compliance policy to Azure AD groups. You can target users or devices. If targeting users, the policy applies to all devices enrolled by those users. If targeting devices, it applies to the specified devices regardless of user. Assignment is done in the 'Assignments' tab of the policy. You can exclude groups as well. After assignment, the policy is distributed to targeted devices on their next check-in (typically within 8 hours).
Device Evaluates Compliance
The Intune client on the device evaluates the compliance policy rules against local device attributes. For example, it checks if BitLocker is enabled by querying the BitLocker status via WMI. The evaluation result is sent to Intune. If all rules pass, the device status is 'Compliant'. If any rule fails, the status is 'Non-compliant' (or 'Grace' if within grace period). The compliance status is stored in Azure AD as a device attribute, which can be used by Conditional Access policies.
Conditional Access Enforces Access
Conditional Access policies in Azure AD use the device compliance attribute as a condition. For example, a policy might require that the device be marked as 'Compliant' to access Exchange Online. If the device is non-compliant, access is blocked or limited (e.g., only web access, no native mail). This enforcement happens at the authentication level. The device compliance attribute is updated in real-time as evaluations occur, so when a device becomes compliant, access is automatically granted on the next authentication.
Scenario 1: Financial Services Firm Enforcing Encryption
A financial services firm with 5,000 Windows 10 devices must ensure all devices have BitLocker enabled and meet minimum OS version (Windows 10 20H2). They create a compliance policy requiring BitLocker and minimum OS 10.0.19041. They also create a configuration policy that enables BitLocker via a profile (Windows Encryption > BitLocker settings). The compliance policy checks that BitLocker is actually on. They set a grace period of 14 days and an action to send email notification after 7 days. They also configure Conditional Access to block access to Office 365 for non-compliant devices. In production, they find that some devices fail the BitLocker check because they lack TPM. They create an exclusion group for those devices and use a different compliance policy that does not require BitLocker but requires a password. They monitor compliance reports weekly to identify devices that consistently fail and investigate. Misconfiguration: initially they set the grace period to 0, causing immediate lockout for users who hadn't yet rebooted after BitLocker enablement. They changed it to 14 days after user complaints.
Scenario 2: Healthcare Organization Managing BYOD
A hospital allows clinicians to use personal iOS devices to access patient records via Microsoft 365 apps. They create an iOS compliance policy requiring: passcode with minimum 6 characters, device not jailbroken, minimum iOS 15, and require encrypted backups. They also create an app protection policy (MAM) to prevent copy-paste of patient data. The compliance policy is assigned to a group of clinical users. Conditional Access requires that the device be compliant for access to the Electronic Health Record (EHR) app. In production, they notice that some devices become non-compliant because users disable passcode temporarily. They set a grace period of 1 day and send a push notification via Company Portal to remind users. They also create a configuration profile that enforces passcode settings, but on BYOD devices, users can remove the management profile; compliance policy detects this and marks device non-compliant. They implement a policy to automatically retire devices that remain non-compliant for 30 days.
Scenario 3: Retail Company with Shared Devices
A retail company uses shared Windows 10 tablets for store associates. They create a device compliance policy requiring: password length 8, require Secure Boot, and require Windows Defender Antivirus (real-time monitoring). They also create a configuration profile that sets a kiosk mode and restricts access to only the retail app. The compliance policy is assigned to device groups (not user groups) because devices are shared. They use Conditional Access to allow access to the inventory system only if the device is compliant. In production, they face issues with devices that are offline for days; compliance status becomes stale. They configure the compliance policy to mark devices as non-compliant if they haven't checked in for 30 days. They also use Windows Autopilot to pre-provision devices with all policies. Misconfiguration: they set the maximum OS version too strictly, causing devices that auto-updated to Windows 11 to become non-compliant. They had to update the policy to allow Windows 11.
The MS-900 exam tests Intune Device Compliance and Configuration Policies primarily under Objective 3.3: Implement and manage device compliance and configuration. Expect 3-5 questions on this topic. The exam focuses on:
Differences between Compliance and Configuration Policies: The most common exam scenario asks you to choose which policy type to use. Remember: Compliance policies are evaluative (check settings), Configuration policies are enforcing (apply settings). If the question says 'ensure devices meet security requirements', it's compliance. If it says 'configure settings on devices', it's configuration.
Default values and timers: The exam loves to ask about the default check-in interval (8 hours) and default grace period (30 days). Also know that the grace period is configurable from 0 to 365 days.
Integration with Conditional Access: You must know that compliance policies provide the 'compliant' attribute that Conditional Access uses. Without a compliance policy, a device cannot be evaluated for compliance. Conditional Access requires a compliant device (or a hybrid Azure AD joined device) to grant access.
Platform-specific settings: The exam may ask which settings are available for which platform. For example, BitLocker is Windows-only; FileVault is macOS; jailbreak detection is iOS/Android.
Actions for noncompliance: Know that you can configure multiple sequential actions (email, mark non-compliant, retire). The retire action removes the device from management and can wipe corporate data.
Common wrong answers:
Confusing compliance policies with Conditional Access. Compliance policies evaluate and report; Conditional Access enforces access. They are separate.
Thinking compliance policies can configure settings. They cannot; they only check.
Assuming the grace period is 15 days (it's 30 days default).
Believing that configuration policies can enforce compliance (they set the baseline, but compliance is verified by compliance policies).
Edge cases tested:
Devices that are not enrolled in Intune cannot be evaluated by compliance policies.
Compliance policies can target users or devices. If targeting users, the policy applies to all devices they enroll.
A device can have multiple compliance policies; it is compliant only if it meets all assigned policies.
The 'Not evaluated' status occurs when no compliance policy is assigned to the device.
How to eliminate wrong answers:
If the question mentions 'check', 'verify', 'ensure', 'report', it's compliance.
If it mentions 'configure', 'set', 'apply', 'deploy settings', it's configuration.
If it mentions 'block access', 'allow access', 'grant control', it's Conditional Access (not compliance).
Look for keywords like 'default', '8 hours', '30 days', 'grace period' to match to the correct value.
Exam tip: For scenario questions, first identify whether the problem is about checking existing settings (compliance) or applying new settings (configuration). Then look for the integration with Conditional Access if access control is mentioned.
Compliance policies evaluate device settings; configuration policies apply them.
Default check-in interval for compliance evaluation is 8 hours.
Default grace period for non-compliance is 30 days (configurable 0-365).
Compliance status is stored in Azure AD and used by Conditional Access.
Conditional Access is required to actually block or grant access based on compliance.
Platform-specific settings: BitLocker (Windows), FileVault (macOS), jailbreak (iOS/Android).
Multiple compliance policies can be assigned; device is compliant only if all are met.
Actions for noncompliance: email notification, mark non-compliant, retire device.
Configuration policies include device restrictions, email, Wi-Fi, VPN, certificates.
Both policy types can target users or devices.
These come up on the exam all the time. Here's how to tell them apart.
Compliance Policies
Evaluate and report on device settings
Do not change device settings
Provide compliance status to Azure AD
Used by Conditional Access for access control
Examples: require encryption, require password, check OS version
Configuration Policies
Apply and enforce device settings
Actively change device configuration
Do not provide compliance status directly
Not directly used by Conditional Access
Examples: configure Wi-Fi, set password policy, disable camera
Mistake
Compliance policies can enforce settings on devices.
Correct
Compliance policies only evaluate and report on the status of settings; they do not change settings. To enforce settings, you must use configuration policies (device configuration profiles).
Mistake
The default grace period for non-compliance is 15 days.
Correct
The default grace period is 30 days. It is configurable from 0 to 365 days. The exam tests this exact value.
Mistake
Configuration policies are the same as compliance policies.
Correct
They are different. Configuration policies apply settings; compliance policies check settings. They often work together but serve distinct purposes.
Mistake
Compliance policies automatically block access to resources.
Correct
Compliance policies themselves do not block access. They mark the device as compliant or non-compliant. The actual access control is enforced by Conditional Access policies that use the compliance attribute.
Mistake
All compliance policy settings are available on all platforms.
Correct
Compliance policy settings are platform-specific. For example, BitLocker is only available on Windows, FileVault on macOS, and jailbreak detection on iOS and Android. The exam tests which settings apply to which platform.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A compliance policy evaluates whether a device meets certain security requirements (e.g., encryption enabled, password set) and reports the status as compliant or non-compliant. It does not change settings. A configuration policy actively enforces settings on the device (e.g., enabling BitLocker, setting a Wi-Fi profile). In the exam, remember: compliance = check, configuration = apply.
The default grace period is 30 days. This means a device that fails a compliance check remains compliant for up to 30 days while the user can remediate the issue. After the grace period, the device becomes non-compliant. You can change this value from 0 (immediate non-compliance) to 365 days.
By default, devices check in every 8 hours. This interval can be modified in Intune settings. The check-in is also triggered at enrollment, when a policy is updated, or when the user manually syncs from the Company Portal.
No, compliance policies themselves do not block access. They only mark the device as compliant or non-compliant. To block access, you must create a Conditional Access policy in Azure AD that requires a compliant device. This is a key exam point: compliance + Conditional Access = access control.
After the grace period expires, the device is marked non-compliant. The actions you configured (e.g., send email, retire device) are executed. If you have a Conditional Access policy requiring compliance, the user will be blocked from accessing corporate resources until the device becomes compliant again.
No, compliance policies are platform-specific. You must create separate policies for Windows, iOS, Android, and macOS because each platform has different available settings (e.g., BitLocker is Windows-only). The exam tests this platform specificity.
Microsoft Defender for Endpoint (MDE) can provide a risk score for devices. Compliance policies can require a minimum threat level (e.g., 'Clean' or 'Low') from MDE. If MDE detects a threat above the threshold, the device becomes non-compliant. This integrates endpoint detection with compliance.
You've just covered Intune Device Compliance and Configuration Policies — now see how well it sticks with free MS-900 practice questions. Full explanations included, no account needed.
Done with this chapter?