Blog Post

Intune Customer Success
6 MIN READ

App protection policy conditional launch improvements

Ross Smith IV's avatar
Ross Smith IV
Icon for Microsoft rankMicrosoft
Mar 15, 2021

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 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 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 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

Updated Dec 19, 2023
Version 5.0
  • looks like i will need to update some documentation on my end. this is good news though!

  • Mikael Cavrak's avatar
    Mikael Cavrak
    Copper Contributor

    Hi

     

    Great improvments. One question. What version of the Intune SDK does the apps need to have?
    Tried the conditional launch disable account scenario(block access) with Outlook for iOS, but it seams to not take effect after waiting a while. What happens instead is that the Outlook App shows banner in the bottom that you need to sign in again. After doing that i get notified that my account is disabled.

  • Reza_Ameri There isn't a simple recovery path. In many cases, the only recovery method after jailbreaking or rooting a device is a reinstall of the OS. 

  • Vadivelu_B's avatar
    Vadivelu_B
    Iron Contributor

    Good info. Hopefully it will help all the organization to make 100% compliance on devices. 

  • Alo Press's avatar
    Alo Press
    Iron Contributor

    This is blog post is very valuable, will be implementing the Disabled account Conditional launch right away. Thanks for the updates!

  • Reza_Ameri's avatar
    Reza_Ameri
    Silver Contributor

    I know it is hard but it would have been nice in case there was some sort of policy to rescue the device from Jailbreak status and back it to normal status or guide user to perform such action. 

    These are very useful features and thank you for sharing.

     

     

  • Mikael Cavrak - iOS apps with 12.9.x and later have support for this functionality. it may be best to open a support case as that isn't the desired experience, nor what I saw when I last tested with Outlook iOS. 

  • Reza_Ameri's avatar
    Reza_Ameri
    Silver Contributor

    Ross Smith IV true and that is the real challenge. 

    Another security issue is when device set to install from untrusted sources.

  • Mikael Cavrak's avatar
    Mikael Cavrak
    Brass Contributor

    Ross Smith IV. - Regarding Conditional Launch "Disabled Account"(block access). After reading your answer to my question regarding this feature, I decided to try it ones again. 

    The outcome/result that I got this time and I hope it matches yours.

     

    After a user account gets disable what happens in a App Protection App(let's say Outlook) on the iOS device is....

    1. After waiting a while, a banner is displayed in the app asking me to sign in to my O365 Account. 

    2. After waiting further an App Access Block Blocked dialog is shown to the user.

     

    Ross, is this the expected behaviour? 

     

    Regards

    Mikael