Windows Global Device ID Tracking Survives VPNs and Local Accounts

Windows maintains a persistent device identifier on many installations that survives OS updates, cuts through VPN obfuscation, and allows Microsoft to reconnect the same machine across different services, sessions, and IP addresses, according to court filings and PCMag's reporting. Most users have never heard of it. The FBI used it to help build a cybercrime case against an alleged Scattered Spider member, and VPN provider Windscribe's attempt to remove it this week showed just how deeply the identifier is embedded in Windows.

The Department of Justice unsealed a criminal complaint against Peter Stokes, a 19-year-old alleged Scattered Spider member extradited from Finland, earlier this month. Investigators traced his Windows machine through VPN obfuscation across multiple countries over roughly eight months using a single identifier Microsoft holds server-side, per PCMag's reporting on the case. Stokes has been charged and is presumed innocent.

For ordinary Windows users, the practical upshot is blunt: standard privacy tools don't touch this layer. Using a VPN or signing in with a local account appears insufficient to prevent the identifier from being generated or transmitted, based on Windscribe's own testing. The only available workaround breaks logins to Xbox, Outlook, and the Microsoft Store. There is no clean opt-out.

How Windows Global Device ID tracking works

The identifier is not a keylogger or a screen recorder. Think of it less as a sensor and more as a library card number: it doesn't record what you do at home, but every time your Windows installation checks in with a Microsoft service, that number gets stamped on the record.

Technically, the GDID is a 64-bit server-assigned Device PUID, not a 128-bit value generated from hardware serial numbers as some early viral posts claimed, according to independent technical analysis by Jaspreet Singh published earlier this month. Microsoft's servers generate it, store it locally in the Windows registry in plaintext, and register it through the Connected Devices Platform into Microsoft's Device Directory Service. A clean reinstall produces a new GDID, which rules out derivation from fixed hardware components.

One nuance worth flagging: Singh's analysis ties the identifier to provisioning against a Microsoft account, but Windscribe found that its test Windows VM still generated a GDID even when configured as a local user account, per PCMag UK this week. Whether Microsoft-account provisioning is strictly required in every configuration remains an open question.

The identifier becomes especially consequential when attached to extensive telemetry and account information, a Substack legal analysis published last week argued. The key threads through Windows diagnostic telemetry, Edge enhanced diagnostics (including browsing history when that feature is enabled), Microsoft Store purchase and license records, and the Connected Devices Platform, according to Computing. Microsoft's own documentation surfaces a GlobalDeviceId field in Azure Monitor and Windows Update for Business telemetry schemas, described only as a "Microsoft global device identifier used internally," the Substack analysis noted. The telemetry schema carrying it can also include approximate city and country derived from an IP address, ISP information, and the last time a device contacted Microsoft. The identifier is carried alongside those fields, not fused into them.

The Stokes case: how GDID cuts through VPN separation

The evidentiary force in the Stokes prosecution didn't come from a single log entry. It came from repetition across contexts over time, which is exactly what a correlation key is designed to enable.

The FBI's initial problem was the standard one: IP addresses pointed to VPN exit nodes, not to people or machines. Microsoft's records closed that gap. The complaint states that Stokes's Windows machine, carrying GDID g:6755467234350028, accessed ngrok's account signup page at 19:21 UTC on May 12, 2025, precisely when an attacker-controlled ngrok account used in the intrusion was created, as PCMag UK reported from the criminal complaint earlier this month. The same GDID appeared behind the VPN proxy that reached the jewelry retailer's systems hours later. Scattered Spider allegedly stole at least 77GB of data from the retailer and demanded roughly $8 million in cryptocurrency ransom, according to Computing.

What converted that link into evidence was what followed: the same Windows installation kept appearing across IP addresses in Tallinn, New York, and Thailand that corresponded to Stokes's known travel, per Computing and the Substack analysis. A VPN separated sessions at the network layer. Different accounts separated activity at the application layer. The GDID reconnected both.

One detail in the complaint is worth holding. Microsoft could associate the identifier not just with its own services but with the timestamps of when that Windows machine accessed third-party services, per PCMag's reporting on the unsealed filing. That's the practical bridge between "internal identifier" and investigative tool: Microsoft's records could place a specific Windows installation at a specific third-party site at a specific moment, independent of IP address.

What users can and can't do: remove Global Device ID from Windows

