Microsoft Just Admitted Windows Has a Tracking ID You Can't Turn Off
Telemetry has been the quiet background hum of the Windows conversation for years — the kind of topic that flares up around a big feature update and then fades. This month it stopped being background noise. A federal criminal complaint forced Microsoft to publicly confirm, for the first time, the existence of a persistent per-device identifier that survives Windows updates, that you can't view through any standard interface, and that — unlike almost everything else in the Privacy settings — has no off switch at all.
How a hacker's VPN stopped mattering
The identifier is called the GDID, short for Global Device Identifier, and it surfaced publicly because of how the FBI caught Peter Stokes, a 19-year-old alleged member of the Scattered Spider hacking group, over a 2025 ransomware attack against a US jewelry retailer. Stokes reportedly ran his operation behind VPNs, proxies, and infrastructure spread across multiple countries — the standard playbook for staying untraceable. None of it mattered, because his Windows PC was quietly reporting a persistent identifier back to Microsoft the entire time, regardless of which IP address or exit node was in front of it.
The unsealed 39-page complaint quotes a Microsoft representative describing GDID as a persistent, device-level identifier designed to uniquely identify a Windows installation across certain Microsoft services and scenarios — physical device or VM, doesn't matter. Once a court order compelled Microsoft to hand over records tied to that identifier, investigators got web activity timestamps, IP history, and infrastructure connections that stitched Stokes' VPN-shielded sessions back into a single, identifiable trail — including something as specific as the exact moment he signed up for an ngrok account.
What GDID actually is, technically
Outside this case, Microsoft has documented GDID exactly once, in the Azure Monitor reference for Delivery Optimization reporting, where a column called GlobalDeviceId gets one sentence: "an identifier used by Microsoft internally." Everything else about how it works came from independent reverse engineering after the complaint went public.
The chain starts the moment you sign into Windows with a Microsoft Account. A system service called wlidsvc talks to login.live.com and gets back a Device PUID — Passport Unique ID — a 64-bit value assigned server-side, not derived from any hardware fingerprint. It lands in your registry at HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties, formatted as g:<decimal>, and from there the Connected Devices Platform (cdp.dll) is what actually registers and propagates it across Microsoft's services. It survives feature updates and version upgrades. It does not survive a clean reinstall — but if you sign back into the same Microsoft Account afterward, Microsoft has every reason to link the new GDID right back to your old activity anyway, so a reinstall buys you less than it sounds like.
The part that should bother developers specifically
Here's the detail that's genuinely different from every other telemetry knob in Windows: there's no consumer-facing setting, policy, or registry flag that turns GDID generation off. Disabling it isn't offered because it's structurally tied to Windows activation and Microsoft Store functionality — killing it breaks things Microsoft doesn't consider optional. The only lever anyone's found is preventing the device from ever reaching login.live.com in the first place — network-level blocking, not a setting — and that's a fragile, all-or-nothing move that breaks plenty of legitimate functionality along with it.
Compare that to literally every other privacy-relevant identifier Windows exposes: the advertising ID, diagnostic data level, activity history, tailored experiences, Recall — all of them are toggleable through Settings or Group Policy, however deeply Microsoft buries the switch. GDID is the one identifier in the whole stack that was never designed with a toggle in mind, and the reason we know that now is a federal court filing, not a Microsoft disclosure.
What you actually can still control
Since GDID itself is off the table, the practical response most security writers have converged on is tightening everything around it: use a local account where setup still allows it, set diagnostic data to Required-only, kill the advertising ID and personalized-ads toggles, and turn off Activity History and Cloud Content Search so less gets tied to whatever identifier is already there.
I ended up automating exactly that second category — the telemetry surface that is actually toggleable — as part of a Windows cleanup tool I put together and pushed to GitHub today. It's aimed at the broader problem of AppX bloat and undocumented uninstalls (full package scanning, dependency-aware removal, a proper System Restore checkpoint via the native SRSetRestorePoint API before it touches anything), but the telemetry piece specifically flips the Advertising ID off, kills the Windows feedback pop-ups via the Siuf\Rules key, and disables CEIP through SQMClient\Windows — the three levers that are still actually yours to control, done in one pass instead of hunting through Settings submenus. It also has a local file-reputation check against VirusTotal's v3 API before you remove anything you're unsure about, with the API key kept encrypted at rest via DPAPI rather than sitting in plaintext next to the binary. Link's on my GitHub if anyone wants to poke at it — WinPurge-Windows 11 Component Cleaner.
The bigger picture
GDID isn't unique in concept — Apple has a hardware UUID and a DSID, Linux has a machine-id, every major platform maintains some notion of persistent device identity for licensing and abuse prevention. What's unusual is the combination Windows landed on: an identifier with real forensic power, presented with zero documentation, zero user visibility, and zero opt-out, discovered by the public only because it showed up as evidence in a criminal case. It caught a genuinely bad actor this time. The uncomfortable part is that the exact same properties — persistent, cross-VPN, tied to a real identity the moment you sign into an MSA — apply to all 1.6 billion Windows installs, not just the ones running ransomware operations.
Do you run local accounts on your dev machines, or has Microsoft made that enough of a hassle that most people just don't bother anymore?
Top comments (0)