Don’t lose control of your data. How to create app protection policies.
In 2020, the COVID-19 pandemic triggered a huge rise in remote working and forced many businesses to undergo rapid digital transformation. With more employees working from home than ever before, your employees likely have a wealth of company data stored on their smartphones, tablets, and laptops.
How can you protect this data, when it’s stored on non-company issued devices?
You could try to apply strict rules and restrictions to the employee’s personal smartphone, tablet, and laptop. However, trying to dictate how employees use their personal devices is never a popular strategy. To strike a balance between protecting your data without alienating your employees, you may want to create app protection policies.
You can apply these policies to sensitive applications, regardless of whether the device is managed or unmanaged. In this way, you can maintain control over your data, regardless of whether it’s accessed on a corporate or personal device.
In this article, we’ll take a closer look at what application policies are and why they’re important. We’ll then show you how to create and deploy an app protection policy for iOS, Windows, and Android devices.
What are Microsoft’s app protection policies?
Mobile Application Management (MAM) app protection policies can help ensure your confidential corporate data remains safely contained within a managed application i.e an application that’s managed by Endpoint.
You can use MAM policies to prevent employees from moving confidential company data outside of approved applications. This includes copy/pasting sensitive data into other applications. You can also prohibit specific actions within an application, for example you might prevent employees from saving application data to their personal storage.
Crucially, MAM app protection policies don’t require mobile device management. By creating MAM app protection policies, you can protect your sensitive company data on devices that aren’t enrolled in your device management solution. This includes employee-owned devices that aren’t managed in Endpoint.
It’s also worth noting that MAM policies don’t apply when an employee is using an application in a personal context. For example, you may require the employee to enter a PIN in order to open an application in a work context. However, that employee will still have the option to access the application without a PIN, in a personal context.
In this way, you protect confidential corporate data on the employee’s personal device, without interfering with how they use this device outside of work.
Create a protection policy for iOS, Android, or Windows
In this section, we’ll set up a simple MAM app protection policy. These steps may vary depending on your chosen platform, but along the way we’ll suggest some resources where you can get more information for specific operating systems.
To create an app protection policy:
● Sign into the Microsoft Endpoint Manager admin center.
● In the left-hand menu, select “Apps > App protection policies.”
● Select “Create policy.”
● Choose the platform you’re creating this policy for: iOS/iPadOS, Android, or Windows 10.
● Give your policy a descriptive name, enter an optional description, and then select “Next.”
On the subsequent page, you can build your app protection policy, using the following settings:
1. Target apps on all device types
If MDM is not detected on the employee’s device, it’s classed as an unmanaged device. It’s pretty common for employees to use Mobile Device Management (MDM) on managed and unmanaged devices. For example, an employee may check their work emails on their personal smartphone. This device isn’t managed by Endpoint. However, you can still use application protection policies to protect your corporate data when it’s accessed on this personal device.
Most employees are happy to follow strict rules for company-issued devices. However, they may be less receptive to following the rules on their personal devices. For this reason, you’ll typically
want to create separate policies for managed and unmanaged devices. You can then be more lenient with your unmanaged app protection policies.
On this screen, you can choose whether this app protection policy should be applied to all devices, regardless of whether they’re managed or unmanaged.
If you push this slider into the “No” position, you’ll be prompted to choose a management state.
The options you see will vary depending on your chosen platform. For iOS/iPadOS devices, you can choose between managed and unmanaged devices. If you’re creating an application protection policy for Android, you can choose between managed, Android Enterprise, and Android device administrator.
Android device administration is sometimes referred to as “legacy” Android management. Google is planning to decrease device administrator support in upcoming releases, so you should opt for Android Enterprise wherever possible.
2. Select public apps
This is where you choose which application this policy should apply to. To start, click “Select public apps.” In the subsequent panel, select all the applications that you want to target.
If you’re creating a policy for iOS devices, you can search for an application using its bundle ID. This is a value that Apple uses to identify specific applications. You can find the bundle IDs for all the native iOS and iPadOS applications, at the official Apple docs.
After you’ve chosen the applications that you want to protect, click “Select.” These applications will now be added to your device protection policy.
3. Custom apps
If you’ve developed your own iOS or iPadOS application, you can add this application to your policy using its bundle ID.
To retrieve your app’s bundle ID, open the project in your XCode Integrated Development Environment (IDE). In the project navigator, select the top project item. You can then select “TARGETS > General.” You’ll find the bundle ID under “Identity.”
Now, switch back to Endpoint and click “Select custom apps.” In the subsequent panel, enter your bundle ID and then click “Add.”
This application will now be added to your policy.
Control your data on managed and unmanaged devices
After entering all your information in the “Apps” tab, press “Next” to move to the next screen.
Here, you can set rules for how your employees can interact with the selected applications. The options you see can vary, depending on your chosen platform. However, you should see some, or all of the following:
● Backup org data to iTunes and iCloud backups. Prevent employees from backing up their work or school data to iTunes or iCloud.
● Send Org data to other apps. Specify which applications can receive data from this application. The available options are: All app; none; policy-managed apps; policy managed apps with OS sharing; and policy managed apps with Open-In/Share filtering. Note that selecting “policy managed apps” or “none,” will block Spotlight search and Siri shortcuts.
● Select apps to exempt. This option is only available if you selected “policy managed apps” on the previous screen.
● Save copies of org data. If you enable this setting, you can choose whether users can save content to OneDrive for Business, SharePoint, and/or Local Storage. All other services will be blocked.
● Transfer telecommunication data to. Typically, when a user selects a hyperlinked phone number, a dialer app will launch automatically with the number already pre-populated. You can use this setting to specify how to handle this type of content transfer when initiated from a policy-managed app. You can prevent this data from being transferred, nominate a specific dialer app, or allow data transfer to any dialer app.
● Dialer App URL Scheme. If you nominated a specific dialer app, this is where you can provide the dialer app URL scheme that’s used to launch the dialer app.
● Receive data from other apps. Here, specify which applications can transfer data to your policy-managed applications. You can choose between: none, all applications, policy managed apps, or all apps with incoming Org data. If you opt for the latter, all incoming data that doesn’t have a user identity will be treated as if it originated from your organization.
● Open data into Org documents. If you select “Block,” Endpoint will prevent employees from sharing application data between accounts.
● Allow users to open data from selected services. This allows you to specify whether the user can open data from OneDrive for Business, SharePoint Online, and/or Camera. All other services will be blocked.
● Restrict cut, copy and paste between other apps. Specify when employees can use cut, copy, and paste actions within policy-managed apps.
● Cut and copy character limit for any app. Here, you can specify the number of characters that employees can cut or copy from Org data and accounts.
● Third party keyboards. You can use this setting to prevent employees from using third-party keyboards in policy-managed applications.
After working your way through this list, click “Next” to move to the next screen.
PIN, Touch, and Face ID: Creating access requirements
In this tab, you can configure the PIN and credential requirements that users must meet in order to access policy-protected applications within a work context. For example, you can specify that the employee must protect these applications with a numeric PIN consisting of more than 3 characters.
You can also configure other credentials, including Touch and Face ID, and set conditions for how often the employee should reset their PIN. Most of these settings are self-explanatory, but if you’re unsure then Microsoft has created detailed documentation for iOS/iPadOS access requirements, and Android access requirements.
After you’ve configured your access requirements, click “Next.”
Creating sign-in requirements for policy-managed apps
On this page, you can specify your sign-in security requirements. You can select each item in turn, and then enter an accompanying value that the employee must meet before they can access your policy-protected applications.
You can also specify how Endpoint should handle employees who don’t meet these requirements. For example, you might automatically reset an employee’s PIN following three failed login attempts. The options will vary depending on your chosen platform.
Most of these settings are straightforward, but a few do require some additional explanation:
● Offline grace period. This is the number of minutes that MAM apps can run offline. After this period expires, the employee will need to verify their identity in Azure Active Directory before they can continue using the app.
● SafetyNet device attestation. You may want to configure Google’s SafetyNet Attestation on the employee’s device. Only unmodified devices that have been certified by Google will pass the SafetyNet check.
● Require threat scan on apps. This setting ensures that Google’s Verify Apps scan is activated on the employee’s device.
● Min Company Portal version. This allows you to specify a minimum version of the Company Portal that’s enforced on the employee’s device.
● Max allowed device threat level. This enables you to specify a maximum threat level threshold. Threats are determined by your chosen Mobile Threat Defense (MTD) vendor application.
● Disabled account. If you disable an employee in Azure Active Directory, this setting will block their access to policy-managed apps and data.
When you’re happy with your conditional access settings, click “Next.”
Apply your app protection policy
On this page, choose who this policy should apply to by clicking “Select groups to include.” You can then select your group(s) in the subsequent panel.
You may also want to exclude certain groups from your policy. To create these exclusion rules, click “Select groups to include.”
After creating your inclusion and exclusion rules, select “Next.” This launches the “Review + create” tab. On this page, you can review your policy settings.
If you’re happy with your policy, click “Create.” This policy is now live, and will be applied to all your chosen users.
Share this article on social media
If you found this article useful, please share it on social media.
Subscribe to our blog…
We will only use your email to send you new blog posts.