The simple answer to the question is No, we cannot Enforce App Protection for Teams mobile apps but we can Require it. These may sound like the same thing, but there is a subtle difference that makes a large impact on our security approach.
Enforce = To carry out effectively
Require = To have a compelling need for
In this post, I am going to dive into this subtle difference and explain what impact this does have on your mobile security.
Enforcing Controls
When we enforce a control we are stating that the control MUST be met otherwise access is not granted. Enforcement is done by Conditional Access as it sits as the "front door" to cloud services and it either grants or blocks access. A Conditional Access policy is a combination on conditions (what scopes a policy to apply) and controls (what must be met for the policy). The key pieces here relating to Teams mobile app use is the controls.
At first glance, it would seem pretty obvious that if we want to make sure the Teams app (and any other Office mobile app for that matter) is protected using an App Protection Policy, we would simply use the Grant control for Require app protection policy.
This control enforces that apps must have an App Protection Policy applied to be granted access to the service, otherwise access is blocked. In effect, this is Enforcing an App Protection Policy.
But when you try to open the Teams mobile app, we get an error that clearly indicates that App Protection Policy is not available for Teams.
Why we get this is not immediately clear as we can create and assign an App Protection Policy to Teams. But when you look at the Microsoft documentation for using App Protection Policy as a grant control, there is a small note that has a big impact.
At first glance, this would appear that Microsoft Teams cannot use this control but rather can only use the control Require approved client app instead. The main difference between these two controls is that the later simply says you have to use the Microsoft Teams app to access Microsoft Teams... not much of a security control there.
So the first thing to try is excluding Microsoft Teams from the Conditional Access Policy. Making this change, you would assume that the policy would apply to all other cloud services, but allow Teams mobile apps access to Microsoft Teams without an App Protection Policy applied.
Even with Microsoft Teams excluded, on your mobile device you will receive that exact same Conditional Access message, "... you're trying to open this resource with a client app that is not available for use with app protection policies..." This was unexpected, but not necessarily surprising because Microsoft Teams is really a collection of underlying service dependencies. In fact, Microsoft Teams is dependent on Exchange Online, SharePoint Online, MS Planner, Microsoft Stream and Skype for Business Online (for voice capabilities).
So understanding that the Teams mobile app would also be communicating with all of those dependent services, that starts to make sense why Conditional Access is still giving us a problem. But, do we really want to exclude all of those services from our policy? Unfortunately, we have to... and then some.
After excluding all of those dependencies, I still ran into errors. Using the "What If" tool in Conditional Access, we can simulate an access scenario to see what Conditional Access Policies would apply under specific conditions.
Even with all these dependency services excluded, including Microsoft Teams, when I run the What If tool to simulate access from an iOS device to the Microsoft Teams service, the Conditional Access Policy still applies. The reason for this is because even though we have excluded the primary dependent services, there are several underlying dependencies that are not exposed as a cloud app in Conditional Access. Therefore, the only way around this is to not use the Conditional Access Policy grant control of Require app protection policy at all. Instead, you have to interpret the note on the Microsoft documentation "...If you require these apps to work, please use the Require approved apps grant exclusively" to mean not just Teams, but if you want to use the Teams mobile app at all, you must use the Require approved apps grant exclusively.
Requiring Controls
So going back to our definitions of enforce and require, we've learned we cannot enforce App Protection Policies for Teams mobile apps. That does not mean we cannot require it though.
I'm not going to walk through the setup of a full App Protection Policy, but know that you can create a policy that can be assigned to Microsoft Teams as well as all other Office apps.
When this policy is assigned to a user, opening the Teams app does pull down the policy and notify that the app is now being managed by your organization.
So we can apply the App Protection Policy to Teams mobile apps and Teams will then adhere to all controls and restrictions imposed by the policy. Now, we are not enforcing the App Protection Policy because we are applying this policy to the app post-authentication (after Conditional Access). But because the policy is assigned to the user, when the app connects to the service the App Protection Policy will be pulled down and applied.
This may raise the question then on can we trick MEM into thinking that the App Protection Policy has been applied when it really hasn't? I don't think we can say there is a guarantee that this cannot happen, but in speaking with several device management experts on my team, there were no instances or known ways to be able to do this.
Once the App Protection Policy is applied, there is no way for the user to remove it without removing their company account from the app, thereby also removing the company data. Once the user adds their corporate account back into the app, the App Protection Policy gets pulled down again and applied.
I also thought, "could there be a corruption or failure in App Protection Policy being applied?" Again, speaking with several experts in the device management space, we could not come up with a single instance where we had encountered this directly or even had heard of scenarios where others had encountered something similar. So trying to think through all the scenarios, we really could not identify one where the App Protection Policy would not apply to the app.
What to Take Away...
So the title and intro to this post may be misleading you to think we cannot secure Teams mobile apps, but that is not the case. With limitations in Conditional Access, specifically around Teams, we cannot enforce that an App Protection Policy be applied. Hopefully this is something Microsoft will address in the future. But, if an App Protection Policy is properly configured and assigned, we can require the Teams mobile app to be protected.
So how should you approach your Conditional Access and App Protection Policy when you need to support the use of Teams mobile apps?
Scope your Conditional Access Policy to apply to the Office 365 cloud service as this includes mainstream and dependency services for Office 365. (note: be mindful of conflicting policies where you may have another policy that applies to Office 365 or other related services, so also use additional conditions like Device Platform to narrow the scope of the policy.)
Configure Conditional Access to use the Require an approved app grant control, which will limit mobile apps to essentially the Microsoft published apps that are compatible with App Protection Policies.
Configure your App Protection Policy to apply to Microsoft Teams (and recommended all other Office 365 related apps to ensure a consistent user experience across all apps).
Scope your Conditional Access Policy and App Protection Policy using the same user groups to ensure consistency across policy assignments.
The last bullet is important as having a mismatch between your Conditional Access Policy assignment and who your App Protection Policy is assigned to can result in scenarios where Teams and other Office-related apps are not being properly protected or unsanctioned apps are being used to bypass app controls.
The end state may not be your preferred configuration as you may want to enforce App Protection Policies, but this approach results in the same outcome.