Microsoft is right about one narrow point in the latest Windows 11 privacy dispute: the Global Device Identifier, or GDID, is not a newly deployed tracking service. But the denial leaves untouched the reason the issue exploded in the first place: a federal court filing shows Microsoft has long maintained a persistent identifier for individual Windows installations and can correlate activity recorded under it across certain Microsoft services.

TechPowerUp reported on August 3 that Microsoft rejected claims of a newly added Windows tracking mechanism. The primary record supports that correction. In a July 2026 superseding criminal complaint against alleged Scattered Spider participant Peter Stokes, the U.S. Department of Justice documented Microsoft’s description of GDID as a persistent, device-level identifier for a Windows installation on a physical PC or virtual machine. The filing concerns activity alleged to have occurred in May 2025—more than a year before this week’s argument.

That means “new service” is the wrong diagnosis. It does not mean the public concern is baseless. Microsoft’s response appears to rebut a claim about when the identifier was introduced, while leaving major questions about its assignment, transmission, retention, service coverage, and consumer controls unanswered.

Cybersecurity network links homes, laptops, VPNs, cloud servers, and legal documents in a digital illustration.The court filing establishes that GDID existed before the controversy​

The Stokes complaint provides the clearest public description yet of what Microsoft calls a Global Device Identifier. According to a Microsoft representative quoted in the filing, the GDID uniquely identifies a Windows installation across “certain Microsoft services and scenarios.” It remains the same through normal Windows updates, but a Windows reinstall receives a new identifier—even if performed on the same hardware.

That lifecycle matters. GDID is not proven to be an immutable motherboard serial number, a TPM identifier, or a deterministic hardware hash. A clean Windows installation producing a new value points instead to an installation identity: a durable identity associated with the operating-system instance that Microsoft services can recognize over time.

In the case described by prosecutors, Microsoft records associated one GDID with an ngrok account registration made through a VPN-proxy IP address. Investigators then used the same identifier alongside timestamps, IP records, account activity, travel evidence, and other provider data to build their attribution case. The GDID did not identify a person by itself; it became useful because it linked events that would otherwise have been split across IP addresses and networks.

That is a more precise—and more consequential—description than saying Windows “tracks every keystroke” or that a new spyware service suddenly appeared. A stable identifier does not need to collect content on its own to become powerful. It gives Microsoft a way to join records produced by other services and diagnostic systems.

Microsoft’s own documentation confirms the identifier, but barely explains it​

Microsoft Learn documentation for Windows Update for Business reporting includes a

GlobalDeviceId

field in the Delivery Optimization status schema. Microsoft describes it in one sentence: a global device identifier used internally by Microsoft.

That documentation is significant for two reasons. First, it independently confirms that the term is real and not an invention of the criminal complaint. Second, it shows why users were caught off guard: the public-facing explanation is exceptionally thin for an identifier that, by Microsoft’s own description to federal investigators, can persist across Windows updates and be used across multiple services.

Microsoft has detailed privacy controls for advertising IDs, location access, app permissions, diagnostic-data levels, tailored experiences, and account-connected features. GDID has no comparable consumer-facing setting. There is no documented toggle labeled “Global Device Identifier,” no published dashboard explaining which Windows and Microsoft services receive it, and no ordinary control for rotating it without reinstalling Windows.

The missing information is not a semantic complaint. Administrators need to know whether an identifier is generated on devices using local accounts, Microsoft accounts, Entra ID, domain join, Microsoft Store access, Delivery Optimization, Xbox services, or any combination of those conditions. They also need to know whether it is transmitted with required diagnostics, optional diagnostics, service-specific traffic, or only under particular connected experiences.

Microsoft has not publicly answered those questions in the material available so far. Calling the system old does not fill in those blanks.


“Manual feedback only” is contradicted by Windows diagnostic documentation​

Some discussion surrounding the TechPowerUp report has framed the disputed activity as feedback data that is uploaded only when a user manually files a report. Microsoft’s own privacy documentation does not support such a broad claim.

Windows sends Required diagnostic data automatically to keep the operating system secure, updated, reliable, and functioning as expected. Microsoft says this data is stored alongside one or more unique identifiers that help it recognize a user on an individual device and understand service issues and usage patterns. Required diagnostics are distinct from the Feedback Hub workflow, which is user initiated.

