GDID Explained: Windows' Hidden Device Identity

before this one, a quick note

the first post i wrote on this was honestly a bit vague on purpose. i was trying to keep it casual and not turn it into a wall of registry keys, so a bunch of the actual mechanics got glossed over. going back through it now there’s stuff i said that wasn’t quite right, and other stuff i just didn’t get into at all. so this is the part i said i’d come back to.

correction first

in the last post i said something like GDID is “there just after installing windows.” that’s not accurate, or at least not the full picture, and worth fixing before anything else.

GDID gets created during setup or when you sign into a Microsoft account, not automatically just from installing the OS. the actual identifying part, the PUID that gets tied to your identity, only exists once there’s a Microsoft account sign-in involved. if you install windows and go straight to a local account, skipping the cloud sign-in entirely, you don’t get that same identifier attached. no account link, no PUID.

so that’s a real correction, not a small one. it changes what the actual mitigation is.

what GDID actually is, technically

GDID is a 64-bit number. internally at Microsoft it’s called a PUID, Passport Unique Identifier, which is a leftover name from the old .NET Passport system before it became “Microsoft Account.” it shows up two ways depending on where you’re looking at it:

• hex format, 16 characters, something like 0018AAAABBBBCCCC
• decimal format with a g: prefix, which is the format used in the actual court filing — g:6755467234350028

the first two bytes matter. 0x0018 marks it as a device identifier. 0x0003 marks it as tied to a specific user account. so technically your windows install has its own device-level GDID, and separately, every Microsoft account you sign into on that machine gets its own user-level PUID. they’re related but not literally the same number.

where does it live. it sits in the registry locally. it also gets reported server-side, into what Microsoft calls its device directory. and it’s not some obscure background thing, it’s stamped onto a huge amount of ordinary telemetry — almost every ETW (Event Tracing for Windows) event carries a Device.ID field, and that field is the GDID.

reinstall windows and you do get a new GDID. that part’s true. what’s not true is that a fresh install gives you a fresh identity. Microsoft’s own filing footnote apparently admits a single Microsoft account can end up linked to multiple GDIDs over time, because as soon as you sign back into the same account, OneDrive, activation, and account history give Microsoft plenty of ways to connect the new number to the old one. so a reinstall changes the number, it doesn’t really break the thread.

what else windows is actually collecting

GDID is really just the identifier the rest of this data gets stamped with. the data itself is a separate, bigger pile.

required tier — device configuration, crash and hang detection, security patch status, basic reliability signals. can’t be turned off on consumer editions, full stop.

optional tier (used to be called “Full”) — this is the heavier one. website visit data, general usage and app activity, enhanced error reports, and it can capture a slice of device memory during a crash, which occasionally sweeps up fragments of whatever you were working on. also covers inking and typing data specifically to improve prediction accuracy.

worth repeating because it’s easy to miss: turning optional off doesn’t get you out of required, and required data is still tied to a device identifier regardless. the “off” switch only removes one layer, not the identity layer underneath it.

they also don’t pull optional data from every machine evenly. it’s sampled — only some percentage of devices get pinged for specific data types at any given time. Diagnostic Data Viewer is the tool if you want to check which bucket a given pc landed in.

and then AI on top of all that — copilot, recall, semantic search. Microsoft’s current line, especially after the 2026 pivot, is that recall and newer local agents run on-device, encrypted, gated behind windows hello, not shipped to the cloud or used for training. that’s the claim. what’s less publicized is that even “on device” ai still depends on the same telemetry-plus-identity infrastructure everything else in this post is about, it’s just not shipping the raw content itself off the machine. the pipe is still the pipe.

disabling telemetry, realistically

none of this fully removes GDID or fully zeroes out telemetry on Home or Pro. here’s what actually reduces exposure, roughly in order of how much it matters:

1. use a local account, not a Microsoft account. given the correction above, this is genuinely the biggest lever available to a regular user. no cloud sign-in, no PUID getting attached in the first place.
2. Settings > Privacy & Security > Diagnostics & Feedback, turn optional diagnostic data off. drops you to the required-only baseline.
3. Group Policy (gpedit.msc, Pro/Enterprise/Education only) — Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds, set “Allow Telemetry” to the lowest available level.
4. Registry, for Home editions where gpedit isn’t available — same setting exists under a registry key (AllowTelemetry), though editing it manually carries the usual “you can break something” risk.
5. Disable the Connected User Experiences and Telemetry service (DiagTrack) — stops one of the main services responsible for packaging and sending diagnostic data, though Microsoft doesn’t officially support running with it off.
6. Block known telemetry endpoints at the firewall or hosts file level (vortex.data.microsoft.com, settings-win.data.microsoft.com, and similar) — blunt but effective for the determined.
7. Third-party tools like O&O ShutUp10 automate a chunk of the above if you don’t want to dig through settings manually.

even doing all of it, on Home or Pro, some required-tier data still goes out, and if you’ve ever signed into a Microsoft account on that install, the GDID/PUID link already exists in Microsoft’s records regardless of what you turn off afterward. only Enterprise, Education, and Server editions get an actual documented path to zero.

can you actually remove GDID once it exists

