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.
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:
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.
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:
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]
The selective wipe will be executed the next time that the app is active after the max time to wipe has passed.
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:
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:
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.
Status: The SafetyNet hardware backed attestation conditional launch setting for Android will be supported in Q2 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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.