Install a per-application firewall on a machine that has already been through the full hardening routine — debloat script applied, privacy panel emptied, Group Policy tightened where the edition allows, a Pi-hole filtering the network — then leave it idle and read the log. Denied connections accumulate anyway. Some are identifiable. Many, however, are processes hosted inside svchost.exe, reaching destinations that resolve to shared Microsoft infrastructure, for purposes no public document explains.
That log describes the real Windows 11 privacy problem, and it reaches well beyond telemetry. Diagnostic data is merely the portion of the operating system’s network behavior that Microsoft documents and governs with a policy. Everything else — connectivity checks, licensing calls, content delivery, component servicing, whatever a service host does at three in the morning — has no published manifest. Consequently, nobody outside Redmond can produce a complete list of what a Windows 11 system connects to and on whose behalf, because the code making those decisions stays unreadable and the behavior is not contractually fixed.
This matters because every mainstream Windows 11 privacy tool assumes that list exists. A blocklist has to know what to block. Therefore the useful question is not which settings to change, but whether the enumeration those settings depend on can be obtained at all.
What Windows 11 Privacy Settings Can Prove
Begin with the documented minority, since it is checkable and it establishes the pattern governing everything else.
The AllowTelemetry floor
Windows exposes four diagnostic data levels through the AllowTelemetry value under HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection. Only Enterprise, Education, Server and certain IoT editions support the lowest — currently “Diagnostic data off,” historically Security. Set it on Home or Pro and Windows raises no error. Instead, it silently treats the value as 1, Required.
That single behavior explains why a correctly executed tool reports success on a machine that keeps transmitting. The tool applied the policy. The floor did not move.
0123WN11-CC-000205Level 0 delivers no silence either. The US Defense Information Systems Agency addresses this in its Windows 11 Security Technical Implementation Guide, specifically WN11-CC-000205 (vulnerability ID V-253393), which describes the Security option as configuring the lowest volume of data — effectively none beyond the Malicious Software Removal Tool, Defender, and the telemetry client’s own settings. That qualifier carries the meaning. Although DISA governs Department of Defense endpoints, its benchmark flags only Full as an actual finding and accepts Security or Basic as compliant.
Why the Diagnostic Data Viewer is not evidence
Microsoft ships a Diagnostic Data Viewer, and defenders of Windows 11 privacy settings reasonably point to it. The tool displays telemetry payloads on a local machine, which genuinely helps anyone trying to understand the shape of diagnostic data.
Nevertheless, it proves less than it appears to. The Viewer shows what the telemetry client reports it is submitting, rendered by the very component under examination. On a closed-source system that constitutes a self-report rather than an observation. The distinction governs everything that follows: a statement from software about its own behavior is not the same class of evidence as a record of packets captured beneath it.
The Channels Nobody Documents
Diagnostic data occupies one network path among many, and it is the only one with a coherent public control surface. Start menu web search, Widgets, Edge, OneDrive, the Microsoft Store, Delivery Optimization, connectivity status checks, activation and licensing validation, component servicing and Defender’s cloud-delivered protection each maintain independent paths under independent controls — where controls exist at all.
Microsoft publishes categories of collected data rather than a connection manifest. In other words, no document maps every outbound connection to the service responsible, the payload carried, and the retention applied. This is not an accusation of concealment; rather, it follows from shipping a closed-source operating system of this size. Either way the consequence holds: the set of connections that occur remains externally unknowable.
Two properties compound the opacity. First, behavior shifts over time, because feature updates introduce components that did not exist when any given analysis ran, while cumulative updates can restore functionality somebody removed. Second, many Windows services share svchost.exe host processes, so “which service opened this connection” is a question the operating system does not answer plainly without tooling built for the purpose.
Why Windows 11 Privacy Tools Can’t Close the Gap
The conventional toolkit rests on an assumption that none of the above supports: that the set of things to block can be known. Each tool is worth running for what it genuinely does. None of them crosses that boundary.
1.0. No consumer features or suggestions.Win11Debloat deserves particular credit here, because it represents the strongest version of the conventional approach. Raphire’s PowerShell script carries 56,200 GitHub stars, ships under an MIT license, and applies in under two minutes a change set that would otherwise consume an afternoon. Moreover, it documents reversal for every change and includes a Sysprep mode so new profiles inherit the configuration. Running it remains worthwhile.
Nonetheless, it addresses the components its maintainers have identified — which is not a defect but a boundary, and the same boundary constrains every Windows 11 privacy tool built on policies and rule lists. Each blocklist is a record of connections somebody happened to observe, presented as though it were the set of connections that occur. On an auditable system those two things could converge. On a closed-source one they cannot, by construction.
That is why better tooling cannot fix it. The missing input is not effort but knowledge that does not exist outside Microsoft.
The Question Default-Deny Removes
One approach escapes the trap, and it does so by refusing to play. A default-deny configuration lists the applications permitted to reach the network and denies everything else, which makes the identity, purpose and novelty of any other component irrelevant. Unidentified becomes the default state, and unidentified does not get out.
The principle long predates the current debate. NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy (Scarfone and Hoffman, September 2009), recommends blocking all inbound and outbound traffic not expressly permitted, with exceptions added for required traffic. Its stated rationale: because hosts, networks, protocols and applications change continuously, deny-by-default is more secure than permitting whatever nobody has forbidden yet. That describes the opacity problem in the abstract, twelve years before Windows 11 shipped.
Applying it to a desktop requires a per-application firewall that observes traffic below the layer where evasion happens. Portmaster, from the Austrian firm Safing, is the practical implementation: open source, filtering at packet level through a Windows Filtering Platform kernel driver, and attributing every connection to its originating process. The full configuration — offline installation, allowlist construction, DNS lockdown, and the honest limits of the model — is covered in how to configure a Portmaster firewall in default-deny mode.
The claim worth making about it is narrow and defensible. It is not that default-deny blocks more than a well-maintained blocklist; on a carefully tended system the overlap is large. Crucially, it is that default-deny never needs to know what it blocks — the one requirement a closed-source operating system makes impossible to satisfy.
FAQ
What do Windows 11 privacy settings actually control?
They govern the documented diagnostic channel plus individual feature toggles. On Home and Pro the diagnostic floor sits at Required regardless of what any tool reports, and they do not govern activation, licensing or servicing traffic at all.
What data does Windows 11 collect?
Microsoft publishes the categories, and the Diagnostic Data Viewer displays telemetry payloads locally. Both describe the documented diagnostic channel, as reported by the component responsible for it. Neither constitutes an inventory of what the system connects to, and no such public inventory exists.
Does Windows 11 spy on you?
That framing assumes intent nobody outside Microsoft can establish. What anyone can establish is narrower and still significant: the machine opens connections that no public document accounts for individually, and the user has no means of auditing what they carry.
What Can Actually Be Claimed
Closed source means the question of what Windows connects to, and why, stays permanently open. No configuration changes that, and any article promising otherwise is selling something.
What changes is whether the question has to be answered. A blocklist needs the answer and cannot get it. An allowlist does not, because a connection either originates from something explicitly permitted or it never completes — and the identity of the unpermitted remainder never has to be resolved.
The code stays closed. The connections do not. That is a smaller claim than most Windows 11 privacy advice makes, and it is one of the few that survives contact with a closed-source operating system.
