> ## Content Index
> Fetch the complete content index at: https://blog.rickzeleznik.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# SharePoint Blocked the Download, OneDrive Synced It Anyway
- URL: https://blog.rickzeleznik.com/sharepoint-blocked-the-download-onedrive-synced-it-anyway/
- Published: 2026-10-17T16:40:01.000Z
- Updated: 2026-10-17T16:40:01.000Z
- Author: Rick Zeleznik
- Tags: Cloud App Security, Conditional Access Policies, M365, Microsoft 365, Purview, SharePoint, Planning, Zero Trust

## What I discovered while testing authentication contexts, and why protecting sensitive information requires more than restricting access to SharePoint.

I've been experimenting with Microsoft Entra authentication contexts as a way to apply more granular Conditional Access policies to individual SharePoint sites.

One of the scenarios I've been testing involves allowing users to access a particular SharePoint site from any network, but restricting downloads when they're outside a defined set of trusted network locations. There's a blog post on this process [here](https://blog.rickzeleznik.com/how-to-block-downloads-from-specific-sharepoint-sites-using-conditional-access/). 

The configuration works as expected in the browser. Users connecting from an untrusted network are redirected through Microsoft Defender for Cloud Apps (the familiar “.mcas.ms” URL rewrite), where downloads are blocked.

But I ran into something interesting when I started testing OneDrive synchronization.

**What Microsoft Says**

Microsoft's documentation includes a fairly definitive statement about authentication contexts:

> The OneDrive sync app won't sync sites with an authentication context.

Source: [Conditional Access policies and SharePoint — Microsoft Learn](https://learn.microsoft.com/en-us/sharepoint/authentication-context-example?ref=blog.rickzeleznik.com)

That's a significant limitation, particularly for organizations that depend on OneDrive synchronization for everyday collaboration.

Except that's not quite what I experienced.

**What I Actually Found**

Using a domain-joined Windows computer, I tested OneDrive synchronization against a SharePoint site protected by an authentication context and a location-based Conditional Access policy.

The results were interesting:

| **Scenario**                                                   | **Result** |
| -------------------------------------------------------------- | ---------- |
| Establish OneDrive sync from a trusted network                 | Works      |
| Establish OneDrive sync from an untrusted network              | Fails      |
| Download through the browser from an untrusted network         | Blocked    |
| Continue an existing sync after moving to an untrusted network | Works      |
| Download newly added files through that existing sync          | Works      |
| Upload new files through that existing sync                    | Works      |

The last two results are particularly important.

This wasn't simply a matter of previously synchronized files remaining available locally. OneDrive continued transferring new files in both directions after the computer moved to an untrusted network.

Meanwhile, the browser was correctly enforcing the download restriction.

**So Is This a Security Problem?**

Potentially, but I think there's an important distinction here.

The computer in my testing was still an organization-managed, domain-joined device. Moving it to an untrusted network didn't remove the security protections already in place on the endpoint.

Assuming the device is properly secured, another computer sharing that network doesn't suddenly gain access to its synchronized SharePoint content.

The more meaningful observation is that **restricting browser downloads doesn't necessarily prevent files from reaching a device through other mechanisms**.

In fact, Microsoft's Defender for Cloud Apps documentation explains that session controls apply to browser-based access, while native desktop applications may require additional access controls.

[Microsoft Defender for Cloud Apps — Conditional Access App Control](https://learn.microsoft.com/en-us/defender-cloud-apps/proxy-deployment-aad?ref=blog.rickzeleznik.com)

The behavior I observed is consistent with that distinction, even though it doesn't align neatly with the documented statement that OneDrive synchronization won't work with authentication contexts.

**Protecting the Content, Not Just the Site**

For me, this reinforces something that should be central to any Microsoft 365 information protection strategy.

**Preventing someone from downloading a file isn't the same as protecting the file itself.**

Conditional Access, device compliance, sensitivity labels, and Data Loss Prevention each address different aspects of that problem.

A properly configured sensitivity label can apply encryption and usage restrictions that remain with a supported document after it's downloaded or synchronized. Microsoft Purview DLP can provide additional controls around how sensitive information is shared, transferred, or used.

Of course, simply applying a sensitivity label doesn't automatically provide those protections. The label needs to be configured appropriately, and the relevant DLP policies need to be in place.

The point is that we shouldn't depend exclusively on the security boundary around the SharePoint site to protect the information stored within it.

**Final Thoughts**

I don't interpret these results as evidence that authentication contexts are broken, or even necessarily that the observed behavior represents an unacceptable security risk.

But I would be cautious about assuming that a successful browser download restriction means content is equally protected across every access method. 

My testing also demonstrates that OneDrive synchronization can function under circumstances where Microsoft's current documentation says that it shouldn't and it's worth understanding before making deployment decisions. In my case, I was quite literally making significant changes to my strategy based on Microsoft’s language before I tested it firsthand. Also worth noting that just because it works, its certainly not guaranteed that it will continue to work or that it's suddenly a Microsoft-supported behavior.

Ultimately, I think the more useful lesson is about security planning.

**We need to protect sensitive information based on what it is, not just where it's stored or the network from which someone accesses it.**

Authentication contexts can be one part of that strategy. Properly configured sensitivity labels, endpoint protections, and DLP controls need to do their part as well. If the sensitivity of a particular piece of content merits it, a more zero-trust, defense-in-depth approach is necessary.