Microsoft Defender Adds Internet Exposure Recommendation: Turning Attack Surface Visibility Into an Action Plan

Microsoft has introduced a new security recommendation in Microsoft Defender that identifies devices accessible from the public internet, classifies whether that access is expected, and gives security teams a structured path to reduce what isn't. Announced on June 9, 2026, the feature lives under Exposure management in the Defender portal and targets a problem most organizations know they have but struggle to quantify: how many of their machines can actually be reached by an outside attacker, and which of those should be.

What changed

The core shift is interpretive, not just detective. Plenty of tools already tell you a device is internet-facing. Defender's new recommendation tries to answer the harder question of why it is reachable and whether that is intentional. It pulls from two signal sources: external scan telemetry that confirms a device responds to inbound connections from the public internet, and network telemetry showing inbound connections originating from external sources. Correlating both reduces the false positives that plague pure scan-based discovery, where a device might appear reachable in one snapshot and not another.

The recommendation sorts devices into three states. Exposed devices are reachable from the internet and need review. Compliant devices are either not externally reachable or have had their exposure explicitly validated and accepted by the security team. Not applicable devices show no inbound exposure at all. That middle category matters more than it looks. Most attack surface tools treat any internet-facing asset as a finding to be cleared, which trains analysts to dismiss alerts wholesale because so many exposures are legitimate web servers, VPN endpoints, or communication gateways. By letting teams mark intentional exposure as accepted, Defender keeps the noise down and preserves signal for the exposures nobody authorized.

You reach the feature through Exposure management, then Recommendations, then Devices, then Misconfigurations. From there you can drill into individual exposed devices, see which services and ports make them reachable, and track how exposure posture trends over time. Coverage is currently limited to onboarded Windows clients and Windows Server, specifically Windows 10 version 1607 and earlier, Windows 10 version 1809 and later, and Windows 11.

One caveat Microsoft calls out directly: the recommendation and the Internet-facing filter in device inventory can disagree temporarily. They refresh on different schedules, so a freshly remediated device might still show as exposed in one view until the assessment window catches up. For real-time device checks, the inventory filter remains the authoritative source.

Provider comparison

External attack surface management has become a standard line item across the major cloud and security platforms, and Microsoft is entering a field where the alternatives take noticeably different approaches.

Microsoft Defender ties exposure detection to its endpoint agent. Because devices are already onboarded to Defender for Endpoint, the inbound-reachability signal is correlated with full device context: installed software, vulnerabilities, configuration state, and Secure Score. The strength here is enrichment. You don't just learn a host is exposed, you learn what's running on it and how risky that combination is. The constraint is equally clear: the assessment only covers managed Windows endpoints. Unmanaged assets, appliances, IoT, and non-Windows servers fall outside this particular recommendation, though Defender's broader External Attack Surface Management product addresses internet-wide discovery separately.

AWS approaches the same goal through configuration analysis rather than endpoint agents. Services like Security Hub, GuardDuty, and the Network Access Analyzer reason about exposure from the infrastructure layer, security groups, network ACLs, and route tables, to determine whether a resource is reachable. This is powerful for cloud-native workloads where the network definition is the source of truth, but it is less helpful for understanding a managed endpoint's posture from the inside out.

Google Cloud Security Command Center offers attack path simulation through its Attack Exposure scoring, modeling how an external attacker could chain reachable resources toward high-value assets. Google's emphasis on attack-path reasoning is arguably ahead on prioritization logic, but it is anchored to GCP resources rather than fleet-wide endpoint telemetry.

The pricing models diverge in ways that affect strategy. Defender's exposure recommendation is included in Defender for Endpoint plans, so organizations already licensed pay nothing additional to surface these findings. AWS Security Hub and GuardDuty bill on a consumption basis tied to events and resources evaluated, which scales with environment size and can grow unpredictably in large accounts. Google's Security Command Center Premium and Enterprise tiers carry platform fees that make the attack-path features a deliberate budget decision. For a multi-cloud shop, the practical takeaway is that no single tool covers everything, and exposure data from each provider stays largely siloed in its own console.

Business impact

For security and infrastructure leaders, the value of this release is less about a new capability and more about reducing the operational cost of an existing one. Attack surface reduction programs tend to stall not because teams can't find exposed devices, but because they can't triage them fast enough to matter. An explicit acceptance state for intentional exposure is the kind of workflow detail that determines whether a program survives past its first quarter.

Microsoft frames the response as a five-step action plan: assess which devices are reachable and why, validate whether the exposure is actually required by confirming business need and ownership, prioritize high-risk assets like critical servers and sensitive environments, reduce unnecessary exposure by closing ports or moving services behind controlled access layers, and then monitor continuously so new exposure gets validated as the environment changes. None of these steps is novel on its own. The contribution is packaging them around a single prioritized data source so the work becomes repeatable.

The corporate-laptop scenario in Microsoft's FAQ deserves attention from anyone running a distributed workforce. Normal web browsing generates outbound traffic and won't flag a device. But a laptop that is directly reachable from the internet shows up as internet-facing, and that almost always signals a misconfiguration: a misapplied firewall policy, a device on a flat network, or a remote-access setup gone wrong. For organizations with employees working from home networks of unknown quality, this turns an abstract policy concern into a concrete, enumerable list of machines to fix.

The strategic limitation to plan around is scope. Because this recommendation only sees managed Windows devices, it should be treated as one input into a broader exposure picture, not the whole map. Teams running mixed estates will still need cloud-provider attack surface tools for their infrastructure and a dedicated external attack surface management capability for unmanaged and internet-discovered assets. The right posture is to use Defender's recommendation for the managed Windows fleet where its endpoint context adds real depth, and to keep the cloud-native tooling for everything that lives outside the agent's reach.

For organizations already invested in the Microsoft security stack, there is little reason not to enable the recommendation and work the action plan. The marginal cost is analyst time, the data is already being collected, and the output maps cleanly to Secure Score for Devices, giving leadership a measurable way to demonstrate that attack surface is shrinking rather than quietly expanding. Additional guidance on investigating internet-facing devices is available through Microsoft's Defender for Endpoint documentation and the Microsoft Security blog.