As I mentioned earlier, in April 2026, the FBI caught an alleged Scattered Spider member. The guy was hiding his traffic behind a VPN, with IPs across three different countries. And guess what? It wasn't a rookie mistake that gave him away - it was an identifier that your Windows carries around 24/7 and that Microsoft hands over to the authorities when asked: the GDID. I already told you about it in this article , and after writing it, I started wondering whether you could actually get rid of it.
So I spun up a little Windows 11 Pro VM, rolled up my sleeves, and dug in with the help of my favorite LLM - and here's what I found. What works, and above all what doesn't work at all - you'll see.
First, you need to understand what the GDID actually is. It's not your motherboard serial number, it's not a hash tied to your hardware. No - it's a 64-bit PUID, meaning an identifier that Microsoft's servers attach to your account the moment you sign into Windows. It's written in plain text in your registry, your machine registers it in a directory on Microsoft's side, and a service quietly reports it back when needed. And if you change your IP with a VPN - it doesn't care. The GDID doesn't budge.
Look your own tracker in the face
Let's start by seeing it with our own eyes. Open a PowerShell and paste this:
$lid=(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"
On my VM, it spit out g:6755487812206045. That's the one Microsoft can link to everything I do. (In theory, at least - this is my VM's code, so I don't care, which is why I'm showing it to you.)
You just read the label they've been sticking on your back.
Delete it? Forget it
The obvious reflex: delete the key from the registry at HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties and boom, no more tracker. That's what I tried first... I deleted the value, restarted the service responsible for it, and - nothing. Victory? Nope. I opened the Microsoft Store for all of two seconds, and the GDID was back. Not a new one, mind you - THE SAME ONE!!
That's the crazy part. Your GDID isn't stored on your disk - it's stored at Microsoft, firmly attached to your account like a barnacle on a rock. Your PC just re-downloads it over and over again. Sure, if you do a full reinstall, Windows gives you a new number - but the old one, along with everything linked to it, stays nice and cozy on their servers. The past is never gone...
Disabling telemetry doesn't change a thing either
Another tip you see everywhere is to disable Windows telemetry. On my VM, the classic telemetry service was already stopped. And yet my GDID was right there, perfectly readable, with the services that report it running at full speed. The tracker doesn't go through the telemetry you think you're cutting. It goes through something else - the connected device platform services and delivery optimization.
You can click every single privacy toggle in the settings - it doesn't give a damn.
Shutting the tap off for real
Since we can't delete it, we're going to do the only thing within our power: stop it from getting out. And without logging out of the Microsoft account, so the PC stays usable.
To do that, we have 2 levers. The first is to disable the services that register and report your machine's information. The second is to redirect Microsoft's servers to nowhere via the hosts file - so even if the snitching services are running, they can't reach anyone. And above all, we leave login.live.com alone, otherwise goodbye Microsoft account login.
There is one small catch, as you might expect... The service that reports the GDID - DoSvc - refuses to be disabled through the normal route. Even as admin, Windows throws an "Access denied" at you. The workaround is to disable it directly in the registry, where the admin does have write access where the service manager blocks you.
Now to do all this, rather than dumping walls of code for you to copy-paste, I've packaged everything into clean, tested scripts, with a command to revert everything back to how it was.
The project is here: no-gdid on GitHub . Run the read-only audit first to see where things stand, then the blocking scripts in preview mode, and only then with the option that actually applies the changes. Test it in a VM with a snapshot before doing this on your real machine, because we are disabling system services after all. And if you just want to cut network access for a specific process without all this fuss, good old ProcNetBlocker already handles part of the job.
Let's go!
Open a PowerShell as administrator, and the first time, do it in a VM with a snapshot so you can test things and get familiar with the commands. Step 1, clone the project:
winget install --id Git.Git
git clone https://github.com/Korben00/no-gdid
cd no-gdid
First, let's look at your own situation. This audit is read-only - it doesn't change anything, it just displays your GDID and which services in the chain are running:
powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1
Next, let's see what the mitigation would change, without applying anything. Without the -Apply flag, both scripts run in preview mode and simply list what they would do:
powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1
If that looks good, let's cut it for real. This time we add -Apply: the services that register and report the device are disabled, and the corresponding Microsoft servers are sent into the void via the hosts file. Your Microsoft account stays connected:
powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply
And to revert everything back to how it was, just one command:
powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1
Once applied, things will go quiet... the registration services will be stopped, their servers unreachable, and your Microsoft account will still be connected. The GDID will obviously still be readable on disk, but it won't be reported back to Microsoft anymore.
The uncomfortable truth
I'm not going to sell you a dream here. These steps reduce what Microsoft will be able to correlate going forward, but they don't erase your GDID - which has been sitting on their servers since your very first login - and they don't make you anonymous. Also, switching to a local account , as I've seen suggested elsewhere, does remove the path we just blocked, but there's no proof that some anonymous identifier doesn't take over behind the scenes.
The only genuinely solid solution for sensitive activity is more drastic: don't do that activity on Windows. A live Linux session, for example, gives you full control over what leaves your machine. Everything else is just damage limitation, nothing more.
There you go - defending your privacy starts with knowing what's been stuck on your back, and now you do. No thanks, Microsoft.
Source: The Register and the reverse engineering by SmtimesIWndr .
This article was originally written in French and automatically translated. Read the original.