Web content filtering in Defender for Endpoint: network protection, categories and indicators

Web content filtering lets Defender for Endpoint block whole categories of websites, such as gambling or newly registered domains, on managed devices wherever they are and without a proxy in the path. The catch is that it only works where network protection or SmartScreen is actually enforcing, so most "the filter doesn't block" and "the filter blocks the wrong thing" tickets are really about those prerequisites. In this post I'll set up network protection from Intune, build a category policy scoped to device groups, add indicators for exceptions, and show how to see blocks in reports and hunting.

Prerequisites#

• Licensing: Defender for Endpoint Plan 1 or Plan 2, Defender for Business, Microsoft 365 Business Premium, or a suite that includes them (Microsoft 365 E3, E5 or A5, Windows Enterprise E5).
• Operating systems: Windows 11, Windows 10 1607 or later or Windows Server 2019 or later with current Defender Antivirus updates; macOS and Linux versions supported by network protection.
• Browsers: Microsoft Edge, Chrome, Firefox, Brave and Opera. Edge is enforced by SmartScreen, the others by network protection.
• Defender Antivirus in active mode with real-time protection, behavior monitoring and cloud-delivered protection on. Network protection doesn't run in passive mode.
• Permissions: in unified RBAC, Security data basics (read) to see policies and reports, Response (manage) to create them, and Core security settings (manage) to turn the feature on.

How it works#

Web protection in Defender for Endpoint has three layers that share one enforcement engine: custom indicators (your own allow, warn and block lists), web threat protection (Microsoft's phishing and malware intelligence) and web content filtering (categories). They are evaluated in that order of precedence, and within indicators allow beats warn, which beats block. That ordering is what lets an allow indicator punch a hole in a category block. In Edge, SmartScreen does the work and shows an in-browser block page. In every other browser and process, network protection reads the destination name from the TLS handshake and blocks the connection, so the user sees a failed connection plus a Windows toast such as "This content is blocked". Full URL paths can be blocked only in Edge; other browsers are filtered by domain, and only if QUIC and Encrypted Client Hello are disabled in them.

Step-by-step#

Step 1: Turn on network protection from Intune#

In the Microsoft Intune admin center, go to Endpoint security › Antivirus › Create policy, platform Windows, profile Microsoft Defender Antivirus. In the Defender section set Enable network protection to Enabled (audit mode) for a pilot ring and later to Enabled (block mode). Block mode is required for web content filtering and indicators in non-Edge browsers; audit only logs. In the same profile make sure real-time protection, behavior monitoring and cloud-delivered protection are allowed. The Microsoft Defender for Endpoint security baseline carries the same setting as Enable Network Protection, and the same antivirus policy exists under Endpoint security policies in the Defender portal. For other MDM tools the Policy CSP is ./Device/Vendor/MSFT/Policy/Config/Defender/EnableNetworkProtection with 0 off, 1 block and 2 audit. Edge needs SmartScreen enabled, which the Edge security baseline or an Edge settings catalog policy covers. Windows Server is opt-in: set AllowNetworkProtectionOnWinServer to true first, and keep datagram processing off on busy UDP roles such as domain controllers and DNS servers.

Step 2: Turn on web content filtering#

In the Microsoft Defender portal, open Settings › Endpoints › General › Advanced features (Microsoft's documentation now calls this page Optional features) and make sure Web content filtering is On, then save.

Step 3: Create a category policy scoped to device groups#

Go to Settings › Endpoints › Rules › Web content filtering › Add policy. Name it, pick the categories to block, choose the device groups on the Scope page (the default is all), review and submit. The parent categories are Adult content, High bandwidth, Legal liability, Leisure and Uncategorized, each with child categories you can select individually, for example Gambling, Streaming media & downloads, Hacking or Newly registered domains. Everything you don't block is audited, so a policy with no categories is a pure audit policy and a sensible first step. Policies can take up to two hours to reach devices, and where several policies hit one device the more restrictive setting wins per category. Defender for Business and Business Premium get a single policy that applies to everyone.

Step 4: Allow specific sites with indicators#

To exempt one site from a blocked category, go to Settings › Endpoints › Rules › Indicators, open the URLs/Domains tab, select Add item, enter the URL or domain, set the action to Allow, scope it to device groups and save. Indicators need the Custom network indicators advanced feature turned on. The same wizard creates Block and Warn indicators for your own threat intelligence; Warn lets users bypass for 24 hours by default. Enforcement usually follows within two hours but can take up to 48. Only external IP addresses are supported, and when two URL indicators overlap the longer path wins.

Step 5: Dispute a wrong category#

If a domain is miscategorised, allow it with an indicator so users keep working, then open Reports › Web protection, select Web content filtering categories details, go to the Domains tab, select the ellipsis next to the domain and choose Dispute category. Microsoft reviews the request within one business day.

Verify#

On a pilot device, confirm the mode Defender holds:

Get-MpPreference | Select-Object EnableNetworkProtection
# 0 = off, 1 = block, 2 = audit

Then browse to Microsoft's network protection test site, https://smartscreentestratings2.net, in Chrome or Firefox. In block mode you get a failed connection and a "Connection blocked" toast; in audit mode the page loads and an event is written. In Event Viewer, under Applications and Services Logs › Microsoft › Windows › Windows Defender › Operational, event 1125 is an audited connection, 1126 a blocked one and 5007 a settings change. Test a blocked category in Edge too; since Edge 124 it shows the organisational block page for web content filtering. In the portal, Reports › Web protection has Web activity by category, Web content filtering summary and Web activity summary for categories, and Web threat detections over time and Web threat summary for threats and indicators; the category card needs some history before it shows much. For individual blocks, hunt:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in ("ExploitGuardNetworkProtectionBlocked", "SmartScreenUrlWarning")
| extend f = parse_json(AdditionalFields)
| extend Source = iff(ActionType == "SmartScreenUrlWarning",
                      tostring(f.Experience), tostring(f.ResponseCategory))
| project Timestamp, DeviceName, ActionType, RemoteUrl, InitiatingProcessFileName, Source
| order by Timestamp desc

CustomPolicy means web content filtering, CustomBlockList a custom indicator, CasbPolicy a Defender for Cloud Apps block, and Malicious or Phishing web threat protection. That one column answers "why was this blocked?" faster than anything else.

Tips and gotchas#

• Chrome isn't filtered but Edge is. Network protection isn't in block mode, Defender is in passive mode, or the device isn't onboarded. Check EnableNetworkProtection first.
• Edge isn't filtered but Chrome is. SmartScreen is disabled in Edge.
• A site is blocked unexpectedly. Read the Source column. CasbPolicy means an unsanctioned app in Defender for Cloud Apps created the indicator; fix it there. CustomPolicy means a category; allow and dispute. Blocking Uncategorized catches every domain registered in the last 30 days, which breaks legitimate new vendors.
• Only parts of a site are blocked in Chrome. Full-path blocking works only in Edge; other browsers see domains.
• Local proxies and Application Guard. A local proxy such as Fiddler hides the browser's process name, and isolated Application Guard sessions aren't filtered.
• Latency. Give new policies and indicators two hours before deciding they don't work.
• Audit first. An audit-only policy for a few weeks shows real usage per category and device group before anyone is blocked, and makes the conversation with HR and legal about which categories to block much easier.

References#

• Web content filtering in Microsoft Defender for Endpoint
• Configure network protection in Microsoft Defender Antivirus
• Web protection in Microsoft Defender for Endpoint