Every claim below is a direct quotation from Microsoft Learn, checked against the live pages in October 2026, with the source page named. This isn't a theoretical gap — it's documented, intended behavior of Microsoft Defender for Endpoint's Network Protection component.
Defender for Endpoint's custom indicators let you block a specific URL path — not just a domain — for
example https://contoso.com/block. Microsoft's own documentation is explicit that this only works
in one browser:
https://contoso.com/block).
This indicator matches resources under the /block path on contoso.com. Note that HTTPS URL paths will only
be matched in Microsoft Edge; HTTP URL paths can be matched in any browser."
— Overview of indicators in Microsoft Defender for Endpoint, learn.microsoft.com/en-us/defender-endpoint/indicators-overview
The same constraint is repeated, word for word in effect, on the indicator-configuration page:
This isn't a licensing restriction — it's a structural limit of how non-Edge browsers are protected. Outside Edge, Defender relies on Network Protection, which inspects traffic below the browser, at the network layer:
In plain terms: Network Protection reads the hostname from the unencrypted part of the TLS handshake (the ClientHello / SNI field) before the encrypted session starts. The actual URL path and query string travel inside that encrypted session and are never visible to a network-layer control — in any browser other than Edge, where SmartScreen sits inside the browser itself and sees the request before it's encrypted. Microsoft's Web Content Filtering documentation states the same consequence for its own category blocking:
On macOS and Linux, the gap widens further:
Separately from browser scope, the entire custom-indicator system has a hard cap:
File, certificate, IP and URL indicators all share that one ceiling, so large threat-intel feeds or incident response engagements can use it up quickly.
An organization can invest fully in Defender for Endpoint P1/P2, Sentinel, and curated threat intelligence, and still have zero URL-path enforcement the moment a user opens Chrome, Firefox, or Safari — not because the intelligence is wrong, but because the enforcement point (Network Protection) was never designed to see inside an encrypted request outside of Edge. Cybereinforce closes exactly this gap: a native browser extension enforces the same Defender IOC policy at the point where the URL is still visible — inside the browser itself — across Chrome, Firefox, Safari and Edge, on Windows, macOS, Linux, iOS and Android. URL indicators can live in Cybereinforce, leaving Defender's 15,000 slots for file, certificate and IP indicators.
| # | Claim | Microsoft Learn page |
|---|---|---|
| 1 | HTTPS URL-path indicators only match in Microsoft Edge | learn.microsoft.com/en-us/defender-endpoint/indicators-overview |
| 2 | Full URL path indicators can only be blocked in Microsoft Edge | learn.microsoft.com/en-us/defender-endpoint/indicator-ip-domain |
| 3 | Network Protection reads only the TLS ClientHello / FQDN, not the URL path | learn.microsoft.com/en-us/defender-endpoint/network-protection |
| 4 | For HTTPS traffic, full URL paths can be blocked only in Microsoft Edge | learn.microsoft.com/en-us/defender-endpoint/web-content-filtering |
| 5 | QUIC / Encrypted Client Hello must be disabled for non-Edge FQDN blocking | learn.microsoft.com/en-us/defender-endpoint/network-protection |
| 6 | Network Protection must be in block mode for non-Edge enforcement | learn.microsoft.com/en-us/defender-endpoint/network-protection |
| 7 | 15,000 indicator-per-tenant limit, no increases supported | learn.microsoft.com/en-us/defender-endpoint/indicators-overview |
All sources checked October 2026 on Microsoft Learn (learn.microsoft.com). Quoted for accuracy; Cybereinforce is not affiliated with Microsoft. Documentation is subject to change — verify current behavior against the live pages before relying on this brief for a compliance submission.