> For the complete documentation index, see [llms.txt](https://helpdesk.augmentt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpdesk.augmentt.com/modules/secure/intune/device-compliance.md).

# Device Compliance

{% hint style="info" %}
This page is a branch of [Intune](/modules/secure/intune.md), covering the **Device Compliance** policy category specifically. See that page first for how Templates, Baselines, and Policies relate to each other in general — everything below assumes that model.
{% endhint %}

Device Compliance policies define the rules a device must meet to be marked **compliant** in Intune — which in turn is what most Conditional Access "require compliant device" grant controls check against. Unlike Device Configuration (which pushes settings onto a device), a compliance policy doesn't change anything on the device by itself — it evaluates the device's reported state and marks it compliant, non-compliant, or (after a grace period) triggers an action such as blocking access or sending a notification.

## What this category controls

A Device Compliance template captures one Intune `deviceCompliancePolicy` (Graph `/deviceManagement/deviceCompliancePolicies`), which is inherently **platform-specific** — the fields and even the compliance rule types differ between Windows, macOS, iOS, and Android policy bodies (`@odata.type` values like `#microsoft.graph.windows10CompliancePolicy` or `#microsoft.graph.macOSCompliancePolicy`). Every compliance policy also carries a **scheduled actions for noncompliance** block — what happens, and after how much grace period, if a device fails the rule.

## Configuration surface

Augmentt's compliance policy editor groups settings the same way the Intune admin center does — by platform, then by settings section (Device Health, Device Properties, System Security, Device Security, Configuration Manager Compliance):

### Windows 10/11

* **Device Health** — require BitLocker; require Secure Boot; require Code Integrity.
* **Device Properties** — minimum/maximum OS version, minimum/maximum mobile OS version, valid OS build ranges.
* **System Security** — password required; simple passwords blocked; required password type; minimum password length; password expiration (days); password history (previous-password block count); minutes of inactivity before lock; password required to unlock from idle; encryption of data storage required; firewall required (active firewall required); TPM required; antivirus required; antispyware required; Defender required (and Defender signature out-of-date check); real-time protection (RTP) required; Defender version check.
* **Device Security** — Attack Surface Reduction / advanced protections surfaced here too: memory integrity (HVCI/virtualization-based security) enabled, kernel DMA protection, firmware protection, early-launch antimalware driver, device threat protection required and its required security level (via a connected Mobile Threat Defense/Defender for Endpoint connector).
* **Configuration Manager Compliance** — optionally require the device to also be compliant per Configuration Manager, for co-managed devices.
* **Custom compliance** — a compliance policy can point at a device-side custom compliance script instead of (or alongside) the built-in rules (`deviceCompliancePolicyScript`).
* **WSL distributions** — allow-list of Windows Subsystem for Linux distributions, where applicable.

### macOS

* Firewall enabled, block all incoming, stealth mode enabled.
* Minimum/maximum OS version and build version.
* Password required, simple passwords blocked, required password type, minimum length, expiration, minutes of inactivity before lock, character-set count, previous-password block count.
* Storage encryption required (FileVault).
* System Integrity Protection (SIP) enabled required.
* Gatekeeper allowed app source.
* Device threat protection required / required security level.

### iOS/iPadOS and Android

* Jailbroken/rooted device detection and blocking.
* Passcode requirements (required, minimum length, complexity, expiration, failed-attempts-before-wipe).
* Minimum/maximum OS version.
* Email profile requirement (managed email profile must exist).
* Security patch level minimum (Android).
* Device threat protection level, tied to a connected Mobile Threat Defense partner.
* Enrollment-type-specific rule sets for Android: device administrator, AOSP, Android Enterprise fully managed/dedicated/corporate-owned work profile, and personally-owned work profile each expose their own subset of the above.

### All platforms

* **Actions for noncompliance** — one or more scheduled actions, each with an action type (mark non-compliant, send email/push notification, remotely lock, or block), a grace period in hours before it fires, and — for notification actions — a notification template and additional CC recipients.
* **Assignment** — all users, all devices, or specific groups (include/exclude), same as every other Intune category in Augmentt.

## Default templates Augmentt ships

Augmentt ships **3 built-in Device Compliance templates**, unaffiliated with any customer tenant:

### macOS Compliance Baseline

`@odata.type: #microsoft.graph.macOSCompliancePolicy`, version 2.

| Setting                                 | Value                                               |
| --------------------------------------- | --------------------------------------------------- |
| Firewall enabled                        | `true`                                              |
| Firewall block all incoming             | `false`                                             |
| Firewall stealth mode                   | `true`                                              |
| Minimum macOS version                   | `15.0`                                              |
| Storage encryption required (FileVault) | `true`                                              |
| System Integrity Protection required    | `true`                                              |
| Gatekeeper allowed app source           | `notConfigured`                                     |
| Password required                       | `false`                                             |
| Device threat protection required       | `false` (and required security level `unavailable`) |
| Noncompliance action                    | Block, 0-hour grace period                          |

Description notes Gatekeeper configuration itself is handled separately via a Device Configuration policy. Cites **CIS v8: 4.3, 4.5, 7.3, 10.1**.

### Device Security (Windows)

`@odata.type: #microsoft.graph.windows10CompliancePolicy`, version 2. "Requires Bitlocker, Secure Boot, and Code Integrity to be compliant. Requires Encryption on data storage, Firewall, TPM, and Antivirus. Password required to unlock device, simple passwords blocked, password required when returning from idle state. Defender not enforced in this policy."

| Setting                                                                | Value                      |
| ---------------------------------------------------------------------- | -------------------------- |
| BitLocker required                                                     | `true`                     |
| Secure Boot required                                                   | `true`                     |
| Code Integrity required                                                | `true`                     |
| Storage encryption required                                            | `true`                     |
| Active firewall required                                               | `true`                     |
| TPM required                                                           | `true`                     |
| Antivirus required                                                     | `true`                     |
| Antispyware required                                                   | `false`                    |
| Defender required                                                      | `false`                    |
| RTP enabled required                                                   | `true`                     |
| Signature-out-of-date check                                            | `true`                     |
| Password required                                                      | `true`                     |
| Password block simple                                                  | `true`                     |
| Minimum password length                                                | `14`                       |
| Password required to unlock from idle                                  | `true`                     |
| Minutes of inactivity before lock                                      | `15`                       |
| Previous-password block count                                          | `24`                       |
| Memory integrity (VBS/HVCI)                                            | `false`                    |
| Firmware protection / kernel DMA protection / early-launch antimalware | `false`                    |
| Noncompliance action                                                   | Block, 0-hour grace period |

Cites **CIS v8: 4.3, 4.5, 7.3, 10.1**.

### Device Security - Defender (Windows)

`@odata.type: #microsoft.graph.windows10CompliancePolicy`, version 1. Identical intent to "Device Security" above, but with Defender enforced:

| Setting                                            | Value (where it differs from "Device Security") |
| -------------------------------------------------- | ----------------------------------------------- |
| Defender required                                  | `true`                                          |
| Minimum password length                            | not set (`null`)                                |
| Minutes of inactivity before lock                  | not set (`null`)                                |
| Previous-password block count                      | not set (`null`)                                |
| All other System Security / Device Health settings | same as "Device Security" above                 |

Cites **CIS v8: 4.3, 4.5, 7.3, 10.1**.

## Resolves posture check(s)

As with Device Configuration, Augmentt's `SECURE_CHECK_TYPES` / `COMPLIANCE_AUDIT.*` posture-check engine does not have automated checks that grade the content of live Device Compliance policies directly. The three default templates instead map to:

* **CIS Controls v8** safeguards 4.3 (secure configuration of enterprise assets), 4.5 (secure configuration of end-user devices), 7.3 (automated OS patch management), and 10.1 (deploy and maintain anti-malware software) — cited explicitly in each template's description.
* Indirectly, a compliant-device requirement enforced by these policies underpins Conditional Access grant controls such as **"Require Compliant or Entra Hybrid Joined Devices for Admins"** and the CIS-mapped CAP template **`CIS_M365_V6_L1_MANAGED_DEVICE_REQUIRED_FOR_AUTHENTICATION_5_2_2_9`** — see [Conditional Access](/modules/secure/conditional-access.md). A device can't satisfy those Conditional Access controls unless it's actually evaluated as compliant, which is exactly what these Device Compliance policies determine.
* The one Intune-related check that *does* exist in Augmentt's `SECURE_CHECK_TYPES` enum — **`intuneenrollmentsigninfrequency`** (CIS M365 v6 L1 5.2.2.11 / NIST CSF 2.0) — is a **Conditional Access** sign-in-frequency setting for Intune *enrollment*, not a Device Compliance rule; see [Conditional Access](/modules/secure/conditional-access.md) for that check specifically.

## Related pages

* [Intune](/modules/secure/intune.md)
* [Device Configuration](/modules/secure/intune/device-configuration.md)
* [Conditional Access](/modules/secure/conditional-access.md)
* [Compliance Audit](/modules/secure/security-posture/compliance-audit.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://helpdesk.augmentt.com/modules/secure/intune/device-compliance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.