A free, open-source tool now lets Windows users erase one of the most persistent identifiers baked into the operating system. Windscribe has published deGDID, a PowerShell utility that removes Microsoft's Global Device Identifier from the registry and stops Windows from issuing a fresh one.
The context matters: the GDID reportedly surfaced in a federal case where authorities used it to locate an alleged hacker, underscoring how thoroughly the identifier tracks hardware beneath the network layer where VPNs operate.
The utility is script-driven and comes with trade-offs. Some Microsoft account flows stop working once it runs, and identifiers Microsoft has already collected remain on its servers.
- DeGDID is open source and requires administrator-level PowerShell to execute.
- Four flags are available: -Status checks whether a GDID is active, -Status -Redact hides the identifier in diagnostic logs, -Protect performs the core removal, and -Unprotect reverses the process.
- The script is restricted to unmanaged, non-domain-joined machines.
How the script reaches into Windows
GDID operates below the network stack where typical VPNs live. A VPN masks an IP address. It does nothing about a fingerprint Microsoft uses to recognise the same hardware across reboots and logins.
DeGDID closes that gap. It locates cached entries, deletes them, locks the registry keys so Windows cannot recreate them, and pushes a firewall rule against the internal DeviceAdd endpoint used by Microsoft identity services. Testing on a Windows 11 host confirmed the entries stayed gone after a restart, and no new GDID appeared even after rebooting. Online games and other software kept running normally throughout testing.
Why it matters: a meaningful fix with real limits
The script delivers what it claims. The cost is real and shows up in everyday sign-ins. After running -Protect, account verification through login.live.com failed in every browser tested. Workstation sign-ins through login.microsoftonline.com continued working. A handful of Microsoft apps returned connection errors.
Windscribe is candid about the ceiling. Identifiers already cached on Microsoft's infrastructure stay on Microsoft's infrastructure—there is no API or registry trick to wipe them. So deGDID closes the door going forward; it does not unsee the past.
Who wins:** Privacy-conscious users, security researchers and power users who want to limit hardware fingerprinting. Admin workstations handling sensitive operations benefit most since they typically don't rely on consumer Microsoft account flows.
Who loses:** Users dependent on full login.live.com verification or Microsoft apps that rely on device registration. The script explicitly refuses to run on managed or domain-joined hosts, which signals its intent: a power-user tool for unmanaged machines, not a fleet deployment.
What to watch:** Microsoft may change how or where GDID is stored, forcing Windscribe to update the script. Watch for similar community projects targeting other persistent Windows identifiers. The tool will likely evolve as researchers learn more about the identifier's inner workings.
Users should remember that this addresses tracking, not malware—antivirus and endpoint protection remain essential regardless of whether the script runs.
Key takeaways
- DeGDID removes cached GDID keys from the Windows registry and blocks Windows from reissuing them.
- Some Microsoft account sign-in flows, particularly login.live.com, stop working after it runs.
- Server-side data Microsoft already holds cannot be erased by the script.
- Use it on unmanaged admin workstations; it refuses to run on domain-joined systems.
- Keep antivirus active—deGDID handles tracking, not malicious software.
Frequently asked questions
What is deGDID?
An open-source PowerShell script from Windscribe that strips Microsoft's Global Device Identifier from Windows hosts and prevents reissuance.
Which Microsoft services stop working after the script runs?
Account verification through login.live.com fails across browsers, and a few Microsoft apps surface connection errors. Login.microsoftonline.com and most other software continue functioning normally.
Can Microsoft still keep the data it already collected?
Yes. Windscribe acknowledges that server-side records remain outside the script's reach, so historical data stays with Microsoft indefinitely.
Does deGDID work on corporate or domain-joined systems?
No. The script deliberately refuses to execute on managed or domain-joined hosts.
Can the changes be undone?
Yes. Running -Unprotect reverses the registry and firewall changes and restores default settings.