not really, no. locally you can wipe the registry entries, but Microsoft ties the identifier to hardware descriptors and account history on the server side, so a local deletion doesn’t erase anything on their end. the only thing that generates a genuinely new GDID is a clean reinstall, and even that gets threaded back to your old identity the moment you sign into the same account again. the closest thing to an actual reset is: clean install, local account only, never sign into that Microsoft account on that install again. which for most people defeats half the reason they use windows in the first place.

how the fbi actually built the case, mechanically

this is the part worth slowing down on because “telemetry caught him” undersells how specific it actually got.

the attack itself ran may 12–15, 2025. attackers called the jeweler’s IT help desk from Google Voice numbers, posed as locked-out employees, and social-engineered staff into resetting passwords and MFA. standard Scattered Spider opening move, nothing new there. what’s new is what happened after.

may 12, 7:21pm UTC. GDID g:6755467234350028 gets logged visiting the ngrok signup page. ngrok is a legit tunneling tool, normally used to reach stuff behind firewalls, but Scattered Spider crews use it to keep a foothold on compromised servers without setting off the usual network alarms. that 7:21pm timestamp lines up exactly with when an ngrok account tied to the intrusion got created, routed through a Tzulo VPN proxy.

three hours later. same GDID, same proxy, now hitting the victim jeweler’s site directly.

on its own that’s a coincidence you could argue about. what turns it into a case is that this wasn’t a one-off match, it was a pattern that kept repeating across roughly eight months and four countries. investigators pulled the GDID’s historical telemetry and started finding more IPs tied to the same device, then cross-referenced those against login records from Snapchat, Facebook, Apple, and Ubisoft, plus travel records. same device, same timestamps, different services, different countries — Estonia, New York, Thailand — and it kept lining up. his own public Snapchat photos matched hotel bookings and travel timelines the GDID had already put him in.

worth being precise about what GDID actually did here, because it gets oversold in a lot of the coverage. it wasn’t a smoking gun by itself. what it did was give investigators a fixed point. VPN IPs rotate, proxies rotate, but the underlying windows installation kept reporting the same identifier through all of it, so once they had one confirmed match, they could pull a whole history of everywhere else that same device had shown up. it’s less “one identifier convicts a man” and more “one identifier turns a pile of disconnected sightings into a single timeline.”

and this wasn’t even the first flag. Microsoft had already sent the FBI a criminal referral back in october 2024, over a year before the arrest, off the back of its own telemetry pattern-matching, separate from this specific complaint. the case had eyes on him for a long time before it closed.

ok can we talk about how he used windows though

because reading the affidavit, the GDID doing its job is honestly the less embarrassing part of this story. the actually embarrassing part is what he did on top of it.

this is a guy allegedly running social engineering attacks against a jeweler’s help desk, tunneling through ngrok, routing through a VPN proxy specifically to stay untraceable — and then, on the same physical machine, in overlapping sessions, logging into his own personal Snapchat, Facebook, Apple ID, and Ubisoft account. and playing Growtopia. on the machine. running an $8 million extortion attempt on.

like. you can rent a proxy for like eight dollars a month. you can run a separate machine, a separate VM, a live USB, literally anything, for the part of your life where you’re allegedly committing federal crimes, and keep that fully apart from the part of your life where you’re posting selfies with your face behind hundred dollar bills and a chain that spells out “hack the planet.” he didn’t do that. he used one windows box for both, which means the one identifier windows quietly stamps on everything did exactly what it’s built to do: it noticed the same machine was living two lives and stitched them into one.

and then, per the reporting, he was caught boarding a flight to japan carrying two hard drives full of evidence. physically. on his person. through an airport.

so yeah, GDID is a genuinely uncomfortable piece of tech to learn about, no argument there. but crowning it the sole reason a guy who kept his hacking sessions and his Snapchat sessions on the same box, then walked through TSA holding the evidence, got caught — that’s giving windows telemetry a bit too much credit. the operating system provided the thread. he’s the one who spent eight months tying his real identity to the other end of it, on purpose, apparently without it occurring to him even once that maybe don’t.

the linux side of this, personally

i’ve been on CachyOS with COSMIC as the DE for a while now, so this part’s less theoretical for me than it might read.

there’s no equivalent of GDID baked into the distro. no central identifier that pacman, the kernel, or COSMIC itself assigns and phones home with as a matter of course. when something does talk to the network, it’s usually scoped and obvious why — pacman checking a mirror for updates, that’s it, that’s the request, it’s not stitched to a persistent cross-service identity token the way windows telemetry is.

COSMIC being relatively new and Rust-based, System76 hasn’t built anything resembling a telemetry pipeline into it, and Arch-based distros in general aren’t shipping a background diagnostics service the way windows ships DiagTrack. that doesn’t mean zero network activity, obviously updates need checking, AUR helpers reach out, individual apps can phone home on their own. but there’s no OS-level identity layer sitting underneath all of it correlating everything back to one persistent number the way GDID does on windows.

the honest tradeoff, and i think this gets skipped over a lot in “just switch to linux” takes — you give up the recovery conveniences Microsoft leans on to justify all this in the first place. no cloud-tied bitlocker recovery key baked in by default, no automatic license reattachment, less of that “sign in and everything’s back” experience. on CachyOS if something breaks, it’s mostly on you to have backed it up. that’s a real cost, not nothing. it’s just a cost i’d rather pay myself than have it quietly handled by a system that also happens to log everything centrally, with no visible toggle, in case someone with a court order asks nicely enough.