From time to time, customers have the Ask to allow access to Microsoft 365 on devices not managed by their Organisation. Whether it is because of a bring-your-own-device (BYOD) strategy, the desire to access work files on the go, collaborating with guests, or a multitude of other reasons.
Specifically for VDI: Allow use of the full Teams Desktop Client instead of the limited Virtual Desktop Version. This is expected to improve with the redevelopment of the integration engine, but I have been hearing similar promises since the Skype for Business days.
While this might seem like a simple request initially, as SaaS M365 is theoretically available from anywhere, there is usually a catch: Users should not be able to download files to an unmanaged device (requirements may vary depending on level of security concern).
In this article, I will take a deep dive into the features available through Conditional Access, "app enforced restrictions" and "Conditional Access App Control" (CAAC). These are often the first thing I find configured. The main advantage I see is that they require minimal effort to set up, but it might help that they are the first results when you search for "block file download office 365".
So, while starting points may be immediately obvious, I have a hard time finding detailed behaviours of current options and their known caveats. Therefore, I organized my experiences and thoughts to help you find a more accurate fit for your use case and avoid repeating my mistakes during implementation.
Comparing "app enforced restrictions" and "Conditional Access App Control" on paper
An additional option would be App Protection Policies, but then we would be moving quite heavily into Intune territory – so I’ll keep them separate.
I am not aware of any "free" solutions. To take control of data, you will need a license that includes Conditional Access and for CAAC, "Defender for Cloud Apps" must also be covered.
I recommend M365 Maps for an up-to-date overview of which plans include these features.
Our two Conditional Access checkboxes represent very different controls. "Use app enforced restrictions" is enforced by the applications themselves (shocking, I know). Conditional Access gives the signal, the apps do the protecting. Depending on the chosen settings, these restrictions can either limit users to opening files only in the browser, entirely block access to unsupported files or more. The "applications" in question include the Outlook Web App (not Exchange Online!), SharePoint Online, and by extension, OneDrive, Word Online, Teams, and others.
In contrast, Conditional Access App Controls utilize Microsoft Defender for Cloud Apps (MDCA). After authenticating, the user is redirected to a proxy between them and the application, which then controls the session. Why is it not called MDCA App Controls then? Don’t ask me 🤷♂️
Defender for cloud Apps can do much more than what is listed here. I am focusing on features comparable to app enforced restrictions.
Both solutions provide the desired control over file downloads in Office 365. Let’s examine their behavior more closely to understand how they meet these requirements.
Testing Experience in Teams
My testing setup was straightforward: I enabled app enforced restrictions for SharePoint and Outlook Web App (OWA) using the default settings, and assigned the associated Conditional Access policy to a test user. Additionally, I created a basic session policy in Defender for Cloud Apps and applied the corresponding Conditional Access policy to a different test user.
Detailed setup steps can be found in the Setup chapter.
Most of my testing was conducted through the lens of the new Teams, with periodic validation of behavior using the Edge browser on Windows (without the new session support in Enterprise Edge).
Why Focus on Teams? In many articles on this topic, Teams is often overlooked. This makes sense to some extent since app enforced restrictions are not specifically designed for Teams, and Conditional Access App Controls (CAAC) can be applied to any application. However, given that Teams is one of the most requested applications for these controls, I decided to focus on it.
Moreover, I concentrated on the Teams Desktop Application because it essentially functions as a browser and inherits most behaviors from SharePoint or the Teams browser client. I will highlight any differences where applicable.
I will not be covering the "old" Teams client due to its impending end of availability.
Let’s dive into the testing results.
App Enforced Restrictions
Once you have set up the prerequisites and applied them to a user through Conditional Access, they will encounter the following warning when opening a SharePoint site or Document within:
In the Teams client, this warning is not displayed in the file overview or most of the tabs. It appears only when you are in the Word or Excel plugin, which can be confusing to the user as to why some functions are missing or not working. The application does not inform the user about these restrictions; therefore, they must be aware of these limitations through organizational communication.
Don’t forget to prepare your Helpdesk
The most noticeable and straightforward difference is the removal of the option to download files. Under active app-enforced restrictions, the download option is no longer available in the Files view, just as it is in a SharePoint library.
| app enforced restrictions | Normal | |
|---|---|---|
| Quick Open Options |  |
 |
