SmartScreen is being deprecated, and the CISO who assumed Defender covers it inherits the gap

Open most risk registers and web reputation has one owner and one line: Defender SmartScreen, green. A CISO signed it off years back, an auditor saw "Microsoft Defender" in the control matrix, and nobody went back to ask which surfaces it actually inspects. That is the trap. SmartScreen was never the fleet-wide web-reputation layer it got booked as, and a quiet November 2025 deprecation made the gap visible to anyone who bothers to look.

The assumption was shaky from the start. SmartScreen is browser-bound and reputation-only. It does not see traffic leaving a non-Edge browser, an installed app, or a script. Treat it as endpoint web filtering and you have inherited a control that protects a slice of the attack surface while reporting on all of it.

What KB5071357 removed

In November 2025, Microsoft shipped KB5071357, which deprecates the in-process SmartScreen URL and download checks inside the legacy Internet Explorer runtime and IE Mode on Windows 11. Edge SmartScreen, the Windows Shell check, and Mark-of-the-Web handling all stay. The stated reasoning is that IE Mode exists for enterprise-trusted intranet sites, so its anti-phishing interstitial was treated as redundant.

That holds only if your IE Mode site list is genuinely clean and genuinely enforced. Plenty of enterprises run IE Mode against legacy line-of-business apps that pull in third-party content, redirect off-prem, or landed on the allow list years ago courtesy of someone who has since left. For those fleets, an interstitial that used to fire is simply gone now, and no alert announced it.

Why it was never a fleet control

SmartScreen checks URLs and downloads against a cloud reputation service and shows a warning page. That is a per-browser feature, not a network or endpoint policy. Enable it in Edge and it covers Edge. It does not reach Chrome, Firefox, an Electron app phoning home, a PowerShell Invoke-WebRequest, or a vendor agent pulling an update over HTTPS. No single console lets a CISO confirm "every device, every egress path, web reputation enforced." The control was always partial. The deprecation trimmed one more slice.

The surfaces it never touched

List the ways a corporate endpoint reaches the web and the blind spots are hard to miss:

Every one of those paths resolves a domain first. That is the shared chokepoint, and it sits below the browser, not inside it.

Moving enforcement to the DNS layer

A DNS-layer control is browser-agnostic by design. When a process asks to resolve a malware, phishing, or command-and-control domain, the resolver refuses regardless of which application asked. You stop hoping each browser's reputation engine is switched on and current. Enforce the malware, phishing, and C2 categories plus signed threat feeds such as URLhaus, OpenPhish, and PhishTank at the resolver, and the same decision lands on Chrome, the legacy IE Mode app, and the rogue updater alike.

Proving the control is fleet-wide

The audit question is not "is SmartScreen on." It is "what fraction of egress is covered, and can you show it." NIS2 and ISO 27001 surveillance audits reward an enforcement inventory: which devices point at the managed resolver, which categories and feeds are live, which exceptions exist and why. Pull your resolver query logs and reconcile them against your asset list. Any endpoint resolving through an unmanaged resolver is an uncovered surface, and you found it before the assessor did.

If SmartScreen was the line item, replace it with a control you can inventory. ClearScreen enforces web-reputation categories and signed threat feeds at the DNS layer for every device in a policy group, browser or not, and the resolver logs give you the fleet-wide evidence an assessor asks for. See how the categories and feeds map to enforcement before your next surveillance audit.