deGDID blocks Microsoft account sign-in, and only claims one completion state

The shipped artifact is one PowerShell script, and tools/ is never described

The top level of the repository holds .gitignore, LICENSE, README.md, degdid.ps1, and three directories: docs/, tests/, and tools/.

So the operational tool is a single script. Everything else is documentation, test material, and a tools directory that the README never mentions. The read-more section points at docs/usage.md for commands, verdicts, exit codes, and recovery, docs/countermeasures.md for the exact gate, wipe scope, and residual risk, docs/architecture.md for the generation and lifecycle model, docs/surfaces.md for a registry, credential, service, and endpoint inventory, docs/experiments/ for the lab and field evidence, and docs/open-questions.md for what is still unknown.

tools/ appears in none of that. It may hold research helpers, it may hold the harness that produced the experiment records, and the README does not say.

There is also a date discrepancy worth a glance. The README's own header reads Last updated: 2026-07-16, while the last push to the repository is dated 2026-08-08. So the front page was last edited about three weeks before the last commit touched something.

One verdict string is success, and it does not mean history was erased

The quick start is three commands in an elevated PowerShell window, and the sequence is part of the contract:

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

The first call reads, the second changes, and the third confirms. The only complete result is ProtectedNoRealGdid.

What that string means is defined narrowly and worth reading as a contract. It means the supported environment was readable, no real-shaped PUID remained in the known inventory, and the DeviceAdd gate verified.

What it does not mean is stated in the same breath: it does not mean Microsoft deleted historical records, and it does not mean unrelated telemetry stopped.

That distinction is the whole character of the project. GDID itself is described as a server-assigned 64-bit Device PUID that Windows can mint through Microsoft's DeviceAdd infrastructure and retain across several local identity stores, and the tool's stated job is to remove real server-issued GDID state from the known local stores and keep the DeviceAdd path blocked. It is a completion gate for that goal, and the README explicitly refuses to present it as a general telemetry, browser-privacy, or court-record-channel suppression claim.

For anyone evaluating it, the useful question is therefore not whether it works but whether its narrow claim is the one they need.

The network gate goes up before any identity state is touched

Protect runs four steps in a fixed order. It applies a dual-stack hosts block and checks the actual DeviceAdd path. It refreshes firewall defense-in-depth where policy allows. It clears known GDID copies and device-identity rehydrate sources from the target user, from .DEFAULT, and from SYSTEM. And it waits, rechecks the network gate, and refuses success if identity state returns.

The ordering is the design. The network gate is applied before identity mutation, and if a required check fails the script stops instead of continuing with a partial protection state. So the failure mode is a machine that is unchanged rather than a machine that is half-cleared and still minting.

The last step is the one that closes the loop. After clearing, it waits and checks again, and it will not report success if identity state comes back. That is what makes the verdict string mean something beyond a snapshot of a directory.

One detail to know about before you see a failure: canonical protection uses Wipe. Decoy mode also exists for research, and the README says plainly that decoy mode is not a clean completion state. A run that ends in decoy mode has not produced the completion string.

One build is lab-validated, everything else warns, managed systems are refused

Eligibility is narrow and the tool enforces it rather than guessing. The target is an unmanaged personal Windows installation with one loaded human profile, running Windows 10 22H2 build 19045 or Windows 11 build 22000 or newer, with no domain, Entra, workplace, or MDM enrollment, driven from 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 being handled speculatively, and the compatibility section repeats that domain, Entra, MDM, and multiple-loaded-profile systems are refused rather than assigned speculative compatibility claims.

The distinction between refuse and warn matters more than it sounds. A refusal means the script will not act on a machine whose identity model it cannot read confidently. A warning means it will act on a supported build whose behaviour was not validated to the same depth.

Status is the exception. It can still inspect unsupported systems, so you can look before you decide, and the complete eligibility rules live in the usage guide rather than in the README.

Blocking those endpoints breaks Store, Xbox, OneDrive, and Phone Link

The compatibility section is the part most readers should read twice.

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, CDP graph features, and related identity workflows. That is not a side effect. It is the mechanism the gate is built on.