Optional diagnostic data expands the scope. Microsoft says it can include more detailed device health information, application usage, enhanced error reporting, and—in relevant circumstances—websites a user browses. The company’s Edge policy documentation is even more specific: when Edge optional diagnostics are enabled, visited URLs and per-page usage can be reported to Microsoft. Administrators can disable that URL-reporting policy, but it applies only when optional browser diagnostics are in use.

The Stokes filing does not disclose the exact Windows component or telemetry pathway that provided the browsing records cited by investigators. Tom’s Hardware likewise noted that the complaint does not identify the specific collection mechanism. It would be wrong to claim the filing proves every Windows 11 machine routinely uploads every URL a user visits.

But it is equally wrong to claim that Windows data leaves the machine only after a user manually opens Feedback Hub and submits a report. Microsoft documents automatic diagnostic collection, recognizes that diagnostic events carry device identifiers and correlation values, and documents optional browsing-related collection under defined conditions.

A VPN changes network attribution, not Microsoft’s view of a device​

The practical lesson from the court record is not that a VPN is useless. A VPN can still conceal a user’s public IP address from websites and network observers, subject to its own privacy and logging practices. It does not promise anonymity from services where the user signs in, uses a persistent identifier, or voluntarily sends application telemetry.

A persistent Windows installation identity can make a sequence of otherwise separate events easier to associate inside Microsoft’s systems. If the same GDID appears when a device uses a home connection, a hotel network, a VPN endpoint, a Microsoft account, a service login, or optional browser diagnostics, Microsoft may be able to relate those records. Law enforcement access is a separate legal process, but the technical correlation happens because the platform maintains continuity.

For enterprise IT, this is familiar territory. Device identifiers are useful for update compliance, anti-fraud controls, software entitlements, security investigations, Intune administration, and account protection. The operational value is real. A managed fleet cannot be serviced reliably if every client becomes anonymous after an update or a network change.

The consumer privacy issue is that a device-management identifier can also function as a correlation key outside the administrator’s view. Microsoft’s public material has concentrated on the usefulness of diagnostic data and connected experiences while offering very little explanation of the particular identity layer that makes cross-service correlation possible.

What Windows 11 users and administrators can actually control​

There is no supported, documented GDID switch in Windows 11 Privacy & security settings. Removing random services, registry values, or identity files based on scripts circulating online is a poor substitute for a vendor-supported control; it can break Microsoft Store, account sign-in, Xbox, sync, update delivery, or other connected features without establishing what data has stopped flowing.

The controls that do exist are narrower but meaningful:

  • Set Windows diagnostic data to Required rather than Optional where policy and product requirements allow it.
  • Review Microsoft Edge diagnostic settings and, in managed environments, use the UrlDiagnosticDataEnabled policy to disable URL reporting in optional Edge diagnostics.
  • Turn off optional connected experiences that a device or organization does not need, recognizing that this does not disable all required service data.
  • Use Diagnostic Data Viewer to inspect the diagnostic events Windows makes visible locally, while recognizing that it is not a complete inventory of every Microsoft service interaction.
  • Treat a VPN as network privacy tooling, not as a mechanism that prevents Microsoft-connected software from recognizing a signed-in or persistently identified Windows installation.

The direct corrective point is straightforward: there is no evidence in the public record that Microsoft slipped a brand-new Windows 11 tracking service into current builds. The federal complaint shows the opposite—the GDID was already in use by May 2025.

Microsoft’s larger problem is transparency. It has now been publicly established that Windows installations have a durable global identifier that can bridge Microsoft records across services, yet the company still has not published the plain-language technical documentation, retention details, service map, and user controls that such an identifier warrants.


Update: Microsoft says the disputed 15-minute service keeps performance data local (August 4, 2026)​

According to PCWorld, Microsoft deputy technical director Scott Hanselman has now identified the service behind the viral claim that Windows 11 “spies” on users every 15 minutes. He said it belongs to the Windows diagnostic system and records local performance information, such as when Windows detects that a PC is running slowly.

Hanselman reportedly said that this particular data remains on the device unless a user chooses to send it to Microsoft. That clarification narrows the immediate claim: the recurring service is not, by itself, evidence that Windows is continuously transmitting its locally collected performance records.

