What is really behind the Windows ‘GDID’

In the U.S. Department of Justice court documents Alleged members of the hacker group Scattered Spider At the beginning of the month, a term appeared that caused quite a stir in the tech scene: The Global Device Identifier (GDID).

On Twitter/X it was immediately shocked: “Microsoft spies on us with an indelible 128-bit hardware fingerprint generated from serial numbers!”

Short answer: Wrong. Long answer: The truth is technically extremely exciting, but differs significantly from the social media semi-knowledge. Let's take a look under the hood of Windows 11.

Myth busting: What the GDID really is

Let's take a look at the court file procedure linked above (United States v. Peter Stokes). There the GDID dives concretely in the format g:6755467234350028 open.

If you convert this number from decimal to hexadecimal, you get 0x0018000FC8CB93CC.

No 128 bits: This is a simple 64-bit number.
No hardware serial number hash: In the case file, it is explicitly stated that a Reinstalling Windows creates a completely new GDID. If the ID were calculated from fixed serial numbers of your GPU or motherboard, it would remain the same after formatting.

So what is GDID really? Simply the Device PUID (Passport Unique ID) of your Microsoft account? For this we have to dig bit deeper.

How does identity chaos work in Windows?

Think of your Windows system like a hotel:

wlidsvc.dll (The receptionist): If you sign in with your Microsoft account, this service will call the Microsoft server (login.live.com) and says: “Hey, I'm a new Windows installation, give me a passport!” The server generates a unique number (the Device PUID) and sends it back.
Registry (the vault): The Windows system writes this pass unencrypted to your local vault (the registry).
cdp.dll (The VIP Manager): The Connected Devices Platform Service grabs this number from the vault and logs the device into the worldwide Microsoft network (Device Directory Service). As a result, features such as Phone Link or the Clipboard synchronization, which device is currently online.
dosvc.dll (The statistician): Delivery Optimization reads the ID and attaches it to telemetry data.

In short: The GDID is not calculated locally from your hardware, but Assigned by the Microsoft server when registering.

The path of GDID through the system

The whole stack looks like this from the bottom up:

Plaintext

[ Microsoft Server (login.live.com) ] │ (assigns Device PUID to) ▼ [ wlidsvc.dll ] (Microsoft Account Service) │ (stores ID in Registry) ▼ [ HKCU Registry ] │ (Liest ID aus) ▼ [ cdp.dll ] (Connected Devices Platform) │ (Meldet Device an DDS) ▼ [ Delivery Optimization / Telemetry ] (Spittt UCDOStatus.GlobalDeviceId aus)

Even if you don't use a Microsoft account, the Connected Devices Platform (CDP) uses an anonymous device path to manage a comparable identifier.

Find your own GDID (Do It Yourself)

Want to know what your own GDID looks like? If you're logged in with a Microsoft account, you don't even need admin rights. A simple PowerShell command is enough:

$hex = (Get-ItemProperty 'HKCU: \SOFTWARE \Microsoft \IdentityCRL \ExtendedProperties').LID "g:$([Convert]:ToUInt64($hex,16))"

The result spits you exactly the format g:<decimal> This was also found in the FBI investigators' court records.

Important note: Post your GDID never publicly in forums or screenshots! Together with your user ID or your account ID, your device can be uniquely identified.

Will you get rid of that part?

Since the GDID is assigned on the server side and anchored locally in the identity structure, the mere deletion of local cache folders helps little, because the ID is simply re-drawn from the registry.

If you want to minimize tracking:

Disable Connected Devices Services: The stopping of CDPSvc and CDPUserSvc interrupts synchronization with the Microsoft Device Graph.
Turn off activity history: In the Windows settings under Privacy & Security -> Activity History.
Reinstallation: Creates a completely new GDID, but immediately reconnects it to your Microsoft account the next time you log in.

An interesting experiment can also be found, for example, in the detailed collection on Github and it-connect.tech on the topic:

Appendix: Deep-dive, blockade & collateral damage

If you want to understand the exact path of the GDID through the system or prevent the transmission, you will find the technical details under the hood here.

Deep dive: As the GDID in the `wlidsvc.dll` forged

If you want to look even deeper into the binary fabric: The wlidsvc.dll (Microsoft Account / Passport Service) is the only identity service in Windows that uses the term GlobalDeviceId Contained in plain text. Here is the complete logic for device provisioning:

The random key is not the ID: If you look at the code, you will find calls like BCryptGenRandom or CCryptRandom::GenRandom. This, however, generates not the GDID itself, but only the local device key, the BindDeviceToHardware use.
Server assignment via SOAP: The client sends a DeviceAssociateRequest (Passport PPCRL SOAP) login.live.com. The answer contains the XML structure <ps:DevicePUID>.
Clear text parsing: The method CAssociateDeviceRequest::ParseResponseBody reads the value via XPath directly from the response body:

/S:Envelope/S:Body/ps:DeviceUpdatePropertiesResponse/HWPUIDFlipped

Registry persistence: DeviceIdStore::LogToRegistry then puts the ID in plain text in your user hive (HKCU).

The Magic of Prefixes: `0018` vs. `0003`

If you are in your registry HKCU \SOFTWARE \Microsoft \IdentityCRL \ExtendedProperties by value LID searches (or under ...\Immersive \production\Token\{...}\DeviceId), you see a 16-digit hex number.

