# Ensure Android compliance policy blocks rooted devices

Ensure at least one assigned Android compliance policy blocks rooted devices.

Source: https://maester.dev/docs/tests/MT.1232

<!-- This file is generated by website/scripts/generate-test-docs.mjs. Do not edit manually. -->

<div class="test-byline"><div class="test-byline-avatars"><a class="test-byline-avatar test-byline-avatar--author" href="/contributors/earbona23" title="Eduard Arbona · Original author"><img src="https://github.com/earbona23.png" alt="Eduard Arbona" width="28" height="28" loading="lazy" decoding="async" /></a></div><div class="test-byline-meta"><span class="test-byline-text">Contributed by <a href="/contributors/earbona23">Eduard Arbona</a></span><a class="test-byline-link" href="/contributors">All contributors →</a></div></div>

<p class="test-part">Part of <a href="/docs/tests/maester">Maester</a> · Intune · Device compliance · <a href="/docs/tests">All checks</a></p>

```powershell title="Run this check"
Invoke-Maester -TestId MT.1232
```

## Overview

Ensure at least one **assigned** Android compliance policy blocks rooted devices.

A rooted Android device has had the boundary the platform is trusted for removed. The application sandbox no longer separates apps, so the credentials and refresh tokens that Microsoft Authenticator, Outlook and Teams keep on the device can be read by anything running with root, and verified boot no longer guarantees that the running system is the one Google signed.

**Intune cannot prevent a device from being rooted.** What it can do is evaluate the root signal as a compliance condition, so that the device is marked non-compliant and can then be blocked by Conditional Access.

Without that rule, Intune reports a rooted device as healthy, and the device keeps its access to corporate resources with exactly the platform guarantees that justified granting that access gone.

Policies that are **not assigned** to any group are reported by this test but do not count towards a pass, because an unassigned compliance policy is never evaluated against any device.

#### Scope limitation

This test evaluates the **Android device administrator** compliance policy type (`androidCompliancePolicy`). Android Enterprise policies, for work profile and device owner enrollments, are counted and reported but their settings are not read, because their property names are not verified here.

A tenant that has Android Enterprise policies and no device administrator policy is reported as **not applicable** rather than as a failure: Google ended device administrator support, so having none of those policies is the modern posture, not a gap. A tenant with no Android compliance policy of any kind does fail, because then nothing evaluates Android devices at all.

#### Remediation action

1. Navigate to the [Microsoft Intune admin center](https://intune.microsoft.com).
2. Go to **Devices** > **Manage devices** > **[Compliance](https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/~/compliance)**.
3. Select an existing Android policy, or select **+ Create policy** with **Platform** set to **Android device administrator**.
4. Under **Compliance settings** > **Device Health**, set **Rooted devices** to **Block**.
5. On the **Assignments** tab, assign the policy to your Android device or user groups.
6. Select **Next** and then **Create** or **Save**.

For Android Enterprise enrollments, set the equivalent **Rooted devices** setting in the work profile or device owner compliance policy.

#### Related links

- [Microsoft Intune admin center - Device compliance](https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/~/compliance)
- [Microsoft Learn - Android device administrator compliance settings in Intune](https://learn.microsoft.com/intune/device-security/compliance/ref-android-administrator-settings)
- [Microsoft Learn - Levels of protection and configuration in Intune](https://learn.microsoft.com/intune/fundamentals/protection-configuration-levels)

## Details

<details>
<summary>Every attribute of this check</summary>

| Field | Value |
| --- | --- |
| Test ID | MT.1232 |
| Severity | Medium |
| Suite | Maester |
| Product | Intune |
| Feature | Device compliance |
| Area | Devices and endpoints |
| Resource type | Tenant |
| User impact | Low |
| Implementation cost | Low |
| MITRE ATT&CK | T1068 Exploitation for Privilege Escalation, T1553.006 Code Signing Policy Modification |
| Supports controls | nist-800-53-r5:SI-7, nist-800-53-r5:AC-19 |
| PowerShell test | [Test-MtAndroidRootedDevice](https://github.com/maester365/maester/blob/main/tests/maester/intune/Test.MT.1232.ps1) |
| Services | Graph |
| Compatible licenses | INTUNE_A |

</details>

## Source

- Test: [`tests/maester/intune/Test.MT.1232.ps1`](https://github.com/maester365/maester/blob/main/tests/maester/intune/Test.MT.1232.ps1)
- Documentation: [`tests/maester/intune/Test.MT.1232.md`](https://github.com/maester365/maester/blob/main/tests/maester/intune/Test.MT.1232.md)