Understanding Intune Application Protection
While Intune provides robust application management and protection policies, it can be a bit confusing to understand when coming from other mobile device management platforms. Let me start by making one point clear: Intune is not a container.
Intune protects applications with a focus on identity. For Intune enlightened apps, you can protect corporate data even if the device is not managed by Intune. They can be managed by a 3rd party MDM platform or not enrolled in management at all – it doesn’t matter! Intune app protection cares about the identity of the person who is using the mobile app. If there’s a app protection policy deployed to that user, then that policy applies.
Identity is the key to understanding how Intune app protection works.
I have a lot of customers ask me why Intune can only protect a few apps. And in a way, they have a point. At the time of writing the official list is only about 45 apps. Unsurprisingly, majority of these apps are Office 365 applications. O365 apps are often the key focus for organizations leveraging app protection, so at least we’re off to the right foot.
The natural question then becomes: “Why can’t Intune protect my favorite must-have app?” In order for Intune to be able to protect an app, it must be enlightened. “Enlightened” is the phrase we use to define apps that are wrapped to support a corporate identity managed by Intune. This is the trade-off Intune app protection makes. We want to be able to protect corporate data for any user no matter where they access the data. For this to work, applications must be built to understand identities associated with Intune.
Other mobile device management platforms make the opposite trade-off. They provide a container where all your corporate applications live. The container can have a number of restrictions on it that feel secure. But for the end-user, they unfortunately have to change the way they work. If they use their device for personal tasks now they have to jump through hoops to access any corporate information.
Intune subverts this by allowing corporate apps to co-exist with personal apps, while protecting corporate data. It even takes this a step further by allowing multi-identity apps to have protection just apply to corporate data. For example, many companies use OneDrive for cloud storage. OneDrive also comes pre-installed in Windows 10 – so many employees of those companies will have data in their own personal OneDrive accounts. Since OneDrive is an Intune enlightened app, a user with OneDrive installed on their phone (and an App Protection policy deployed) can log in with both their personal and corporate account. The corporate account can be locked down (preventing save as, blocking cut/copy/paste, requiring a PIN, etc.) while the personal account will be unaffected.
In the end, focusing on identity for app protection allows Intune to seamlessly protect data anywhere, but limits the applications that can be used.
*One quick caveat. There is one app that isn’t necessarily supported, but can still be protected. You can probably guess what it is too: Salesforce. It’ll take a blog post of it’s own to explain, but for Intune managed device you can deploy a configuration policy to Salesforce to apply a few restrictions. I’d highly recommend reading this .pdf if you’re interested.
Let’s take a look at actually configuring an app protection policy. In my tenant, I have 2 apps deployed for iOS devices:
Once the device is enrolled, both apps are downloaded on my iPad:
In the Intune portal, I’ll head to Client apps > App protection policies. Since I don’t have any policies created I’ll click + Create policy. After providing a name and specifying iOS for the platform, I’m shown the list of apps Intune can protect:
After selecting Outlook, I can click on Settings to define the app protection settings. For demos, I block cut/copy/paste for easy proof that the policy has applied:
I also left the default access requirements in, requiring a passcode. This ensures that iOS devices that don’t use a PIN to unlock will now be required to set one up for accessing Outlook. Without this, if the device was lost someone could open the device and access my corporate email. After configuring the policy, we just need to deploy it:
When I open Outlook for the first time I’ll be prompted to add my Office 365 account that I enrolled through Intune:
The application protection policy will apply immediately, requiring me to restart the app to apply the policy:
We’ll see that the Device Passcode prompt is shown before access to email is given:
I’ll receive a prompt to enter my device pin to access outlook:
Once that’s confirmed I can access my email! But if I blocked cut/copy/paste, why does it still show up when I select text?
This is because Intune App Protection doesn’t have the ability to change the clipboard behavior, only the app behavior. If we actually copy and paste text into a third party app, we’ll see:
But what if the user uses the Outlook app for their personal email? If I copy from notes to Outlook personal, will that work?
Absolutely! And remember – for the end user, they’re not switching apps. No relaunching. The Outlook mobile app even shows both email inboxes in the same list – but the corporate data is protected by Intune app protection.
Evernote, on the other hand, cannot be managed by app protection. So even though we deployed it via Intune, since it is not enlightened (meaning aware of the identity Intune manages), cut/copy/paste is fair game.
The goal of this post was to hammer home the point of how application protection in Intune relies on identity. I’ve received a ton of questions about this from people working on migrating to Intune, when they were used to containerized management. Throughout this I hope you’ve seen the benefit to Intune approach, especially for the end user.