On the basis of the first four digits, you immediately recognize what you are dealing with:

0003... (User PUID): Identifies your specific Microsoft user account.
0018... (Device PUID): This is the equipment room, talk your GDID.

The value indicated in the court file (0x0018000FC8CB93CC) It is exactly in this 0018Device class.

How the device authenticates itself on the graph

The token cache of Windows (HKLM \SOFTWARE \Microsoft \IdentityCRL \NegativeCache \...) Stores device-specific tokens. These are precisely tailored to the endpoints that the Connected Devices Platform Service (cdp.dll) is directed to:

scope=service::dds.microsoft.com::MBI _SSL _TOKEN _BROKER
scope=service::activity.windows.com::MBI _SSL _SA _TOKEN _BROKER

The Microsoft account service not only provides the ID, but also the appropriate access data to deliver the data to the Device Directory Service (DDS).

Can the GDID be deleted or blocked?

Can you just delete the registry value? Sure. Does that bring anything? No.

After all, the GDID is not only on your PC, but is burned into Microsoft's servers. The next time your box connects, Windows simply pulls the ID back and writes it back to the registry. Who wants to fight the GDID effectively, does not have to screw around the operating system, but Starting in the network.

According to current knowledge, there are two paths that lead to the goal. But it can't be done without restrictions. You can only choose how much collateral damage you want to accept.

Path 1: Nuclear fusion (totally prevent GDID creation)

If you want to block the emergence of GDID from the outset, communication would not have to take place in the first place. In order to block the transmission, you would have to login.live.com Lock out at the network level.

The effect: If you run a fresh Windows installation directly from a DNS blocker, no GDID is registered with Microsoft. From a Microsoft point of view, your PC simply does not exist.
The hook: login.live.com is the eye of the needle for the entire Microsoft account. If you block this, Microsoft Store, OneDrive, Microsoft 365 and all MS account-based UWP apps will fly around your ears.

Path 2: The precision bomb (interrupt reporting only)

You allow generation, but cut down on the telemetry and sync paths of Windows. Staying with it login.live.com available, but the evaluation and synchronization services are disconnected.

If you run Pi-hole, AdGuard Home or a Technitium DNS, you can solve this elegantly with network-level wildcards (the hosts-File on Windows unfortunately does not pack wildcards *).

Rule set using the example of AdGuard Home:

||login.live.com^$dnsrewrite=0.0.0.0 ||dds.microsoft.com^$dnsrewrite=0.0.0.0 ||cdpcs.access.microsoft.com^$dnsrewrite=0.0.0.0 ||do.dsp.mp.microsoft.com^$dnsrewrite=0.0.0.0 ||activity.windows.com^$dnsrewrite=0.0.0.0

(Note: ||do.dsp.mp.microsoft.com^ directly hits the entire delivery optimization level, including all regional subdomains).

If you want to automate the whole thing locally without constantly turning on the DNA, you can the Open Source Script no-gdid (MIT license). The script disables the services CDPSvc, CDPUserSvc and DoSvc and bends their endpoints while the MS account login remains intact. (Before doing a backup or a VM snapshot!)

Which Windows services are breaking away? (Overview)

Each DNS block takes its toll. Here's an overview of what happens when you turn the adjusting screws:

Blocked domain	Role in the GDID chain	What doesn't work after that?
`login.live.com`	GDID Deployment & Login Tokens	Massive: MS account, Store, OneDrive, Office 365, Account UWP apps.
`dds.microsoft.com` `cdpcs.access.microsoft.com`	Registration in the Device Graph (DDS)	Comfort: Smartphone link (Phone Link), ‘Resume to PC’, cloud clipboard, nearby sharing.
`do.dsp.mp.microsoft.com` (+ Subdomains)	Delivery Optimization Reporting	Low: P2P distribution of updates & store content. Windows Update falls back cleanly on direct downloads.
`activity.windows.com`	Activity history	Minimum: On Windows 11, this is negligible because the timeline has been deleted anyway.

Side note to the Microsoft Store: If only the reporting domains are blocked, the store sometimes behaves a bit bit picky. Downloads fail on the first attempt, but usually go through after two or three attempts.

No toggle, no consent

The frustrating thing about GDID is the complete lack of transparency: There are No switch, no consent screen and no real documentation from Microsoft. Addendum: There is at least one document in which the GDID appears.. But with a poor description:

Microsoft global device identifier. This is an identifier used by Microsoft internally.

Of course, other operating systems also use unique identifiers: Apple has it Hardware UUID/DSID, Linux distros use the /etc/machine-id. The subtle difference: On Linux or macOS you can view these IDs 1) or / and 2) control them with on-board resources.

Windows hides the GDID completely from the user. In any case, the usual "privacy" sliders in the Windows settings have no effect on the transmission of the GDID according to previous findings.

conclusion

The GDID is not an ominous spy chip hidden deep in silicon, but simply a server-side token for Microsoft's device ecosystem. Okay, admittedly, it's not much better now.

The fact that law enforcement agencies use such IDs to assign suspicious activities (such as ngrok tunnels or VPN connections) to a specific system, if this is available and usable, shows once again:

Anonymity on the net requires in-depth knowledge of how modern operating systems call home.