deGDID: removing Windows' server-assigned GDID and keeping DeviceAdd blocked

What deGDID removes, and who the script is actually for

GDID is Microsoft's Global Device Identifier, described in the README as a server-assigned installation identifier that Windows can acquire even when the interactive user has only a local account. That last clause is the whole point. A local account keeps you out of a Microsoft account, but it does not stop the machine from being minted a 64-bit Device PUID through Microsoft's DeviceAdd infrastructure, and that value can be retained across several local identity stores.

The repository documents the wider GDID lifecycle, but the shipped degdid.ps1 has a deliberately narrow objective: on a supported Windows target, remove real server-issued GDID state from the known local stores and keep the DeviceAdd path continuously blocked. The README calls this a completion gate and explicitly disclaims being a general telemetry, browser-privacy, or court-record-channel suppression tool. That distinction matters. If you want a general privacy tool, this is not it.

The intended user is narrow: an unmanaged personal Windows installation with one loaded human profile. Windows 10 22H2/build 19045 or Windows 11 build 22000 and newer are accepted, with no domain, Entra, workplace, or MDM enrollment, and an elevated 64-bit Windows PowerShell session. Windows 11 25H2/build 26200 is the fully lab-validated line; other accepted builds warn. Managed systems, ambiguous users, and multiple loaded human profiles are refused instead of guessed at.

How Protect works: network gate first, identity mutation second

The ordering is the design. Protect applies the network controls before it touches identity state, so a failure stops the run rather than leaving a half-protected machine. The README lists four steps: apply a dual-stack hosts block and check the actual DeviceAdd path; refresh firewall defence-in-depth where policy allows; clear known GDID copies and device-identity rehydrate sources from the target user, .DEFAULT, and SYSTEM; then wait, recheck the network gate, and refuse success if identity state returns.

That final recheck is what separates a claim from a gate. A wipe alone would report success the moment the registry keys were gone, even if Windows immediately minted a fresh PUID. Here the script waits and rechecks, and only the verdict ProtectedNoRealGdid counts as complete. Canonical protection uses Wipe; a Decoy mode exists for research but the README does not consider it a clean completion state.

Status is a separate read-only path. It can inspect unsupported systems, and it intentionally prints full local account, profile, PUID, and g:<decimal> values. That output is machine-identifying data. Treat a Status dump the way you would treat a credential, and note the repository's own warning against committing private machine GDIDs, device tickets, or unredacted Status JSON.

Installing deGDID and running a first Protect cycle

There is no package manager step. The repository ships degdid.ps1 at the top level alongside docs/, tests/, and tools/, so you clone or download it and run the script from an elevated PowerShell window. The README's quick start is three commands: check status, protect, check status again.

.\degdid.ps1 -Status
.\degdid.ps1 -Protect
.\degdid.ps1 -Status

Run them in that order. The first Status call tells you whether the environment is readable and what identity state currently exists; the README notes that Status can inspect unsupported systems, so a successful Status is not the same as an eligible target. Protect then applies the network gate, refreshes firewall rules where policy allows, and wipes the known stores. The second Status call is the one that matters: ProtectedNoRealGdid is the only complete result.

If you need to take the network controls back off, the README gives a single command.

.\degdid.ps1 -Unblock

Unblock allows Windows to mint a real GDID again. That is not a rollback of a mistake; it is the documented way to return the machine to normal minting behaviour, and the README's lab record includes an Unblock, an observed remint, a reprotect, and a clean reboot. Re-run Status after major Windows, firewall, security-product, or hosts-file changes, because any of those can reopen the path.

The compatibility cost is the headline limitation

The README is unusually direct about what breaks. Blocking login.live.com, account.live.com, DDS, and the wlidsvc service path is expected to break or degrade MSA sign-in, Store and Xbox authentication, OneDrive MSA sign-in, Phone Link, and CDP graph features. Those are not edge cases for a lot of people. If your daily workflow depends on a Microsoft account anywhere on that machine, this tool is the wrong choice, and the script's own documentation says so before you run it.

