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 wrong move that gave him away - it was an identifier that your Windows carries 24/7 and that Microsoft hands over to authorities when asked: the GDID. I've already talked about it in this article , and after writing it, I started wondering whether we could get rid of it.

So I spun up a small Windows 11 Pro VM and dug in with the help of my favorite LLM - here's what I found. What works, and especially what doesn't work at all, you'll see.

First, you need to understand what the GDID actually is. It's not your motherboard's 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 open a Windows session. It's written in plain text in your registry, your machine registers it in a directory on Microsoft's side, and a service quietly sends it back up when needed. And if you change your IP with a VPN, it doesn't care. The GDID doesn't budge one bit.

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:SOFTWAREMicrosoftIdentityCRLExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"

On my VM, it spat out g:6755487812206045. That's the one Microsoft can tie to everything I do. (In theory, mind you, because this is the code associated with my VM, so I don't care - which is why I'm showing it to you.)

You just read the label that's been stuck on your back.

Delete it? Forget it

Basic reflex: delete the key from the registry at HKCU:SOFTWAREMicrosoftIdentityCRLExtendedProperties and boom, no more tracker. That's what I tried first… I wiped the value, restarted the service that handles it, and nothing. Done? Nope. I opened the Microsoft Store for two seconds, and the GDID came back. Not a new one either - 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 again and again. Sure, if you reinstall everything, Windows gives you a new number, fine, but the old one and everything linked to it stays nice and warm on their servers. The past, you never get that back…

Disabling telemetry changes nothing either

Another piece of advice 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, and the services that send it back up were running at full speed. The tracker doesn't go through the telemetry you think you're cutting. It goes elsewhere - through the Connected Devices Platform and Delivery Optimization services.

You can click every privacy toggle in the settings, it doesn't give a damn.

Turning off the tap for real

Since we can't erase 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.

For that, we have 2 levers. The first is to disable the services that register and report your machine's info. The second is to send Microsoft's servers into the void simply via the hosts file - so even if the snooping services are running, they can't reach anyone. And most importantly, we don't touch login.live.com, 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 the normal way. 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, rather than dumping a ton of lines of code for you to copy-paste, I've bundled everything into clean, tested scripts, with a command to revert everything back to how it was.

The project is here: no-gdid on GitHub . First run the read-only audit to see where you stand, then the blocking scripts in preview mode, and only then with the option that actually applies 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 the network for a specific process without all this fuss, good old ProcNetBlocker [FR] already handles part of the job.

Alright, 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, take a look at your own situation. This audit is read-only - it changes nothing, it just shows you your GDID and which services in the chain are running:

powershell -ExecutionPolicy Bypass -File .auditGet-GDID-Audit.ps1

Then see what the mitigation would change, without applying anything. Without the -Apply option, both scripts run in preview mode and simply list what they would do:

powershell -ExecutionPolicy Bypass -File .mitigateDisable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .mitigateBlock-GDID-Endpoints.ps1

If you're happy with that, 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 .mitigateDisable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .mitigateBlock-GDID-Endpoints.ps1 -Apply

And to revert everything back to how it was, a single command:

powershell -ExecutionPolicy Bypass -File .mitigateRevert-GDID.ps1

Once applied, everything will go quiet… the registration services will be stopped, their servers unreachable, and your Microsoft account will stay 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 run a tutorial that sells you a dream. 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 removes the path we just blocked, but there's no proof yet that an anonymous identifier doesn't take over behind the scenes.

The only truly solid option for sensitive activity is more drastic: don't do that activity on Windows. A live Linux system, 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 know. No thanks, Microsoft.

Source: The Register and the reverse engineering by SmtimesIWndr .