In a lot of Microsoft 365 and Azure projects, I still find network protection in Defender for Endpoint switched off or simply forgotten. That surprises me, because it's one of the most effective ways to protect endpoints from web-based threats, and it rarely gets in users' way. It pays off most when you deploy network protection Defender via Intune in block mode, because then it covers Chrome, Firefox and any other browser on Windows, not just Edge. Below I go through a real-world deployment: configuring block mode in Intune, maintaining indicator-based allow and block lists, and setting up web content filtering by category.

Network protection works at the network level and is not an ASR rule

Network protection is part of Defender for Endpoint. It's included in Plan 1, but you get much more out of it with Plan 2 for reporting and central management. Browser-based solutions only see what happens inside the browser. Network protection works at the network level, so it steps in whenever a user tries to reach a risky URL, no matter which browser they use. That makes it far more dependable than browser extensions or controls that only apply to Edge. It's also not the same thing as ASR rules, although you need both for proper attack surface reduction.

Every Intune rollout should start in audit mode

I always start with audit mode. In Intune, go to Endpoint security → Antivirus or create an attack surface reduction profile. That's where you'll find the "Enable Network Protection" setting. Set it to Audit mode first. It logs what would have been blocked without interrupting anyone, so you can catch false positives and business applications that depend on unusual domains. When the reports look clean, switch to block mode and enforce it. Nearly every rollout I've done turned up some SaaS tool or legacy app nobody had mentioned, and it would have broken without that audit phase.

A typical Intune configuration profile might use this JSON (for custom OMA-URI or direct assignment):

{
  "@odata.type": "#microsoft.graph.windowsDefenderNetworkProtectionConfiguration",
  "networkProtection": "block"
}

Prerequisites: You need Windows 10/11 Enterprise and a device onboarded to Defender for Endpoint (MDE). Without at least Plan 1, your policy and reporting coverage will be limited.

Pro tip from the field: turn on tamper protection at the same time. If you don't, a tech-savvy user (or malware) can just disable network protection locally, and that's a gap you shouldn't leave open.

Web content filtering adds category policies and useful reports

Once network protection is running, keep going. In the Defender portal, under Settings → Endpoints → Web content filtering, you can create policies by content category and block or audit things like adult content, phishing, social media and uncategorized domains. Assign the policies to device groups so you control who gets what. The built-in reports are very helpful here. They show exactly which URLs get blocked and which users keep hitting those blocks. This is usually where my assumptions get corrected. More than once, I've learned that a business unit needed special access, or that a category produced far more blocks than anyone expected.

In many tenants, I run web content filtering in audit mode to keep an eye on risky categories and then enforce blocking only for high-risk or heavily regulated departments. Policy scoping and reporting have matured enough that this works well even in large environments.

Indicators let you allow or block specific URLs and domains

Categories aren't always precise enough. Under Indicators in the Defender portal (Settings → Endpoints → Indicators), you can set allow or block actions for individual domains and URLs. Typical cases are trusted SaaS partners, external test platforms, or domains the category filters have classified wrongly. Indicators are managed centrally and work independently of category filtering. For the details, Microsoft's documentation on indicator IP/domain management is a good reference.

If you combine indicator lists, category filters and audit mode, you get a fine-grained and practical setup. Most organizations I work with haven't made full use of that yet.

Network protection, filtering and indicators check each request in sequence

The following Mermaid diagram shows how network protection, web content filtering and indicators work together when someone opens a website. Pay attention to the order:

flowchart TD
    U["User opens website"] --> NP["Network protection checks destination"]
    NP --> IND["Indicators (URL/domain)"]
    IND --> WCF["Web content filtering categories"]
    WCF --> ACT["Action: Block/Allow/Audit"]

Figure: The order of checks during a website visit with network protection enabled.

In my view network protection delivers a browser-independent layer of defense

When you deploy network protection Defender via Intune in block mode, you get a centrally managed layer that doesn't depend on the browser. It stops phishing, drive-by malware and risky content, even for users who stay on Chrome or another browser. The biggest benefit for me is the reporting, together with the option to fine-tune with allow and block indicators and content category policies. Start with audit mode, go through the logs, and only then enforce blocking. It saves you a lot of trouble later. And don't leave out tamper protection or ASR rules, because endpoint defense only holds up when the layers work together.

For more on attack surface reduction and endpoint controls, have a look at my article on rolling out ASR rules in Defender for Endpoint via Intune.