Issues blocking DeepSeek

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.