| Expanded Options |  |
 |
The "Open in desktop app" option is also not consistently hidden across all scenarios. For example, in SharePoint or during 1:1 chats, navigating to files from the desktop app can still show this option.
Clicking this button opens the appropriate Office application (Word, PowerPoint, etc.), but the user is prompted to reauthenticate and is then met with a misleading "Access Denied" message, which might even include a "request permissions from the owner in SharePoint" prompt.
| Options | Error in Word, if "desktop app" is chosen |
|---|---|
 |
 |
If a user has their client set to open files in the desktop app by default, they might encounter the same error message. To avoid this, they must either change their default setting or explicitly choose to open in Teams or a browser each time.
In some views, the option to download files is still available. In these cases, protection falls back to MDCA.
Note: The following screenshot is in German. The "Download" button is highlighted.
| Visible Download Option | Redirects to Error (If in the app, opens Browser) |
|---|---|
 |
 |
Defender for Cloud Apps
I would definitely not recommend relying on Defender for Cloud Apps for managing Office Desktop Applications. During my testing, the behavior was highly inconsistent, which led me to exclude detailed results for these applications. For instance, sometimes downloads were blocked, and other times they were not, leading to unreliable enforcement.
This is a Download Blocking policy as an example. There are no noticeable UI changes apart from the URL changing to a .mcas.com domain. Users will discover whether their download is blocked only when they attempt to click the download button:
Given the inconsistency of these controls in desktop applications, they did not fit what I was looking for in my testing.
A significant issue is that opening a file in the Desktop Application is not recognized as a download. There seems to be no method to prevent a user from using the "Open in > ____ desktop app" option and subsequently saving the file from there.
This limitation makes it essential to combine Defender for Cloud Apps with app enforced restrictions, which would provide the behaviour we already looked at earlier. Alternatively, implementing other methods such as blocking desktop application access or similar can provide the necessary protection.
If there are any solutions or workarounds that I have overlooked, please share them. I have not found any reliable method at the Defender for Cloud Apps level to address this issue, though stronger options may exist, which I will discuss later.
Summary:
App Enforced Restrictions
- Disabled Downloads: In the Teams Files view, app-enforced restrictions disable the download option, similar to the behavior seen in SharePoint libraries.
- Inconsistent ‘Open in desktop app’: This option is not consistently hidden across all contexts, which can lead to confusing "Access Denied" messages when users attempt to open files in desktop applications.
- Inconsistent In-App Warnings: Teams does not notify users of the restrictions in place, causing confusion when functionalities like downloading or opening files in desktop apps are missing or fail to work.
Defender for Cloud Apps (MDCA)
- Unreliable Desktop Enforcement: MDCA is inconsistent in blocking downloads in Office Desktop Applications. Users can bypass these restrictions by using the "Open in > desktop App" option and saving files locally.
- Combined Controls Needed: To achieve robust protection, it is necessary to combine MDCA with app enforced restrictions or implement measures that block desktop app access on personal devices altogether.
For a more concise comparison with slightly different results, consider Peter van der Woude’s Comparison of Data Security on Personal Windows Devices, which includes App Protection Policies in Windows Edge. I discovered his work after conducting my tests and drawing my conclusions, so it did not influence my findings.
Now that we have examined the behaviors of these features, let’s quickly review how to configure them.
Setup
Simply checking the "App Enforced Restrictions" or "Conditional Access App Controls" boxes in a policy is insufficient to get these controls to work. Further configuration is required. Fortunately, these steps have remained relatively unchanged since their introduction, providing ample resources and guidance for implementation. Here, I have compiled some key configuration resources and highlighted important considerations that are not frequently discussed.
App Enforced Restrictions
Basic Steps:
- Configure SharePoint Online for Conditional Access
- Configure Outlook Web App for Conditional Access
- Set Up Conditional Access Policies
Full Guides:
- Step-by-step setup with user experience examples by Kenneth Van Surksum
- Microsoft Learn: Configure SharePoint for Conditional Access
- Microsoft Learn: Configure Outlook Web App for Conditional Access
Nice to Know:
- Propagation Time: It can take up to 24 hours for changes to propagate in SharePoint. Users need to log out of any active sessions for the controls to take effect, especially in Desktop Apps.
- Customize Conditional Access Policies: The default policies created by the SharePoint Admin Center can be replaced with custom policies to better fit your requirements, for Example they are still initially scoped only to SharePoint Online instead of Office 365.
- Always block Legacy Authentication: Conditional Access policies are not respected by "old" authentication methods.
- Organization vs. Site-Level Policies: If you set a policy at the organization level, you cannot apply less restrictive settings at the site level. To implement less restrictive settings, you would need to adjust the organization-level policy and create a solution to auto-restrict new sites.
- Custom SharePoint Applications: If you have custom applications in SharePoint, you may need to exempt individual files necessary for your solution. Let me know how that works.
- Sensitivity Label-Based Restrictions: app enforced restrictions can also be scoped based on sensitivity labels, providing a way to apply different controls based on the classification of the content.
Conditional Access App Control
Basic Steps:
- Enable a Policy with Conditional Access App Control
- Configure Defender for Cloud Apps Policies as needed
- (Optional for maybe better user experience: enforce through Edge)
Configuring Defender for Cloud Apps can be quite complex. For our purposes, here are some basic configuration examples relevant to our use case:
I want to emphasize that these features require an E5 license (Office 365 E5, EMS E5, or M365 E5) as of the time of writing.
Many older guides do not yet reflect the migration of policy management from the separate MCAS portal to the new location at https://security.microsoft.com/cloudapps/policies/management?tid=[yourtenant]. Although the URL has changed, the screenshots and steps in these guides are still applicable.
Do You Have to Enforce Browser Access?
Through our testing, we observed that we have effective control over the Teams Client App. Similarly, the new Outlook Client behaves like the Outlook Web App (OWA), which means we could use it just as well as the Browser. This includes showing the warning, that app enforced restrictions are active, disabling download options, and displaying the "Access Denied" message when attempting to open files in the Desktop versions of Office apps. HOWEVER
| Default Dialog | App Enforced Restrictions Dialog |
|---|---|
 |
 |
