How to Block Downloads from Unmanaged Devices with Defender for Cloud Apps and Conditional Access

The Real Problem Teams Are Trying to Solve

Many organizations are caught between two realities:

1. Users need access to Microsoft 365 from devices you do not fully manage
2. You do not want sensitive files downloaded freely to those devices

Blocking access entirely is often too disruptive. Salespeople need to open documents while traveling. Executives need quick browser access from a home device. Contractors may need limited access to Teams or SharePoint before a full device management process exists.

That is why this use case matters so much.

You are not trying to answer "should unmanaged devices be allowed at all?" You are trying to answer a more practical question:

How do I allow useful access without letting unmanaged endpoints become an easy data-exfiltration path?

Microsoft's answer is a combination of:

• Microsoft Entra Conditional Access
• Defender for Cloud Apps session controls

Done well, this gives you a middle ground between "full access" and "full block."

What This Setup Actually Does

At a high level, the flow works like this:

1. A user signs in to a protected cloud app such as SharePoint Online, OneDrive, or Exchange Online
2. Conditional Access identifies that the session is coming from an unmanaged device
3. Instead of simply allowing or denying access, the session is routed through Conditional Access App Control
4. Defender for Cloud Apps applies session policies to that traffic
5. The user can browse or work in the browser, but downloads can be blocked, protected, or monitored

This matters because it is not just an authentication decision. It is a session-level control.

Conditional Access vs Defender for Cloud Apps: Who Does What

This distinction confuses a lot of teams, so it is worth making explicit.

Conditional Access decides when session control is invoked

Conditional Access answers:

• Is this user allowed in?
• Is the device compliant?
• Is the location risky?
• Should this session be monitored or restricted by App Control?

Defender for Cloud Apps decides what happens inside the browser session

Defender for Cloud Apps answers:

• Can the user download this file?
• Should the download be blocked or protected?
• Should cut, copy, print, or paste be restricted?
• Should the session be monitored more closely?

You need both pieces. Conditional Access gets the traffic into the control path. Defender for Cloud Apps enforces what the user can do there.

What "Unmanaged Device" Means in Practice

For this design, an unmanaged device usually means a device that is:

• Not marked compliant in Intune
• Not hybrid joined or Entra joined in the way your policy expects
• Not trusted by your organization's device posture rules

This is why your Conditional Access design matters. The session control policy only becomes useful if your CA rules reliably distinguish managed from unmanaged endpoints.

If your device signals are sloppy, the rest of the policy chain will be sloppy too.

Prerequisites Before You Start

Before you configure anything, make sure these basics are true:

• You have Microsoft licensing that supports both Conditional Access and Defender for Cloud Apps session control
• The target apps are integrated with Microsoft Entra ID
• You know which user groups and cloud apps you want to protect
• You understand the user impact for browser sessions
• You have a test user and a test unmanaged device available

Also, be honest about app support. Browser session control works best with supported web application flows. If most of your users work through rich desktop clients, you need to plan for that separately.

The Best First Use Case

If this is your first rollout, start with:

• SharePoint Online
• OneDrive
• A small pilot user group
• Browser-based access only

This is the cleanest scenario and the easiest one to validate.

Step 1: Create the Conditional Access Policy

The first job is to send the right sessions into Conditional Access App Control.

High-level policy logic

• Users: pilot group
• Cloud apps: SharePoint Online and OneDrive
• Conditions: target unmanaged devices
• Session: Use Conditional Access App Control

Example design

1. Go to Entra ID > Protection > Conditional Access
2. Create a new policy
3. Select the target pilot users or groups
4. Select the target cloud apps, such as SharePoint Online and Office 365
5. Configure device conditions so the policy applies when the device is not compliant or otherwise unmanaged
6. Under Session, choose Use Conditional Access App Control
7. Start in Report-only if your environment needs policy validation first

Important note

Do not mix too many goals into one CA policy. If one policy tries to do MFA enforcement, location filtering, device restrictions, and App Control routing all at once, troubleshooting gets harder fast.

Keep the pilot clean and understandable.

Step 2: Create the Defender for Cloud Apps Session Policy

Once the session is routed through App Control, you define what is actually restricted.

The policy type you usually want

