The same dilemma shows up in a lot of my projects. Corporate data has to be protected when people open it from unmanaged devices, yet blocking external or mobile users outright isn't an option because they still need to work. For guests, BYOD and field staff, Conditional Access App Control with Microsoft Defender for Cloud Apps (MDCA) is still a practical answer. Browser sessions are routed through a reverse proxy, which lets you block downloads, monitor them, or protect them automatically in real time. If you plan the setup carefully and know where the limits are, it pays off reliably.

Conditional Access App Control works as a reverse proxy

At its core, Conditional Access App Control is a reverse proxy. Conditional Access in Entra ID decides which user sessions qualify, and those sessions go through the MDCA proxy instead of connecting straight to the cloud app. Defender for Cloud Apps can then inspect requests and responses as they pass and apply session policies: blocking downloads, enforcing sensitivity labels or flagging risky actions. The Conditional Access policy is where it all happens. For apps like SharePoint or Exchange Online, you target access from devices that are not compliant or not hybrid-joined and pick the session control “Use Conditional Access App Control.” Everything after that runs in the background.

I draw this diagram of the session flow in almost every workshop and troubleshooting call:

flowchart TD
  user["User (unmanaged device)"] --> ca_policy["Conditional Access Policy"]
  ca_policy --> proxy["MDCA Reverse Proxy"]
  proxy --> app["Cloud App (e.g. SharePoint)"]
  app --> proxy
  proxy --> user

Figure: How a session from an unmanaged device flows through Conditional Access App Control.

In the browser, users hardly notice the proxy. That leads straight to the main limitation, though. Native apps (Outlook, desktop Teams, the OneDrive client and so on) are not supported. Conditional Access App Control only covers browser-based apps, so make sure your users work in a modern, supported browser if you want things to run smoothly.

The setup spans Entra ID and Defender for Cloud Apps

You begin in the Microsoft Entra admin center (Protection → Conditional Access). Create a new policy, choose the apps to protect (SharePoint Online, Exchange Online, Teams) and scope it to the right users or groups. I usually rely on device filters or device tags to catch devices that are non-compliant or not hybrid joined. In the session controls, select “Use Conditional Access App Control” and switch the policy on.

Next, open the Defender portal (defender.microsoft.com → Cloud Apps → Policies → Session policy). This is where you create the rules, for example blocking downloads from SharePoint or OneDrive when the session runs through the proxy, or requiring every download to get a sensitivity label automatically. For guests, I find monitoring activities and raising alerts on risky behavior particularly useful. The session policy documentation covers the configuration details and options.

Practical tip: Test every combination of session policy and Conditional Access setting in your own tenant, and be extra careful when several policies apply to the same app. Side effects tend to hide in exactly those overlaps.

App-enforced restrictions offer a practical alternative

The reverse proxy isn't always the right choice. In some environments Conditional Access App Control causes problems: complex SharePoint solutions or integrations can break, or the browser experience gets inconsistent. SharePoint Online and Exchange Online give you another route with app-enforced restrictions. In this case the Microsoft service itself detects a non-compliant device (based on claims) and limits download, print or sync directly in the web app. You get less flexibility, but in my experience it's often more reliable, and it works in the native web client with no detour through a proxy.

Plenty of admins end up combining the two. They use Conditional Access App Control for the core apps and app-enforced restrictions wherever user experience matters more than control. That's a sensible compromise between security and usability. If you want more background on session controls in Conditional Access, Microsoft has a good overview.

Licensing and compatibility cause most of the trouble

Conditional Access App Control requires Microsoft Defender for Cloud Apps licensing, either through Microsoft 365 E5 or EMS E5, or as a standalone MDCA license for each user it applies to. App-enforced restrictions don't need MDCA at all. If the protection should also cover external users, remember to license the guests. That question comes up again and again in B2B projects.

A mistake I see all the time is ignoring browser and app compatibility. Not every web app works well behind the proxy, and some features (real-time co-authoring in Office Online or certain SharePoint customizations, for instance) may behave unexpectedly. Native client access can't be controlled this way at all; Conditional Access can only block it completely. If you need a good starting point for Conditional Access in general, have a look at my earlier post Conditional Access in Microsoft Entra ID: The First Policies Every Tenant Needs.

The proxy earns its place when you respect its limits

Conditional Access App Control gives you flexible, real-time control and visibility when data is accessed from unmanaged devices. Most tenants I review use only part of what it can do, usually because some detail or technical caveat was overlooked. Keep proxy-based session controls and app-enforced restrictions clearly apart, test properly and watch the licensing. Then you end up with protection that is strong, doesn't get in users' way and holds up in day-to-day use.