In 2016, I spoke at AirWatch Connect on this new and exciting area within Office 365 called “Mobile App Management Policies” inside of the Azure Portal. The idea was simple: protect stuff, don’t make users sad. A few years later, Microsoft would introduce the ability to push KVPs (Key Value Pairs) to mobile devices to do a lighter version of Mobile App Management. App Protection is becoming the priority and is no longer secondary.

As we fast-forward a few years, both options have matured a bit. We’re going to take a journey explaining how both of these technologies work, what the current state of them are, and can we actually abandon App Protection (their new name) policies now?

App Protection Policies

Microsoft’s App Protection Policies are a really nice idea. When a user logs into a Microsoft mobile application with their Azure AD account, it checks if the user should receive a policy and enforces that policy if that’s the case. Of course, this requires Enterprise Mobility Suite (EMS)/Intune licenses.

The primary use for App Protection Policies are in BYOD scenarios. You might have a user who wants to use OneDrive, Outlook, OneNote, etc. with their personal OneDrive account. This creates many challenges for us as technologists. We have the ability to restrict what apps can open into other apps, but true DLP within application containers is not something we can account for.

App Protection Policies carve out a concept introduced by BlackBerry 10 with a personal and work partition (made more famous by Android Enterprise today). App Protection Policies allow us to enforce specific policies that only apply to the work container, giving our users unfettered access to their personal data while still securing our corporate data.

We will cover the numerous features and options later on, but I think it’s important to be aware of the basics at this point as we go a bit deeper. This was the creation of a new concept known as App-Level Management vs. Full-Device Management. One could “enroll” an application without impacting anything outside of it.

Managed App Configuration

Primarily, we will focus on Managed App Config that Apple uses, but Android’s Managed Configurations work similarly. The idea conceptually is to store configurations in a configuration file or centralized location for the applications to leverage for customization and configuration. Simply, you push stuff, app reads it, and sets it.

A ton of apps now support managed app configuration, including Microsoft to a degree. For the most part, only Microsoft Outlook supports Managed App Configuration keys, but they have ramped up Outlook support for managed app configuration in recent years.

Additionally, Microsoft recently released a new feature for managed app config for a few apps that lets you block personal accounts, which is a huge step forward. The reality is that many companies cannot afford the investment in Intune/EMS licenses if they are using other MDMs. This makes Managed App Config a necessity that many great apps have adopted strongly, such as WorkDay, Salesforce, Tableau, and many more.

What Problem are we Trying to Solve?

Unlike many vendors I’m not going to shout protect your apps from the rooftops a’la Denzel Washington in Training Day. The question is “What are we trying to solve?” Succinctly, we are trying to avoid the accidental or intentional loss of corporate information or data on our endpoints. Depending on who you are, this means different things.

We can think of this the sharing of information that is not known publicly, which can be compromised in malicious and accidental ways. Some of the examples of DLP that I focus on are:

• Files Opened in Unmanaged Apps which may store them locally
• Backing up or copying data into unmanaged Cloud Storage e.g. iCloud, Box, etc.
• Copying and Pasting of company information into untrusted sources
• Unencrypted storage, communication, or connectivity to corporate resources, data, or information.
• Granting Access to Potentially-dangerous 3rd party applications that could read company data (e.g. 3rd party keyboard applications)
• Allowing Compromised devices to access company data
• Allowing bad/insecure versions of operating systems to access company data

With that in mind, let’s see how both options are addressing these issues today. We will couple App Configuration Keys with MDM capabilities to tell a story that will resonate. Looking at this in any other way is illogical.

Intune App Protection Policies

App Protection Policies have come a long way, but the main issue that we have is their lack of imagination. I won’t regurgitate good documentation, so you can view their list of apps here. Their design is smart conceptually as mentioned earlier after your Azure AD login, it will automatically pull down and apply policies.

Data Protection Framework

My favorite thing about App Protection Policies (APP) is a new concept called the “Data Protection Framework” which was a good move on their part. One of the biggest pain points with APP is it is VERY hard to unring the bell. I’ve spent hours trying to pull back a APP, which is tedious as it is because users know EXACTLY when you change or apply a policy. Microsoft does a nice job with the user experience from a privacy and transparency perspective.

Microsoft accentuates deployment rings, which gained popularity with Windows 10 updates. The concept focuses on 3 different levels of security: Basic, Enhanced, and High. Personally, I’m a big fan of that which follows closely with my design methodology with Workspace ONE Access where I carve apps into low, medium, and high risk.

Data Protection Options

