Forum Discussion

KevinJohnson1's avatar
KevinJohnson1
Copper Contributor
Feb 25, 2026

Issues blocking DeepSeek

Hi all,

 

I am investigating DeepSeek usage in our Microsoft security environment and have found inconsistent behaviour between Defender for Cloud Apps, Defender for Endpoint, and IOC controls. I am hoping to understand if others have seen the same.

 

Environment

Full Microsoft security and management suite

 

What we are seeing

 

Defender for Cloud Apps

DeepSeek is classified as an Unsanctioned app

Cloud Discovery shows ongoing traffic and active usage

Multiple successful sessions and data activity visible

 

Defender for Endpoint Indicators

DeepSeek domains and URIs have been added as Indicators with Block action

Indicators show as successfully applied

 

Advanced Hunting and Device Timeline

Multiple executable processes are initiating connections to DeepSeek domains

Examples include Edge, Chrome, and other executables making outbound HTTPS connections

Connection status is a mix of Successful and Unsuccessful

No block events recorded

 

Settings

Network Protection enabled in block mode

Web Content Filtering enabled

SmartScreen enabled

File Hash Computation enabled

Network Protection Reputation mode set to 1

 

Has anyone else had similar issues when trying to block DeepSeek or other apps via Microsoft security suite?

I am currently working with Microsoft support on this but wanted to ask here as well.

microsoft defender for endpoint

2 Replies

  • Lucaraheller's avatar
    Lucaraheller
    MCT
    Mar 03, 2026

    Hi Kevin,

    What you are describing is actually a very common scenario when trying to block web apps like DeepSeek using multiple Microsoft security components at the same time. The behavior is usually related to enforcement configuration rather than detection.

    There are three separate layers involved here:

    – Microsoft Defender for Cloud Apps (MDCA)
    – Microsoft Defender for Endpoint (MDE)
    – Indicator-based blocking (IOCs)

    These do not automatically enforce each other unless properly configured.

    First thing to confirm

    In Defender for Cloud Apps, make sure you have enabled enforcement through Defender for Endpoint.

    Go to:

    security.microsoft.com
    Settings
    Cloud Apps
    Microsoft Defender for Endpoint
    Enforce App Access

    If “Enforce app access” is not enabled, MDCA will only detect and classify DeepSeek as Unsanctioned, but it will not block traffic at the endpoint level. In that case, you will continue seeing successful sessions in Cloud Discovery.

    If enforcement is enabled and you are still seeing traffic, then we need to look deeper.

    Important clarification about Indicators

    Domain and URL indicators in Defender for Endpoint only work when:

    – Network Protection is enabled in block mode
    – The traffic is direct and visible at the network layer
    – The domain is not being resolved via CDN or shared infrastructure

    If DeepSeek is hosted behind a CDN (for example shared Azure, Cloudflare, or other infrastructure), blocking a specific FQDN may not behave consistently because:

    – Some connections resolve to different subdomains
    – Some connections reuse shared IP infrastructure
    – Browser prefetching and DNS caching can show successful connections
    – HTTPS SNI inspection limitations may apply

    That would explain why:

    – Indicators show as applied
    – Connections are still marked as Successful
    – No explicit “Blocked” event appears

    Advanced Hunting observation

    If you see multiple browser processes (Edge, Chrome) connecting and the status shows Successful without a Block action event, that typically means:

    – The domain indicator is not matching the exact FQDN used
    – The connection is happening over a related but different subdomain
    – Or enforcement is not being triggered at the endpoint layer

    Things to verify

    1. Confirm MDCA enforcement via MDE is enabled.
    2. Confirm devices are onboarded and showing healthy in MDE.
    3. Validate Network Protection status using:

    Get-MpPreference | Select EnableNetworkProtection

    Value should be 1 (block mode).

    1. Check if DeepSeek is accessed via alternate domains or APIs.
    2. Review if SSL inspection or proxy configuration is interfering with Network Protection.

    Recommended approach for reliable blocking

    For SaaS web apps like DeepSeek, the most reliable method is:

    – Mark as Unsanctioned in MDCA
    – Enable “Enforce app access” via MDE
    – Ensure devices are properly onboarded and reporting

    If that still does not block traffic, consider:

    – Web Content Filtering with custom domain categories
    – Proxy or firewall level blocking (DNS or URL filtering)
    – Conditional Access App Control (if applicable)

    Important distinction

    Cloud Discovery showing activity does not mean blocking failed. It simply means traffic was observed. You need to look specifically for:

    ActionType == ConnectionBlocked
    or
    NetworkProtectionBlocked

    in Advanced Hunting to confirm enforcement.

    Summary

    What you are seeing is typically due to one of these:

    – MDCA enforcement not enabled
    – Indicators not matching actual domains used
    – CDN/shared hosting behavior
    – Network Protection not enforcing at endpoint level

    If you confirm that “Enforce App Access” is enabled and devices are healthy, we can narrow it down further.

    Let me know what you find and we can go deeper technically.

  • Caleb_A_McDowell's avatar
    Caleb_A_McDowell
    Brass Contributor
    Mar 02, 2026

    Hi Kevin,

    Few things here to diagnose. In MDCA have you set MDE to be the enforcing component of unsanctioned apps? This would be found under: 
    Security.Microsoft.com > Settings > MDCA >Microsoft Defender for Endpoint >Enforce App Access

    Please respond with this if it is on. If it is we can diagnose further, if not please mark this reply as the solution. Thank you! 

    Reference: https://learn.microsoft.com/en-us/defender-cloud-apps/mde-govern