Understanding the practical picture requires separating three categories: privacy measures that don't address GDID at all, partial mitigations, and things that remain outside user control entirely.

Measures that don't help. Using a VPN or a local account does not appear to prevent GDID from being generated or transmitted. The Stokes case demonstrated the VPN limitation directly. Windscribe's own testing showed the local-account limitation. Simply deleting the registry entry also fails: after manual deletion, the identifier reappeared after a reboot, indicating the OS can rebuild it from other sources, PCMag UK reported.

What the Windscribe GDID script does. The deGDID project, available on GitHub and run via PowerShell with administrator rights, attempts two things: delete the identifier from known registry locations, and block the network paths Windows uses to retrieve a replacement. PCMag UK's hands-on test on a Windows 11 machine found the script ran without errors, then broke logins to Xbox, Outlook, and the Microsoft Store, because the firewall rules blocking GDID retrieval also cut off connectivity those services depend on, per PCMag UK. Windscribe acknowledges the tradeoff directly: "Unfortunately, this can break some Microsoft services, but OS functionality remains intact." The company's disclaimer includes a liability waiver from both Windscribe and its CEO, Yegor Sak. Windscribe also can't guarantee the script suppresses every GDID transmission pathway, since the exact Windows components that trigger it haven't been fully mapped publicly, per PCMag UK.

What remains outside user control. deGDID does nothing to erase the records Microsoft already holds server-side. Singh's technical analysis notes the identifier cannot be fully removed on a normal, activated, Microsoft-account-bound Windows installation. Even a full reinstall, which does generate a new GDID, may not create genuine separation: Microsoft may still be able to connect the new identifier to previous ones through a shared Microsoft account, OneDrive, or activation records, the Substack analysis noted. Users can, however, read their own GDID locally from the registry without administrator rights, Singh notes, which at minimum makes the system observable even if it isn't controllable.

What Microsoft hasn't explained

Device identifiers aren't inherently controversial. The concern researchers have raised is more specific: Microsoft appears to have built a consequential identity layer into Windows without disclosing its scope, providing user controls, or explaining how it governs law-enforcement access, according to the Substack legal analysis.

Microsoft's public documentation surfaces GlobalDeviceId in a single-line reference in Azure Monitor schemas. Because almost nothing else was published by Microsoft, the technical details now in circulation came from outside researchers reverse-engineering the identifier after the Stokes complaint made it newsworthy, Computing reported. There is no dedicated privacy notice for GDID, no consent prompt during Windows setup, and no reset or review mechanism inside Windows Settings or the Microsoft privacy dashboard. Windscribe itself was explicit about the limits of what's currently known: "The public case does not identify the exact Windows component or event that produced the logs," per PCMag UK's reporting on the company's blog post.

The Substack legal analysis argues that GDID almost certainly constitutes personal data under GDPR and UK GDPR when processed alongside telemetry, location signals, and account information, since GDPR expressly covers online identifiers and a pseudonymous number remains personal data where Microsoft can link it to a device or account. Two specific compliance questions stand out. On purpose limitation: using an identifier for Windows licensing doesn't automatically justify using the same identifier for cross-service telemetry and retrospective law-enforcement correlation. On transparency: GDPR Articles 12 and 13 require clear, accessible information about purposes, legal bases, recipients, and retention, none of which Microsoft has publicly provided for GDID. These are arguments from a legal analysis, not findings from a regulator or court. Microsoft has not addressed any of these questions publicly, and no regulator has announced a formal inquiry.

What we know, what we don't, and what comes next

Three points are now well supported by the complaint and follow-up reporting. GDID is real, has already been used in a federal prosecution to identify a specific Windows machine across eight months of VPN-obscured activity, and has no clean user-side opt-out. Windscribe's tool makes that third point concrete by showing what it actually takes to interfere with the identifier, and what breaks in the process.

Several significant questions remain open. Which specific Windows components transmit GDID, and under what conditions? Does the identifier behave differently across Windows versions or hardware configurations? What records can users access or request Microsoft delete, and through which mechanism? The answers determine how serious the exposure is for ordinary users versus people specifically relying on operational compartmentalization.

For privacy-conscious users and security researchers, the more consequential question is whether European and UK regulators treat the absence of disclosure as a compliance issue worth investigating. As Singh's analysis concluded, on a standard Microsoft-account-bound installation, the identifier cannot be fully removed. Whether that's a feature or a problem depends entirely on what Microsoft chooses to disclose, and to whom.