If we allow access to Exchange Online, the new Outlook Client is not the only "mobile app and desktop client" that could be used. Legacy clients like Outlook 2016, Thunderbird, and others are still prevalent and do not respect App Enforced Restrictions or Defender for Cloud Apps. Since these clients do not use web traffic, Defender for Cloud Apps session or access policies cannot block SMTP, IMAP, or EWS traffic as they never route through a web proxy.
To manage this, we need to block access to EWS and IMAP while allowing access to clients that adhere to our policies.
Using Conditional Access to block problematic "thick" mail clients from accessing Exchange Online can prevent these clients from bypassing security controls:
Quick CA Policy Reference:
Control Setting Target resources Exchange Online Conditions Mobile apps and desktop clients Grant Block
Unfortunately, blocking access to Exchange Online also impacts the Teams client because it uses Exchange Online calls in the backend.
| Teams Client is Blocked | Due to Exchange Online Block |
|---|---|
 |
 |
Ideally, the new Teams and Outlook clients would identify as browsers because they essentially function as such – or we could create explicit exceptions to the Block. However, they are currently identified as "real" client applications, which leads to them being blocked under the same policies that block other desktop clients.
The "current" solution are Client Access Rules blocking access at the data layer rather than the authentication layer. This is feasible in Exchange On-Premises environments or for tenants that have pre-existing configurations. This solution is however being completely deprecated in Exchange online by September this year, judging by the discussion on the associated blog post currently without replacement.
In some cases, the management of these policies even had to be re-enabled by support for those who still need them.
Additionally, I doubt Exchange Online access is irrelevant to the functionality of Teams. While I did not investigate further, it is likely that blocking Exchange Online could lead to features in Teams misbehaving. If you are aware of any specific examples, your insights would be valuable.
As an Aside, If you create a Defender for Cloud Apps Conditional Access Session Policy, there is a warning at the bottom of the Policy making the supported configuration clear:
So, we close the Exchange Online gap, is our data now completely safe?
Bypassing Protections
Even after blocking full clients from accessing Office and restricting to browser access only, your data may still not be fully protected. Here are some notable ways in which protections can be bypassed, and corresponding mitigation strategies:
App Enforced Restrictions
The "Immersive Reader" functionality in SharePoint can bypass app enforced restrictions. Tools to exploit this feature are readily available. To mitigate this risk, consider the following strategies, prioritized by their desirability:
- App protection Policies in Edge (I assume – I still have to verify)
- Blocking Personal/Unmanaged Devices
- Create an Alert process for the User Agent "ODMTADemand-Transform_ImmersiveReader", for example in Defender for Cloud Apps
Conditional Access App Control
By changing the user agent string in the browser or using a different user agent string for web requests, users can bypass Defender for Cloud Apps (MDCA) and Conditional Access App Control (CAAC). Potential mitigations are again App protection Policies in Edge and just staying away from personal devices.
If you are on Safari, there is no spoofing necessary – the browser is not supported, so it defaults to a bypass.
Additionally, be aware that CAAC has some pretty significant limitations, see the Microsoft Learn documentation on CAAC limitations.
When I would use these Options
This article may seem very critical, but it’s important to scrutinize these options. It’s far easier to acknowledge and accept the risks upfront than to justify them when a CISO or Data Security Officer questions your configuration decisions.
Restricting downloads or copy-pasting isn’t foolproof. Once data is visible on a screen, it can be exfiltrated using Optical Character Recognition (OCR) or simple screen recording. Therefore, achieving 100% protection is unrealistic if a user can view the data. The most effective way to prevent data exfiltration is to block access entirely based on user permissions or device management.
Given the limitations, and without further measures, the goals I see as practical are:
- Preventing Accidental Downloads
- Deterring Mass Data Exfiltration
- Complying with lenient regulations, where best-effort is sufficient
In summary, I am a strong proponent of app enforced restrictions. They are straightforward to implement and effectively prevent accidental downloads while deterring mass exfiltration.
Defender for Cloud Apps offers advanced features that can be beneficial, but it’s essential to conduct thorough testing to ensure it performs as expected in your environment.
Given the current landscape, the most practical approach is to restrict access to browser-only usage. Attempting to support full clients involves complexities that are often unsupported by Microsoft and is not sustainable.
While CAAC and app enforced restrictions are effective tools, they are not the only controls available for securing data. As mentioned throughout this article, there are additional options that can provide better coverage and address the limitations of these controls. Let’s have a look at some:
Alternatives / Extensions
During the course of finishing up this article, I came across Peter van der Woude’s insightful write-ups on related topics. I particularly agree with layering controls for the best combination of usability and protection. Besides the controls discussed there, I can see the potential for several additional options:
Corporate Devices and Virtual Desktops
The most robust solution would be to move entirely to corporately managed devices and / or virtual desktop infrastructure (VDI). This approach ensures full control over the device environment and significantly reduces security risks. However, this might be cost prohibitive for many organizations due to the expenses associated with device management and VDI implementation.
App Protection Policies
Currently, app protection policies are supported only by Edge, but there is potential for expansion to other applications like the Teams Client and the new Outlook in the near future. This extension would provide a new layer of usability and protection, making it easier to enforce security policies across more platforms.
Microsoft Purview
Protecting files with Microsoft Purview can introduce further granularity for sensitive data that requires stringent protection. Purview allows for detailed classification and labeling of documents, helping to apply specific security measures based on the data’s sensitivity. This level of control could ensure that the most critical information remains secure, even if other controls are bypassed.
I plan to do a similar deep dive into App Protection Policies and Microsoft Purview once I get the chance, so keep an eye out if you found this helpful.
If you have different experiences or questions, connect with me on LinkedIn. Sharing thoughts with the community can provide diverse insights and refine strategies further.
Comments