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 Experts

1 Reply

  • Pbv85's avatar
    Pbv85
    MCT
    Mar 27, 2026

    Hi KevinJohnson1​ 

    What you are seeing usually means the block isn’t being fully enforced on the endpoint even though the domains or URIs exist as Indicators.

    For Chrome and others, Defender for Endpoint enforces URL or domain blocks via Network Protection (Edge uses SmartScreen), so if Network Protection is not enabled in Block mode or Defender AV prerequisites aren’t fully met (i.e active mode, cloud-delivered protection, behavior monitoring), you will still see outbound HTTPS attempts but no block events. 

    For non‑Edge browsers, Defender derives the FQDN from the TLS handshake, so if traffic uses QUIC or HTTP3 or Encrypted ClientHello (ECH), domain blocking can be bypassed or effective and you’ll again see “successful” connections with no recorded blocks.

    To make this consistent, I would say ensure your indicators are Domain or FQDN based e.g. deepseek.com, not the full HTTPS URL paths which are limited outside Edge and verify Custom network indicators and  Network Protections  block mode are enabled and deployed to the relevant device groups.

    Allow at least 2-3 hours for the enforcement to be in effect. 

    If you find the answer useful, please do not forget to like and mark it as a solution