Windows has obvious identifiers, like your computer name, and less obvious ones buried in Microsoft's identity systems. One of the more interesting ones is the Global Device Identifier, or GDID: a Microsoft-issued identifier tied to a Windows installation.
GDID is not new, but it recently got dragged into public view in the superseding complaint against Peter Stokes, a 19-year-old alleged member of the Scattered Spider hacking group. According to the filing which was unsealed on July 1st, Microsoft gave investigators logs that correlated a Windows GDID with IP activity. In the past you could guess something like this was happening behind the scenes, but now we have it confirmed in a sworn federal affidavit: a stable identifier inside a giant cloud ecosystem that can connect more dots than most people realize.
What is GDID?
Microsoft publicly documents GlobalDeviceId in the UCDOStatus table for Windows Update for Business and Delivery Optimization reporting, defining it as a device identifier generated by Microsoft and used internally. That confirms the ID exists but it does not explain much to normal Windows users like your grandma.
GDID is not the same as your advertising ID, Microsoft account user ID, or a simple motherboard serial number. Our research suggests the server-issued ID is minted through Windows identity and account-registration flows, with hardware signals involved in the request. Hardware alone does not determine it, though. Reinstall Windows and the machine gets a brand new GDID, so the ID cannot simply be derived from your serial numbers.
Why it matters
Stable identifiers are not automatically evil. Operating systems use device identity for updates, fraud prevention, licensing, sync, account security, abuse response, and diagnostics. Microsoft also documents extensive optional diagnostic data in Windows.
The privacy issue starts when a durable Windows installation ID can be associated with IP addresses, account activity, SmartScreen or browser events, update delivery data, and other telemetry. The Stokes complaint shows how far that association reaches. Microsoft records tied the GDID to the creation of an ngrok account at the exact minute the intrusion began, and to the same IP addresses used by personal accounts prosecutors say belong to Stokes, sometimes within hours of each other. That covers signups on third-party services, and investigators got all of it with a legal request.
Worth spelling out, since we sell one: the VPN in this case did not fail. The GDID never saw through the tunnel. It sat outside it, at the layer where Windows talks to Microsoft's cloud, and it tied every session together no matter which IP the traffic came from. One connection with the VPN off, or one personal account signed in on the same machine, and the whole chain links back to you.
To be clear, we are not claiming GDID is sent to every website you visit. The public case does not identify the exact Windows component or event that produced the logs. The careful claim is narrower: GDID can exist on your machine, Microsoft can associate it with activity, and local privacy advice often ignores it.
Local accounts are not enough
A lot of people assume identifiers like this only appear if you sign into Windows with a Microsoft account. Our lab work says otherwise.
In one experiment, a local-account virtual machine that had never minted a GDID stayed clean while the registration path was blocked. When the block was removed, a real GDID appeared shortly afterward, carrying the same 0018... prefix you see when you convert the identifier from the Stokes complaint into hex. Blocking it again stopped the re-mint.
"Just use a local account" is a common Windows privacy tip, and it still cuts down on account-linked exposure, but our testing shows it is not a GDID shield. The likely mint path is Microsoft Passport or Microsoft Account DeviceAdd, especially login.live.com/ppsecure/deviceaddcredential.srf, with Windows identity components handling the request.
Why one registry delete is not enough
If there is an ID in the registry, the tempting fix is to delete the obvious value and move on. We tried that. It wasn't enough.
Our early wipe removed the obvious value, a registry entry called the LID. After a reboot, a related account-level identifier called the user PUID came back even while login.live.com stayed blocked. That PUID is a separate identifier from the device-level GDID, and its reappearance shows how much identity state Windows keeps in reserve. We found related state across IdentityCRL locations, token fields, device tickets, Credential Manager entries, SYSTEM and .DEFAULT hives, and user profile caches like ConnectedDevicesPlatform and TokenBroker.
Translation: this goes beyond a simple registry key. It is an entire lifecycle in the operating system. If Windows can rebuild identity continuity from another local source, all those shallow "debloat" scripts do not actually break continuity.
What we built: deGDID
Our deGDID project is research plus a practical PowerShell tool, degdid.ps1. Its goal is deliberately narrow - remove known local real GDID state on supported unmanaged Windows systems, then keep the Microsoft DeviceAdd path blocked so Windows cannot immediately mint or retrieve a replacement.
We didn't set out to make a generic "stop all Windows telemetry" button here. It does not erase Microsoft's historical server-side records, does not make a managed corporate machine safe to mutate, and does not prove every possible GDID copy is gone forever. It is a targeted GDID mitigation: continuity breaker plus mint blocker.
Use .\degdid.ps1 -Status for read-only inspection, .\degdid.ps1 -Status -Redact before sharing output, and .\degdid.ps1 -Protect for the normal protection flow: block first, verify the block, wipe known local state, wait, re-inventory, then report a verdict.
What protection does
At a high level, deGDID does two things:
- Blocks known Microsoft registration paths by managing a region in the Windows hosts file, plus reinforcing the block with Windows Firewall rules.
- Wipes known local GDID-related state across target-user,
SYSTEM, and.DEFAULTidentity locations, token device IDs, device tickets, Credential Manager entries,ConnectedDevicesPlatform,TokenBroker, WAM broker caches, and matching NegativeCache entries.
The tool is intentionally conservative. It refuses managed, domain-joined, Entra-joined, MDM-enrolled, or ambiguous multi-profile systems. It requires admin rights, it backs up what it touches, and it supports undo using .\degdid.ps1 -Unprotect.
The tradeoff
Blocking Microsoft identity and device graph paths can break or degrade Microsoft features like account sign-in flows, Microsoft Store, Xbox, OneDrive, device sync, passkeys, and Windows Hello sign-in tied to a Microsoft account. Replicating these blocks by hand on a managed corporate machine would also interfere with MDM enrollment, which is one of the reasons the tool refuses to run on those systems in the first place. Core desktop usage worked in the lab, and Windows Update scans plus Defender signature updates worked in partial testing, but this is not a zero-cost toggle.
That is why deGDID reports explicit verdicts. ProtectedNoRealGdid means the supported environment was readable, no real-shaped GDID was found in known local stores, and the registration path was blocked. Anything weaker should be treated as incomplete.
The bigger privacy lesson
GDID is one entry in a much longer list. Modern operating systems are full of identity systems most people never see: advertising IDs, account IDs, hardware hashes, service tokens, device registration records, telemetry clients, update clients, sync clients, app store clients, security reputation systems, and more.
GDID gives us a concrete example. It is named in Microsoft documentation. It appeared in a public legal filing. It has local artifacts researchers can inspect. It can be mitigated, but only by understanding how the surrounding system behaves.
Privacy shouldn't be left to magic debloater tools that say they'll move mountains. Privacy comes from understanding what the system is even doing in the first place. Mapping behavior, doing repeatable testing, seeing what failure modes exist, and understanding the tradeoffs that come from disabling these systems.
Windows may be on your computer, but it is also part of Microsoft's telemetry and identity ecosystem. GDID is one reminder that those two facts are not the same thing. If you want to inspect or reduce this specific identifier, start with deGDID. If you want an operating system that does not require this kind of archaeology in the first place, well, you know where the Linux download button lives.
Disclaimer: deGDID is a research experiment provided as is. Our research and testing may not have found every instance of the GDID system, and the tool may not block them all. It does not erase records Microsoft already has or make you anonymous. Running it can break Microsoft account features. Use it at your own risk, on systems you're authorized to modify. Neither Windscribe nor Yegor Sak is liable for any damage or loss that results.
