App protection policy conditional launch improvements
Published Mar 15 2021 06:00 AM 17.8K Views
Microsoft

As mobile usage becomes more prevalent in your organizations, so does the need to protect against data leaks. App protection policies (APP, also known as MAM) help protect work or school account data through data protection, access requirements, and conditional launch settings. For more information, see App protection policies overview

 

Conditional launch settings validate aspects of the app and device prior to allowing the user to access work or school account data, or if necessary, remove the work or school account data. Based on your feedback, we’ve updated an existing conditional launch setting, and are introducing four new management settings.

 

Jailbroken/rooted devices

Status: Jailbroken/rooted devices conditional launch setting was updated in February 2021 and works with both iOS and Android Microsoft apps.

 

To improve the overall security of devices accessing work or school account data using apps with App Protection Policies, the Jailbroken/rooted devices conditional launch setting can no longer be deleted and defaults to block access. Organizations now only have two options for jailbroken or rooted devices:

  • Block access - When the Intune SDK has detected the device is jailbroken or rooted, the app blocks access to work or school data.
  • Wipe data - When the Intune SDK has detected the device is jailbroken or rooted, the app will perform a selective wipe of the users' work or school account and data.

For organizations that had previously removed the Jailbroken/rooted devices conditional launch setting, this is now enforced in the Intune SDK automatically. If users had been using a jailbroken or rooted device prior to this change, those devices would be blocked.

 

Disabled account

Status: The Disabled account conditional launch setting was released in Q4 2020 and works with both iOS and Android Microsoft apps.

 

When a user account is disabled in Azure Active Directory (Azure AD), customers have an expectation that work or school account data being managed by an APP is removed. Prior to this conditional launch setting, customers had to rely on the Offline grace period timer to remove the data after the token expired.

 

The Disabled account conditional launch setting works by having the Intune SDK check the state of the user account in Azure Active Directory when the app cannot acquire a new token for the user. If the account is disabled, then the Intune SDK will perform the following based on the policy configuration:

  • Block access - When Intune has confirmed the user has been disabled in Azure Active Directory, the app blocks access to work or school data.
  • Wipe data - When Intune has confirmed the user has been disabled in Azure Active Directory, the app will perform a selective wipe of the users' work or school account and data.

If Disabled account is not configured, then no action is taken. The user continues to access the data in an offline manner until the Offline grace period wipe timer has expired with data access being wiped after 90 days (assuming default settings).

 

Important: The Disabled account setting does not detect account deletions. If an account is deleted, the user continues to access data in an offline manner until the Offline Grace Period wipe timer has expired.

 

The time taken between disabling an Azure Active Directory user account and the Intune SDK wiping the data varies. There are several components that impact the time to initiate the data wipe:

 

[Max time to wipe] = [Azure AD connect sync time] + [APP access token lifetime] + [APP check-in time]

  1. Azure AD Connect sync defaults to 30 minutes. See Azure AD Connect sync: Scheduler for more information.
  2. Azure AD access token for the APP service is hard coded to 120 minutes.
  3. Intune APP check-in time is hard coded to 30 minutes. For more information, see Understand App Protection Policy delivery timing

The selective wipe will be executed the next time that the app is active after the max time to wipe has passed.

 

Max OS version

Status: The Max OS version conditional launch is supported with the March 2021 (Company Portal version 5.0.5084.0) release for Android Microsoft apps and the Intune SDK will be available for consumption by iOS Microsoft apps in April 2021.

 

The Max OS version conditional launch setting operates like the Min OS version setting. When the app launches, the operating system version is checked. The primary use case for the Max OS version conditional launch setting is to ensure that users don’t use unsupported operating system versions to access work or school account data. An unsupported version could be beta versions of next generation operating systems, or versions that you have not tested.

 

If the operating system version is greater than the value specified in the Max OS version, then the Intune SDK will perform the following based on the policy configuration:

  • Warn – The user sees a dismissible notification if the operating system version on the device doesn't meet the requirement.
  • Block access - The user is blocked from accessing work or school account data if the operating system version on the device doesn't meet the requirement.
  • Wipe data - The app performs a selective wipe of the users' work or school account and data if the operating system version doesn’t meet the requirement.

Figure 1: Access is blocked due to OS versionFigure 1: Access is blocked due to OS version

Require device lock

Status: The Require device lock Android conditional launch setting was released in January 2021 and works with Android Microsoft apps.

 

The Require device lock conditional launch setting determines if the Android device has a device PIN, password, or pattern set. It cannot distinguish between the lock options or complexity, for that, device enrollment is required. If the device lock is not enabled on the device, then the Intune SDK will perform the following based on the policy configuration:

  • Warn – The user sees a dismissible notification if the device lock is not enabled.
  • Block access - The user is blocked from accessing work or school account data if the device lock is not enabled.
  • Wipe data - The app performs a selective wipe of the users' work or school account and data if the device lock is not enabled.

Figure 2: Access is blocked until device lock is enabledFigure 2: Access is blocked until device lock is enabled

With this conditional launch setting, there is parity both mobile operating system platforms whereby app protection policies can enforce a device PIN (on iOS, device lock is required when encryption is required) on devices that are not enrolled.

 

SafetyNet Hardware Backed Attestation

Status: The SafetyNet hardware backed attestation conditional launch setting for Android will be supported in Q3 2021.

 

App protection policies provide the capability for admins to require end-user Android devices to pass Google's SafetyNet Attestation. Administrators can validate the integrity of the device (which blocks rooted devices, emulators, virtual devices, and tampered devices), as well as require that unmodified devices have been certified by Google. Within APP, this is configured by setting SafetyNet device attestation to either Check basic integrity or Check basic integrity & certified devices.

 

Hardware backed attestation enhances the existing SafetyNet attestation service check by leveraging a new evaluation type called Hardware Backed, providing a more robust root detection in response to newer types of rooting tools and methods, such as Magisk, that cannot always be reliably detected by a software only solution. Within APP, hardware attestation will be enabled by setting Required SafetyNet evaluation type to Hardware-backed key once SafetyNet device attestation is configured.

 

As its name implies, hardware backed attestation leverages a hardware-based component which shipped with devices installed with Android 8.1 and later. Devices that were upgraded from an older version of Android to Android 8.1 are unlikely to have the hardware-based components necessary for hardware backed attestation. While this setting should be widely supported starting with devices that shipped with Android 8.1, Microsoft strongly recommends testing devices individually before enabling this policy setting broadly.

 

Important: Devices that do not support this evaluation type will be blocked or wiped based on the SafetyNet device attestation action. Organizations wishing to use this functionality will need to ensure users have supported devices. For more information on Google’s recommended devices, see Android Enterprise Recommended requirements.

 

If the device fails the attestation query, then the Intune SDK will perform the following based on the policy configuration:

  • Warn - The user sees a dismissible notification if the device does not meet Google's SafetyNet Attestation scan based on the value configured.
  • Block access - The user is blocked from accessing work or school account data if the device does not meet Google's SafetyNet Attestation scan based on the value configured.
  • Wipe data - The app performs a selective wipe of the users' work or school account and data.

Figure 3: Access is blocked with a rooted deviceFigure 3: Access is blocked with a rooted device

We hope you find these enhancements to our Conditional launch capabilities useful. The Data Protection Framework has been updated for the settings that have been released and changes will be introduced as the new settings are released in the future.

 

Ross Smith IV
Principal Program Manager
Customer Experience Engineering

9 Comments
Co-Authors
Version history
Last update:
‎Dec 19 2023 01:18 PM
Updated by: