Skip to main content

Android Rooting Policy

Updated today

Overview

The Android Rooting Policy in Swif.ai helps you protect corporate data by detecting rooted or otherwise compromised Android devices and automatically disabling them.

When enabled, Swif uses the Google Play Integrity / Android Management security posture reported for each device. If Google flags a device as AT_RISK or POTENTIALLY_COMPROMISED (for example, due to a compromised OS / rooting), Swif evaluates this policy and, by default, disables the device.

Requirements

  • Minimum Android version: Android 9+

  • Supported platform: Android (managed via Android Management API / Android Enterprise)

  • Owner: Company-managed policy (cannot be end-user modified)

What the policy does

When the policy is active on a device or device group:

  1. Swif receives STATUS_REPORT events from Google (via Pub/Sub) that contain the device’s SecurityPosture.

  2. If the posture is:

    • SECURE → No action is taken.

    • AT_RISK or POTENTIALLY_COMPROMISED → Swif checks whether the Android Rooting Policy is enabled for that device.

  3. If the policy is enabled and the configured action is DISABLE (default):

    • Swif calls DisableDevice via the Android Management API.

    • The device’s state is set to DISABLED.

    • The user sees a customizable message explaining that the device is disabled due to a security risk.

  4. If the policy is disabled or not assigned:

    • Swif does not modify the device state, even if it is AT_RISK or POTENTIALLY_COMPROMISED.

This means:

  • You can enforce that only devices with an uncompromised OS can access corporate apps and data.

  • If you later resolve the issue, you can re-enable the device by setting its state back to ACTIVE and clearing the disabledReason (handled by Swif’s backend / admin actions, as discussed in ST-6371).

Configuration Fields

The Android Rooting Policy exposes the following configuration fields in Swif.ai:

1. Enable Root Detection (rootDetectionEnabled)

  • Display name: Enable Root Detection

  • Type: Boolean (true / false)

  • Required: Yes (field must be present; default is false)

  • Default value: false

  • Minimum system requirements: Android 9+

Description:
Turns the rooting / compromised OS detection on or off for the devices assigned to this policy.

  • When true:

    • Swif monitors the device security posture reported by Google.

    • If the device is reported as AT_RISK or POTENTIALLY_COMPROMISED, Swif evaluates this policy and applies the configured action (currently: DISABLE).

  • When false:

    • Swif ignores AT_RISK / POTENTIALLY_COMPROMISED signals for this policy.

    • No enforcement action is taken by this policy, even if Google reports a compromised posture.

Typical usage:

  • Set to true for high-security fleets where rooted/compromised devices must not access corporate data.

  • Leave as false if you only want to monitor posture via other reports, without automatically disabling devices.

2. Action (action)

  • Display name: Action

  • Type: String (drop-down)

  • Required: Optional

  • Default value: DISABLE

  • Allowed values:

    • "" (empty – interpreted as “use default”)

    • DISABLE

  • Minimum system requirements: Android 9+

Description:
Controls what Swif does when a rooted or compromised device is detected and root detection is enabled.

  • DISABLE

    • Swif calls the DisableDevice operation via the Android Management API.

    • The device state is set to DISABLED.

    • The user is blocked from using the device for managed apps and data and will see the associated message.

  • "" (empty)

    • Swif falls back to the default enforcement behavior.

    • In the current implementation, that default resolves to DISABLE when rootDetectionEnabled is true.

If rootDetectionEnabled is false, this field is effectively ignored and no action is taken.

3. Disabled Message (disabledMessage)

  • Display name: Disabled Message

  • Type: String (free text)

  • Required: Optional

  • Default value:

    This device has been disabled because it appears to be rooted or compromised. Please contact your IT administrator.

  • Minimum system requirements: Android 9+

Description:
Custom message displayed to the end user when their device has been disabled because it is considered rooted or compromised.

  • If you set a custom message, the user will see that string when their device is disabled by this policy.

  • If you leave it empty, Swif will use the default message above.

Examples:

  • High security environment:

    “Rooted device detected. Corporate data access has been revoked. Contact IT to restore access.”

  • Standard corporate messaging:

    “This device has been disabled because it appears to be rooted or compromised. Please contact your IT administrator.”

How Swif interprets device posture