What the lab did confirm is narrower. Core desktop access worked in the lab. Windows Update scanning, Defender updating, and installs that happened during a historically blocked period were observed. But a controlled pending cumulative update and a feature update remain unvalidated, so the honest reading is that update behaviour was seen in passing and has not been tested under a controlled condition.

Unblock reverses the network controls, and the README says plainly what that means: it allows Windows to mint a real GDID again.

.\degdid.ps1 -Unblock

There is also a re-check instruction that applies to the whole workflow, since Status should be re-run after major Windows, firewall, security-product, or hosts-file changes. Any of those can undo a gate without touching the script.

Status prints full account, profile, and PUID values on purpose

Status intentionally displays full local account, profile, PUID, and g:<decimal> values. The instruction is to treat its output as private machine-identifying data.

That is an unusual thing for a diagnostic command to do deliberately, and the reason is visible in the shape of the tool: to tell you that no real-shaped PUID remains in the known inventory, it has to have read the inventory. A redacted display would let it pass in cases it should fail.

The ethics section follows from that. Do not commit private machine GDIDs, device tickets, unredacted Status JSON, or machine-identifying dumps. The project adds that a cited public court example is source material rather than a lab secret, which is a distinction worth keeping: the public record is quotable, the lab's own identifiers are not.

Stated purposes are research, privacy hardening, and analysis of opaque device identity, with an explicit line that this is not a guide to evade lawful process or to commit crimes. Anyone using it has to hold the same line themselves, since the tool hands back identifiers it just told you not to publish.

The evidence is 33 hours on one VM and 18 hours on one field machine

The lab record is specific and small. For Windows 11 build 26200 it 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, then Unblock, an observed remint, reprotect, and a clean reboot. There is also an MSA-connected field run that stayed protected through sign-out and sign-in, sleep and resume, reboot, and 18 hours.

The README bounds that evidence itself: it applies to the recorded machines and windows, and Windows 10 along with other Windows 11 builds are accepted with warnings rather than as equivalent lab claims. The failures, fixes, timings, and limitations that produced the current design live in the experiment index.

Read as a whole, this is a two-machine evidence base with one long soak on a VM and one long soak on a real signed-in machine. It supports the claim the tool makes, which is about a known mint path on a controlled machine. It does not support a claim about a fleet, and nothing in the documentation suggests one is being made.

The remaining unknowns have their own file, docs/open-questions.md, described as the short remaining research backlog.

The tool says it does not block the channel the court record implicates

The reason the project exists is stated plainly. GDID is a server-assigned installation identifier that Windows can acquire even when the interactive user has only a local account, and a local Windows account does not prevent that machine-level mint.

Court reporting in 2026 established that Microsoft held a GDID-to-URL/time/IP association in one investigation. That is the motivation.

And then the limitation: the public record does not identify the Windows component or network channel responsible, so the tool makes no claim to block that unknown channel.

That sentence is the most important line in the README, because it separates two different things. What the script demonstrably does is close a known mint path at the hosts and service layer, clear identity state from three stores, and verify the result. What the public record describes is an association of an identifier with a URL, a time, and an IP address. Nothing in the documented mechanism reaches a channel that has not been identified.

So the honest summary of the scope is the one the project gives itself: a GDID completion gate, not a general telemetry, browser-privacy, or court-record-channel suppression claim.

Editorial conclusion

deGDID fits someone running their own unmanaged Windows machine who wants to understand and reduce a server-assigned device identifier, and who will accept losing Microsoft account sign-in to get there. Four things to establish first. Which Windows build you are on, because only 25H2 build 26200 carries equivalent lab evidence and everything else is accepted with a warning. Whether your machine is unmanaged, since domain, Entra, workplace, and MDM systems are refused rather than attempted. Which Microsoft services you depend on, since blocking login.live.com, account.live.com, DDS, and the wlidsvc path degrades Store, Xbox, OneDrive, and Phone Link by design. And what your own goal is, because the tool clears local identity state and closes a known mint path while stating plainly that it does not stop whatever channel the 2026 court record actually describes.

Frequently asked questions

Official sources

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