For this use case, the most common control is a session policy focused on:

• Blocking downloads
• Protecting downloads
• Monitoring risky activity

Basic policy pattern

1. Go to Microsoft Defender portal > Cloud Apps > Policies > Policy management
2. Create a new Session policy
3. Choose the activity control you want
4. Scope the policy to the target app, such as SharePoint Online or OneDrive
5. Set the device tag or session context to unmanaged devices
6. Choose the action:

• Block
• Protect
• Monitor

Block vs Protect vs Monitor

This choice affects both security and user experience.

For many teams, Protect is the most balanced option once the environment is mature enough to support it. For early pilots, Block or Monitor are usually easier to validate.

What Users Will Actually See

This part matters because poor user communication causes needless tickets.

When browser session control is active:

• Users may notice the session is proxied
• Certain actions, especially downloads, may be blocked
• Some experiences may differ between browsers
• The user may see messaging that the action is restricted by policy

Historically, some users notice the session proxied through a .mcas.ms domain in certain flows. In other scenarios, especially in Edge with tighter Microsoft integration, the experience can feel more native.

Do not assume the session will look identical across browsers.

Browser Behavior: Edge vs Other Browsers

This is one of the most practical parts of the rollout.

Edge

For Microsoft-heavy environments, Edge often gives the smoothest experience for browser session controls and can support more integrated protection behavior.

Other browsers

Other supported browsers can still work, but the experience may be less seamless, and some users may notice the proxied session behavior more clearly.

If user friction matters, test:

• Microsoft Edge
• Chrome
• Safari if relevant to your workforce

Document what users should expect in each one.

Native App Bypass: The Mistake Many Teams Miss

Blocking browser downloads is not enough if users can simply open the same app in a rich client and download from there.

This is where teams get false confidence.

Example

You block downloads from unmanaged devices in browser sessions for SharePoint Online.

But the same user signs into the OneDrive sync client or opens the file through a desktop Office app on the same unmanaged machine. If that path is not separately controlled, your browser restriction does not solve the problem you think it solves.

How to Handle Native Clients

You need to decide whether unmanaged devices should also be restricted from:

• OneDrive sync
• Desktop Office clients
• Mobile app sessions

This is typically handled with additional Conditional Access logic, including app targeting and client app conditions.

The key lesson is simple:

Session control is mainly a browser-session solution. Do not confuse it with universal device containment.

A Clean Pilot Design

If you want a practical rollout that teaches you something useful, use this structure:

1. Pilot group of 5 to 15 users
2. SharePoint Online and OneDrive only
3. Browser-based access only
4. Download action set to Block or Monitor
5. Desktop sync and rich clients separately restricted if needed
6. Clear user communication before the test begins

This will teach you much more than throwing the policy at the whole company and hoping for the best.

Testing the Policy Properly

Testing is where many rollouts go wrong.

Use a real unmanaged device

Do not validate the experience only from a managed admin laptop with a few policy toggles changed. Use an actual unmanaged endpoint or a realistic test VM.

Start with a fresh sign-in session

Conditional Access and session control testing can be misleading if old browser cookies are still active. Use:

• A private browser session
• Sign-out and sign-in again
• Browser cache cleanup if needed

Test all the actions that matter

Do not stop at "user can open the file." Test:

• Download
• Preview
• Edit in browser
• Open in desktop app
• Print if relevant
• Copy or export behaviors if relevant to your policy design

Validate with logs

Check both:

• Conditional Access sign-in results
• Defender for Cloud Apps activity and policy logs

If the behavior looks wrong in the browser, the logs usually tell you whether the session was never routed into App Control or whether the session policy itself failed to match.

Troubleshooting: Policy Is Not Triggering

This is the most valuable section for many admins.

If the policy does not appear to work, check these in order.

1. The session never hit App Control

If Conditional Access is not routing the session to App Control, Defender for Cloud Apps cannot enforce the browser restriction.

Check:

• The CA policy assignment
• The targeted users and apps
• The device condition logic
• The sign-in logs to confirm the App Control session path was applied

2. The device is not being evaluated as unmanaged

If the device is accidentally considered compliant or trusted, the policy path may never activate.

Check your device filters and compliance assumptions carefully.