Core desktop access worked in the lab, and Windows Update scan, Defender update, and historical blocked-period installs were observed. But a controlled pending cumulative update and a feature update remain unvalidated. That is a real gap: the scenario most likely to disturb a hardened machine, a large servicing operation, has not been tested under controlled conditions according to the README.

The evidence is also bounded. The completed Windows 11 25H2/build-26200 lifecycle covers prevention before first network access, a natural mint followed by Protect, reboot and repeated identity triggers, more than 33 hours protected on the local-account lab VM, and an MSA-connected field run that stayed protected through sign-out and sign-in, sleep and resume, reboot, and 18 hours. Windows 10 and other Windows 11 builds are accepted with warnings, not equivalent lab claims. And the README concedes the larger unknown: court reporting in 2026 established that Microsoft held a GDID-to-URL/time/IP association in one investigation, but the public record does not identify the Windows component or network channel responsible, and this tool makes no claim to block that unknown channel.

deGDID versus a general Windows privacy-hardening script

The obvious alternative is a broad Windows privacy script, the kind that disables telemetry services, edits scheduled tasks, and applies a long list of registry tweaks in one pass. The difference in approach is scope and verification. A general hardening script changes many settings and reports which ones it applied; it does not know what a real GDID looks like, so it cannot tell you whether a real-shaped PUID still exists in the known inventory, and it has no reason to recheck the network path after the wipe.

deGDID inverts that. It does one thing, defines success as a specific verdict, and refuses targets it cannot reason about. The cost of that focus is everything outside GDID: browser privacy, advertising identifiers, and other telemetry surfaces are explicitly out of scope per the README. If you want broad coverage, a general script covers more ground. If you want to know whether the DeviceAdd path is actually closed on your machine, a general script does not answer that question at all.

A second alternative is doing nothing and relying on a local account. That is precisely the assumption the project exists to challenge: the README states a local Windows account does not prevent the machine-level mint.

Maintenance, licensing, and what changes on a Windows upgrade

The last push to the repository was on 2026-08-08, and the README carries a last-updated date of 2026-07-16. The project is not archived. Those two facts are the only maintenance signals available here; there is no release history in the repository, so there is no version line to track and no upgrade path to follow beyond pulling the current degdid.ps1 and re-reading docs/usage.md.

The practical maintenance cost is operational rather than dependency-driven. A PowerShell script with no package dependencies does not break because a library moved. It breaks because Windows changed. The README already treats build support as a graded thing: 25H2/build 26200 is lab-validated, other accepted builds warn, and Windows 10 is accepted with warnings rather than lab claims. A feature update is exactly the event that can invalidate the gate, and the README lists a controlled pending cumulative update and feature update as unvalidated. Re-run Status after major Windows, firewall, security-product, or hosts-file changes.

The licence is MIT. That permits use, modification, and redistribution with the copyright notice and permission notice retained, and it comes with no warranty. The README states the work is provided as-is and that you are responsible for changes made to your systems. The repository also carries an ethics section: use it for research, privacy hardening, and analysis of opaque device identity, not to evade lawful process. That is the project's stated intent, not a legal position, and nothing here is legal advice.

Editorial conclusion

Adopt deGDID only on an unmanaged personal Windows 10 22H2 or Windows 11 machine with a single loaded human profile and an elevated 64-bit PowerShell session, and only if you accept that MSA sign-in, Store, Xbox, OneDrive MSA and Phone Link are expected to break. Do not run it on domain, Entra, MDM or multi-profile systems: the script refuses those rather than guessing, and there is no lab evidence for them. Before you commit, verify your build against the accepted list, read docs/usage.md for exit codes and DryRun behaviour, and confirm you can tolerate the loss of identity workflows rather than discovering it after Protect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. yegors/deGDID on GitHub