Windows Information Protection (WIP) App Protection Policies: Protected and Exempt; Denied and Allowed – What Do They Mean?

One of things that strikes me as vague in Windows Information Protection (WIP) policies in Intune is configuring targeted apps:  what’s the exact difference between a protected app and an exempt app; and what does allow or deny exactly do for both of those?

A recap on some terminology before explaining what-does-what.

• Targeted apps are ones the WIP service will implement controls over.
• Unenlightened apps cannot differentiate between work and personal data.  They have no idea what WIP is as the developer has not incorporated it.  They can only implement controls if the device is MDM enrolled.
• Enlightened apps have incorporated WIP into the design and can differentiate between work and personal data.  For example, Outlook knows if the email account is tenant one or not.  They can implement controls even if it’s just using MAM.  Such a scenario is called WIP Without Enrollment or WIP-WE.
• Enterprise context is the ownership of data in the application.  You can review this by adding the column in Task Manager.  Data will either belong to the tenant (work) or personal (not work).  It can also be exempt, which means waived from rules.

In the example below, every app you see – protected and exempt – will be controlled if an MDM scenario, but only enlightened ones can be in a MAM scenario.

Now onto protected and exempt, denied and allowed.  When you set these in their various arrangements, what happens?

• Protected apps that you allow will set the enterprise context to the tenant.  This is true of enlightened or unenlightened apps.
  • If enlightened, the app can interact with any work data passed to a work context only.  For example, you can copy and paste between a OneDrive for Business file and your Outlook tenant email, but not your personal email.
  • If unenlightened, the app can interact with any work data passed to it.  It doesn’t understand ‘contexts’, so any part of the app can access it.
• Protected apps that you deny will set the enterprise context to personal.  This is true of enlightened or unenlightened apps.
  • The app cannot interact with any work data passed to it, even if it is something like a configured work website or email account.
• Exempt apps that you allow will set the enterprise context to exempt.  You would only ever do this for unenlightened apps.
  • The app can interact with any work data passed to it.  You are effectively giving the app a waiver to any restrictions.
• Exempt apps that you deny will set the enterprise context to personal.  You would only ever do this for unenlightened apps.
  • The app cannot interact with any work data passed to it.
• Unconfigured apps that you do not target will set the enterprise context to personal.
  • The app cannot interact with any work data passed to it.

I have summarised the various effects of app policies in the following table.

A few conclusions worth noting:

• Denying has the same result under all circumstances: the app will not get work data.  The nuance is that an enlightened one still knows what’s work and what’s not, but blocks you from that work context, unless override mode is on.
• Allowing always lets that app get access to work data, but if it’s enlightened, only to the work context.
• Rather than denying apps, you may as well just not configure them.  The enterprise context and treatment of work data are the exact same.  Simplify your policies.  However, open to comments and feedback on why you may need to do this.
• Exempt enlightened apps are a redundant setting.  An enlightened app is WIP aware and can manage the work/personal divide, so you have no reason not to protect it.  Microsoft’s managed list of enlightened apps are all included in the recommended apps whenever you create a WIP policy.