Understanding the device attestation verdict

IBM® MaaS360® now integrates the Play Integrity API to enhance attestation checks, making them faster, more resilient against attacks, and more privacy-focused for users.

The Play Integrity API helps developers and organizations evaluate the reliability of devices accessing their applications by offering attestation for Android devices. It provides different levels of security based on the status of the device. By detecting potentially risky and fraudulent interactions, such as from tampered app versions and untrustworthy environments, the backend server of the app responds with appropriate actions to prevent attacks and reduce abuse.

Following are the different attestation strictness.
Attestation Strictness Android 12 or earlier Android 13 and later
Basic This device recognition verdict is an indication that the app is running on a device that passes basic system integrity checks. The device bootloader can be locked or unlocked, and the boot state can be verified or unverified. It might not be Play Protect certified, in which case Google cannot provide any security, privacy, or app compatibility assurances. This device recognition verdict is an indication that the security check happened on a physical Android-powered device. The device bootloader can be locked or unlocked, and the boot state can be verified or unverified. It might not be Play Protect certified but is hardware-backed. It might not be Play Protect certified and Google cannot provide any security, privacy, or app compatibility assurances and cannot guarantee that the device is not acting as a proxy, such as for a virtual instance of Android. This implies that rooted devices can still pass the meets-basic-integrity check, if key attestation is available.

The basic verdict requires only that the attestation root of trust is provided by Google.
Moderate This device recognition verdict is an indication that the app on the device is a genuine Play Protect certified and Android-powered device. This device recognition verdict is an indication that the app on the device is a genuine Play Protect certified and Android-powered device. This verdict requires the device bootloader to be locked and the loaded Android OS to be a certified device manufacturer image

There is hardware-backed proof that the device bootloader is locked and the loaded Android OS is a certified device manufacturer image.
Strong This device recognition verdict is an indication that the app is running on a genuine Play Protect certified Android-powered device and provides hardware-backed proof of boot integrity. This device recognition verdict is an indication of a genuine Play Protect certified and Android-powered hardware-backed device with a recent security update. This requirement mandates that devices meet the device-integrity standard and received security updates within the past year for all partitions. This includes patches for both the Android OS and vendor partitions.

The strong verdict requires moderate and security updates in the last year for all partitions of the device, including an Android OS partition patch and a vendor partition patch.
IBM MaaS360 supports the stronger framework for the Device Attestation checks. The administrator can now select the following attestation checks from the Device Attestation section.
Basic
For Android 13 and later, this ensures that the device is a physical device, irrespective of its bootloader status, boot state, or Play Protect certification.
However, for Android 12 and earlier, it ensures basic system integrity, allowing unrecognized Android versions, an unlocked bootloader, unverified boot, or lack of manufacturer certification.
Moderate
For Android 13 and later, this ensures that the device is Android Play Protect certified, with a locked bootloader and certified OS.
For Android 12 and earlier, this ensures that the device is Android Play Protect certified.
Strong
For Android 13 and later, this ensures that the device is Android Play Protect certified, with a locked bootloader, certified OS, and received a security update within the last year.
For Android 12 and earlier, this ensures that the device runs Google Play services and provides strong hardware-backed proof of boot integrity.

For Android 13 and later, by default all the three integrity checks are now hardware-backed, enforcing higher security standards. Devices must have a security patch not older than a year to pass the Strong Integrity verdict, which might impact enrollment and compliance.

Notes:
  • For WPCO devices the EMM must warn that the Play Integrity API might return a false negative on older devices if the IT admin selects an action other than quarantining.

Setting up device attestation during device enrollment

Follow these steps to select new integrity checks for verifying device compliance.
  1. From the IBM MaaS360 Portal home page, go to Setup > Settings > Directory and Enrollment > Advanced Enrollment Settings > Advanced Management for Android Devices.
  2. From the Device's Attestation section, select a mode for device attestation checks.

