The GDID Is Not What You Think

The Windows Global Device Identifier (GDID) is a real telemetry identifier that appeared in a U.S. federal criminal complaint in July 2026. Social media claimed it was a 128-bit identifier derived from hardware serial numbers. Both claims are wrong.

What the Court Actually Said

The complaint (United States v. Peter Stokes, N.D. Ill., July 2026) states: "a Global Device Identifier in the Windows ecosystem is a persistent, device level identifier designed to uniquely identify an installation of a Windows operating system on a device... A GDID remains consistent across Windows operating system updates on a device, but a reinstall of Windows... will be tied to a new unique GDID." The value shown is g:6755467234350028. In hex that's 0x0018000FC8CB93CC — a 64-bit number. A reinstall gives a new GDID, so it cannot be a hash of fixed hardware.

Where GDID Surfaces

Microsoft's public Azure Monitor docs define a GlobalDeviceId column in the UCDOStatus (Delivery Optimization) table: "Microsoft global device identifier. This is an identifier used by Microsoft internally." But Delivery Optimization only reports it. The real owner is the Connected Devices Platform (CDP).

CDP Registers the GDID

In C:\Windows\System32\cdp.dll, there's a full Device Directory Service (DDS) registration subsystem. Capturing CDP's ETW providers on a live Windows 11 (build 26200) showed:

DdsClient::RegisterUserDeviceAsync()   RegistrationReason: Startup   Account Type: MSA
DDSClient: Registration response received. HTTP status code: 200
OnRegisterUserDeviceComplete
GetDeviceIdAndTicketActivity -> deviceid: 0018XXXXXXXXXXXX

That deviceid matches the complaint's structure: both are 64-bit values in the 0x0018 high word class (device PUID namespace).

CDP Does Not Compute the ID

With public PDB symbols (cdp.pdb), the device ID path is just a request/wait against the identity stack. The callback OnGetStableDeviceIdCompleted stores the string directly — no computation, no serials.

The Mint: wlidsvc and MSA Device PUID

C:\Windows\System32\wlidsvc.dll (Microsoft Account / Passport service) contains the literal GlobalDeviceId and the full device provisioning machinery. It communicates with login.live.com via SOAP, and the server assigns a Device PUID (Passport Unique ID). The client parses the response XML using XPath:

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

This server-assigned PUID is why a reinstall yields a new GDID.

Persisted in Cleartext Registry

You can find your own GDID in the registry without admin:

(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

This returns 16 hex digits (e.g., 0018XXXXXXXXXXXX). The same value appears in HKCU\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{...} as DeviceId. User PUIDs are 0003 class; device PUIDs are 0018 class.

Full Chain

  1. wlidsvc provisions device with login.live.com → server assigns Device PUID → stored in registry.
  2. cdp.dll reads the PUID via identity stack → registers it into DDS as g:.
  3. Delivery Optimization reports it as UCDOStatus.GlobalDeviceId.

Reducing Exposure

  • Use a local account: CDP still creates an anonymous device path, but the GDID won't be tied to an MSA.
  • Block dds.microsoft.com and activity.windows.com via firewall or hosts file.
  • Delete the registry keys under IdentityCRL to clear the stored PUID (will be recreated on next MSA sign-in).

Methodology

All claims are tagged: [COURT] for primary source, [OBSERVED] for live reproduction on Windows 11 (26200), [STATIC] from binaries and public PDBs, [ASSESSED] for strong inference. The writeup includes full disassembly snippets and ETW traces.

Limitations

The author notes a correction: using a local account does not prevent a GDID—CDP has an anonymous device path. The underlying system is still factually correct but missing that detail.