Microsoft also acknowledged that the service’s current Windows description is unclear and said it will be revised. That is a meaningful concession for users and administrators trying to distinguish locally retained diagnostic logging from telemetry that is actually uploaded.

The statement does not, on its own, answer the separate GDID questions raised above—particularly which services receive that persistent installation identifier, what records can be correlated under it, and how long those records are retained.


Update: Report says the service is newly reaching release builds after earlier preview testing (August 4, 2026)​

TechRadar reports that, while the Windows Health and Optimized Experiences service itself dates to Canary-channel testing in May 2025, it appears to be only now reaching mainstream Windows 11 release builds.

That distinction partly explains why users encountered the process as though it were new. It does not change Scott Hanselman’s clarification that its targeted performance traces are stored locally and can be submitted through Feedback Hub, rather than being automatically sent to Microsoft every 15 minutes.

The report also associates the component with Adaptive Energy Saver work, though Microsoft has not yet published a clear release-channel rollout history or a detailed technical description of the service. For administrators, the practical takeaway remains the same: its arrival on production systems should not be equated with evidence of a newly deployed telemetry-upload mechanism, but Microsoft still needs to document its scope and behavior plainly.


Update: Windscribe releases deGDID script that blocks new Windows identifier registration (August 6, 2026)​

According to Tom’s Hardware, VPN provider Windscribe has released an open-source PowerShell project called deGDID that attempts to remove locally cached GDID values and stop Windows from obtaining replacements.

The tool reportedly deletes registry-cached identifiers, changes registry permissions to prevent them being recreated, and blocks Microsoft’s internal DeviceAdd endpoint. Windscribe says the protection mode is intended for unmanaged PCs with administrator access; it refuses to run on organization-managed or domain-joined devices.

Tom’s Hardware tested the script and reported that cached identifiers were removed and did not reappear after a restart, but Microsoft account verification and some Microsoft-connected applications returned connection errors. The tradeoff is significant: blocking the registration path can impair account and cloud-service functionality, rather than providing a clean, supported privacy setting.

The project does not erase identifiers Microsoft may already hold server-side, and it is not evidence that every GDID pathway has been eliminated. It does, however, underscore the unresolved issue for Windows users: Microsoft still offers no documented native control to rotate or disable this persistent installation identifier without disrupting connected services.


References​

  1. Primary source: TechPowerUp
    Published: August 3, 2026 at 4:22 PM UTC
  2. Related coverage: learn.microsoft.com
  3. Related coverage: learn.microsoft.com
  4. Related coverage: support.microsoft.com
  5. Related coverage: pcworld.com
  6. Related coverage: community.bitdefender.com
  7. Related coverage: support.mozilla.org
  8. Related coverage: windowsreport.com
  9. Related coverage: support.microsoft.com
  10. Related coverage: keelcrux.com
  11. Related coverage: windowsforum.com
  12. Related coverage: zerotracelab.com
  13. Related coverage: pchardwarepro.com
  14. Related coverage: neowin.net
  15. Related coverage: xela.au
  16. Related coverage: modemguides.com
  17. Related coverage: cipheryou.com
  18. Related coverage: cdn-dynmedia-1.microsoft.com
  19. Related coverage: cdn-dynmedia-1.microsoft.com
  20. Related coverage: tomshardware.com
  21. Related coverage: tomshardware.com
  22. Related coverage: pcgamer.com
  23. Related coverage: bleepingcomputer.com
  24. Related coverage: techradar.com
  25. Related coverage: azure.status.microsoft
  26. Related coverage: bleepingcomputer.com
  27. Related coverage: windowscentral.com
  28. Related coverage: thehackernews.com
  29. Related coverage: appliedantitrust.com
  30. Related coverage: appliedantitrust.com
  31. Related coverage: techcommunity.microsoft.com
  32. Related coverage: learn-attachment.microsoft.com
  33. Primary source: PCWorld
    Published: August 4, 2026 at 3:59 PM UTC
  34. Primary source: TechRadar
    Published: August 4, 2026 at 4:40 PM UTC
  35. Primary source: Tom's Hardware
    Published: August 6, 2026 at 10:30 AM UTC