3. The user is not actually using the browser path you designed for

If they open the app in a desktop or mobile client instead of the browser, the browser session policy will not help.

4. The session policy is too narrow

If the session policy matches only specific apps, activities, or file conditions, you may have built a rule that is technically correct but operationally too restrictive to trigger during your test.

5. Existing sessions are confusing the test

Old session cookies can create misleading results. Start again with a clean session.

Troubleshooting: Users Can Still Download

If downloads still happen, the usual causes are:

• Native client access is still allowed
• The session was not proxied
• The action selected was Monitor instead of Block
• The app or activity did not match the session policy
• The user was on a managed device during the test and did not realize it

This is why pilot testing with one known device and one known user matters so much.

When to Use Protect Instead of Block

Blocking is simple and strong, but it is not always the best long-term answer.

If your organization already uses Microsoft Information Protection or Purview labeling well, Protect can be better because:

• Users can still work with files
• The file remains controlled after download
• Security can reduce friction without giving up governance completely

That said, Protect adds operational complexity. If your labeling and rights-management model is still immature, start with Block or Monitor first.

Where This Fits in a Zero Trust Program

This is a strong Zero Trust control because it is:

• Context-aware
• Session-aware
• Focused on data access rather than just sign-in

It also connects naturally with the other identity controls you already cover.

Use this alongside:

• [Microsoft Entra ID Conditional Access](/blog/microsoft-entra-id-conditional-access-setup) for access decisions
• [Entra ID break glass account planning](/blog/entra-id-break-glass-account-setup-monitoring) so admin recovery paths remain safe
• [ZTNA vs VPN](/blog/zero-trust-network-access-ztna-vs-vpn-complete-guide-2026) for the wider remote-access strategy
• [Azure Policy vs Defender for Cloud](/blog/azure-policy-vs-defender-for-cloud-difference) to help teams understand where identity and data-session controls sit compared with resource governance

Recommended Rollout Sequence

If I were implementing this in a real tenant, I would use this sequence:

1. Pick one data-sensitive app such as SharePoint Online
2. Pilot with a small group
3. Route unmanaged browser sessions into App Control
4. Start with Monitor or Block for downloads
5. Test Edge and at least one non-Edge browser
6. Decide how native clients will be handled
7. Expand to broader user groups only after the logs and user experience are understood

This keeps the project realistic and avoids the classic "the control technically exists, but nobody trusts it" outcome.

Final Checklist

• [ ] Conditional Access correctly identifies unmanaged devices
• [ ] The session is routed into Conditional Access App Control
• [ ] A Defender for Cloud Apps session policy exists for the target apps
• [ ] You tested the behavior in a fresh browser session
• [ ] You tested native client bypass scenarios
• [ ] Pilot users were informed about the expected experience
• [ ] Logs were reviewed in both Entra and Defender

Frequently Asked Questions

How do I block downloads from unmanaged devices in Microsoft 365?

The common approach is to use Entra Conditional Access to route unmanaged browser sessions into Conditional Access App Control, then use a Defender for Cloud Apps session policy to block or protect downloads.

What is the difference between Conditional Access and Defender for Cloud Apps session policies?

Conditional Access decides whether the session should be allowed, blocked, or routed into App Control. Defender for Cloud Apps session policies decide what the user can do inside that browser session.

Why is my Defender for Cloud Apps session policy not triggering?

Usually because the session was never routed through Conditional Access App Control, the device was not evaluated as unmanaged, the user used a native client instead of the browser, or the session policy conditions did not match.

Can users bypass this with desktop or mobile apps?

Potentially yes, if you only configured browser session controls. That is why native client access needs its own Conditional Access design.

What does `.mcas.ms` mean?

It is associated with the proxied browser session experience used by Defender for Cloud Apps in certain flows. Seeing it usually indicates the session is being routed through App Control.

Closing Thought

Most organizations do not really want to choose between "full unmanaged access" and "no access at all." They want a controlled middle ground that lets people work without turning every personal device into an unmonitored download point.

That is exactly where Defender for Cloud Apps session control shines. When you combine it with well-designed Conditional Access policies and realistic testing, you can give users the access they need while keeping a much tighter grip on how sensitive data leaves the browser.