Enabling device attestation through policies

To ensure device integrity, you can manage how often attestation checks occur. Follow these steps to enable and configure device attestation.
  1. From the IBM MaaS360 Portal home page, go to Security > Policies.
  2. Select the Android MDM policy for which you want to enable device attestation. By default, the attestation check is done in every 24 hours. and set the frequency.
  3. Click View > Configure settings > Security > Device Security > Enable Device Attestation.
  4. Select the checkbox to enable device attestation setting for the attestation check on the device.
  5. Go to Select frequency and select the attestation check frequency like once a day, twice a day, once in 2 days, and once a week. By default, the frequency is set to once a day.

Setting enforcement rules for device attestation failures

You can define rules that specify what actions to take when a device fails attestation like if the device is rooted or jailbroken, it triggers automatic actions when devices fail integrity checks. If the attestation check is enabled during enrollment, the enrollment is blocked when the attestation fails. If the attestation check is disabled, enrollment proceeds even if the device fails attestation. Even if enrollment is allowed, the system can still enforce the attestation rule afterward. For example, if the rule is to wipe the device on attestation failure, the device will be wiped immediately after enrollment. Follow these steps to set up enforcement rules.
  1. From the IBM MaaS360 Portal home page, go to Security > Compliance Rules.
  2. Click Edit, go to Enforcement Rules > Enforcement Action.
  3. Select the enforcement action like Alert, Selective Wipe, Full Wipe, Change Policy, Hide Device.

View Attestation failure details

The following table describes the attestation failure details for Android 12 and earlier and Android 13 and later.
Android version Attestation level Failure reason Failure reason description
Android 12 and earlier Moderate Device has failed the attestation check. Expected Moderate but received Basic. The app might not be running on a genuine Play Protect certified Android-powered device.
Android 12 and earlier Strong Device has failed the attestation check. Expected Strong but received Basic. The app might not be running on a Play Protect certified Android device, or the device might not support hardware-based boot integrity verification.
Android 12 and earlier Strong Device has failed the attestation check. Expected Strong but received Moderate. The device might not support hardware-based boot integrity verification.
Android 12 and earlier Basic, Moderate, Strong Device has signs of attack, system compromise, or an emulator. The app is running on a device that has signs of attack (such as API hooking) or system compromise (such as being rooted), or the app is not running on a physical device (such as an emulator that does not pass Google Play integrity checks).
Android 13 and later Moderate Device has failed the attestation check. Expected Moderate but received Basic. The device might not be Play Protect certified, might have an unlocked bootloader, or might be running an uncertified version of Android.
Android 13 and later Strong Device has failed the attestation check. Expected Strong but received Basic. The device might not be Play Protect certified, might have an unlocked bootloader, might be running an uncertified version of Android, or might not have received security updates in the past year for all partitions, including the Android OS and vendor partitions.
Android 13 and later Strong Device has failed the attestation check. Expected Strong but received Moderate. The device might not have received security updates in the last year for all partitions of the device, including an Android OS partition patch and a vendor partition patch.
Android 13 and later Basic, Moderate, Strong Device has signs of attack, system compromise, or an emulator. The app is running on a device that has signs of attack (such as API hooking) or system compromise (such as being rooted), or the app is not running on a physical device (such as an emulator that does not pass Google Play integrity checks).
The following table describes the attestation failure details for all Android versions.
Android version Attestation level Failure reason
All Versions Basic, Moderate, Strong Device check failed
All Versions Basic, Moderate, Strong Token decryption failed
All Versions Basic, Moderate, Strong Corrupted response
All Versions Basic, Moderate, Strong App/Device Integrity failed
All Versions Basic, Moderate, Strong Agent package name mismatch
All Versions Basic, Moderate, Strong Agent certificate mismatch
All Versions Basic, Moderate, Strong Empty/Unevaluated values received
All Versions Basic, Moderate, Strong Device has failed the attestation check