Type	Features	Thoughts
Enterprise Basic Data Protection	-Requires Encryption -Requires Pin on the Application -Block Compromised Devices -Perform Device Attestation and Threat Evaluation of Apps on Android	This level seems basically pointless. Doesn’t really do much for you. If you’re spending the money on EMS, you aren’t doing this one.
Enterprise Enhanced Data Protection	-Block Cloud Sharing -Only Share Content with other APP-protected Apps -Block Save As -Restrict Saving to OneDrive/SharePoint Online -Restrict Cut and Paste -Block Screen Capture and Google Assistant on Android -Restrict Web Data Transfer to Microsoft Edge Block Notifications -Enforce OS Requirements for Launch -Enforce Patch Versions on Android	This is the gold standard for things. When we evaluate and look at configurations, this one is what most people will land on. You will probably tweak it a little bit, but overall this solves most use cases.
Enterprise High Data Protection	-Restrict Dialer Apps to only managed apps on Android -Restrict Dialer Apps to only specific apps on iOS -Can only receive data from other APP-managed apps -Block 3rd party keyboards on iOS -Enforce a 3rd party keyboard whitelist on Android -Block printing -Enforce a stronger Pin -Enforce a higher OS level for Android (e.g. Android 8) -App Wipe Compromised Devices -Block Access based on threat level	This is mostly overkill. There are a few aspects to this you may want to adopt like blocking 3rd party keyboards, which are notorious keyloggers and more heavily relying on Mobile Threat Defense (MTD) products to only grant access when meetings your requirements.

Deploying Data Protection Collections to App Protection Policies

Microsoft supports a nice way of deploying these with their deployment script that let’s you use the JSONs stored in their APP Github. If you need help building a customized JSON based on your requirements, reach out to me and I can build something gorgeous. You can access my customized JSON here.

Now that we discussed the possibility with APPs, we must consider the concerns. The major issue is that they are highly templatized. These work great for OneDrive, Word, PowerPoint, and Excel, but they aren’t particularly useful for apps like Outlook and Teams. Sure, you can block stuff like copy and paste, but they would be more valuable if tailored for the application and its specific use cases.

The APPs are built on the Intune SDK, which means they are a bit restrictive in what you can do. Overall they do a great job, but they are not without challenges. Occasionally bugs will surface that could break your environment for until the next Intune SDK release (that can take up to a month). Let’s close things out by evaluating DLP against APPs to see if it closes the gaps.

The App Protection Policy DLP Results

DLP Area	Does APP do the job?	Thoughts
Files Opened in Unmanaged Apps which may store them locally	YES	You can restrict files to only other APP-Apps or no apps at all.
Allowing Compromised devices to access company data	YES	You can wipe the corp perimeter or block access.
Allowing bad/insecure versions of operating systems to access company data	YES	They do a great job with their conditional launch functionality to use threat level, compromised status, and OS.
Backing up or copying data into unmanaged Cloud Storage e.g. iCloud, Box, etc.	YES	Nice job again being able to restrict to only O365-managed storage.
Copying and Pasting of company information into untrusted sources	YES	You can restrict copy and paste to only other APP-Apps or no apps at all.
Unencrypted storage, communication, or connectivity to corporate resources, data, or information.	YES	They do a nice job of enforcing PINs, which they share across all apps for one publisher on iOS or all apps on Android. It’s a bit of a frustration on iOS as they add 3rd party apps here, but overall not a huge deal. A pro-tip is to have separate policies for unmanaged devices and only enforce passcodes for them.
Granting Access to Potentially-dangerous 3rd party applications that could read company data (e.g. 3rd party keyboard applications)	YES	Yes you can I especially like that you can whitelist specific keyboards on Android.

As you can see, APPs fix a gaping hole in iOS. Put as much lipstick on a pig as you want, iOS is a consumer operating system. We can do a ton to get us somewhere good, but we can only do so much. Let’s see how its opposition does….

MDM and Managed App Config try to close the Gap

Let’s start with the baseline that MDM provides to close some of the gaps in DLP. We have a few nice features in MDM that will certainly help, but the biggest problem is Apple getting in the way. Apple recently moved a bunch of items to supervision, which means BEAT IT BYOD! Let’s quickly highlight those items.

MDM Restrictions

Final Thoughts on DLP

So this has been “A LOT!” Let’s circle back to our previous sentiment. Can MDM and App Config get it done? I think it’s close, but the real issue is a typical Microsoft problem. Follow-through!

I know they hate when I say that, but they should have released the Personal Account blocking for all apps. Why can I use a personal OneDrive on OneNote even though I blocked it in OneDrive itself? That’s a killer. You can work around the copy/paste stuff if you had that fully-baked.

At the end of the day, you could argue that you are REALLY close to being good enough without APPs. Some industries can probably meet their requirements now, but regulated industries like finance still have an issue there.

On the other side, your user experience is much better without a fully-locked down application. I think you could split things up now. Your business users leveraging APPs and IT using AppConfig+MDM. It’s entirely up to your use-cases and what works for you. I have found that APPs tend to bite you in the ass once or twice a year.

Ultimately is the risk truly worth it? I might prefer something like AppConfig+CASB with a solid EDR product like Carbon Black or Windows Defender to have the ultimate surface protection in place. Remember no matter what vendors tell you, there is no panacea for DLP or risk. As always, I strongly suggest reading a few of my recent articles that can help you make decisions. My Intune vs Workspace ONE comparison is great coupled with my review of Microsoft Defender.