Swif relies on the device posture coming from Google’s Android Management / Play Integrity signals. The raw decision of whether a device is AT_RISK or POTENTIALLY_COMPROMISED is determined by Google’s services (not by Swif).

Internally, the flow (as validated in ST-6371) is:

  1. Swif receives a STATUS_REPORT event.

  2. It reads:

    • SecurityPosture.DevicePosture → e.g. SECURE, AT_RISK, POTENTIALLY_COMPROMISED

    • (Optionally) PostureDetails[].SecurityRisk → e.g. UNKNOWN_OS, COMPROMISED_OS, HARDWARE_BACKED_EVALUATION_FAILED

  3. Swif decides whether the posture requires enforcement:

    • SECURE → no enforcement (policy skipped).

    • AT_RISK or POTENTIALLY_COMPROMISED → enforcement is required.

  4. If enforcement is required and an Android Rooting Policy is assigned:

    • If rootDetectionEnabled == false → skip, no action.

    • If rootDetectionEnabled == true:

      • Resolve action (empty → DISABLE).

      • Resolve disabledMessage (empty → default string).

      • If final action is DISABLE, Swif calls the DisableDevice API and sets the device state to DISABLED with the resolved message.

If no Android Rooting Policy is assigned to the device, Swif logs that no policy is present and takes no action, even if the posture is AT_RISK or POTENTIALLY_COMPROMISED.

For the detailed simulated scenarios and logs used to validate this behavior, see the attachment in Jira:
​security_posture_flow_test.go in https://swifteam.atlassian.net/browse/ST-6371?search_id=f632f1c8-467e-4d0d-adb5-3e6bb3fcbe28&referrer=quick-findPreview

Example scenarios

The following examples summarize what happens in common cases (based on the test flow in ST-6371):

  1. AT_RISK device + policy ENABLED (action: DISABLE)

    • Posture: AT_RISK (e.g. UNKNOWN_OS)

    • rootDetectionEnabled = true, action = DISABLE

    • Result: Device is DISABLED, user sees your configured message.

  2. POTENTIALLY_COMPROMISED (rooted) + policy ENABLED

    • Posture: POTENTIALLY_COMPROMISED (e.g. COMPROMISED_OS)

    • rootDetectionEnabled = true, action = DISABLE

    • Result: Device is DISABLED with your custom message (for example, “Rooted device detected. Corporate data access has been revoked.”).

  3. POTENTIALLY_COMPROMISED + policy DISABLED

    • Posture: POTENTIALLY_COMPROMISED

    • rootDetectionEnabled = false

    • Result: No action. Root detection is considered off.

  4. SECURE device + policy ENABLED

    • Posture: SECURE

    • rootDetectionEnabled = true

    • Result: No action. Device remains active.

  5. AT_RISK device + no Android Rooting Policy assigned

    • Posture: AT_RISK

    • No rooting policy on that device/group

    • Result: No action. Enforcement is skipped because no policy is present.

  6. AT_RISK device + policy enabled but empty action/message

    • Posture: AT_RISK

    • rootDetectionEnabled = true, action = "", disabledMessage = ""

    • Result: Swif resolves:

      • action → DISABLE

      • disabledMessage → default message

    • Device is DISABLED with the default message.

Recommended configuration

For most organizations that want to block rooted or compromised devices:

  1. Enable Root Detection:

    • Set Enable Root Detection (rootDetectionEnabled) to true.

  2. Action:

    • Keep Action set to DISABLE.

  3. Disabled Message:

    • Use a clear, user-friendly message that:

      • Explains that the device appears rooted or compromised.

      • Tells the user how to contact IT or support.

    • Example:

      “This device has been disabled because it appears to be rooted or compromised. Please contact your IT administrator.”

  4. Test in a limited group first:

    • Assign the policy to a test group or small pilot set of Android devices.

    • Review behavior and user experience before rolling out broadly.

Re-enabling a disabled device

If a device was disabled by the Android Rooting Policy and you need to restore access:

  • Resolve the underlying security issue (e.g., unroot or replace the device, or verify that it was a false positive).

  • Use Swif’s device management actions to re-enable the device. Internally this maps to:

    • Setting the device state back to ACTIVE in the Android Management API.

    • Clearing any disabledReason associated with the prior enforcement.

Related Articles
Windows USB policy
Android Device Policy
Android VPN App Policy
Linux User Authorization Policy
Android User Authorization Policy
Did this answer your question?