Windows GDID: Why a VPN Cannot Hide Persistent Device Tracking

Microsoft’s Windows operating system uses a persistent Global Device Identifier, or GDID, that can distinguish one Windows installation from another across selected Microsoft services—and there is no ordinary privacy switch that lets users disable it. The identifier became a public controversy after a newly unsealed federal complaint described how Microsoft records associated with one GDID helped investigators connect VPN-routed activity, website visits, online accounts, and travel patterns to an alleged member of the Scattered Spider cybercrime group. The disclosure does not prove that Microsoft records every action performed on every Windows PC, but it does reveal a durable identity layer whose operation, retention, and user controls remain poorly explained.

---

Background​

Persistent identifiers are not new to Windows, cloud platforms, mobile operating systems, or enterprise device-management systems. Modern computing services need stable ways to distinguish devices for software licensing, update eligibility, fraud prevention, account security, synchronization, app entitlements, and fleet administration.
Windows already exposes or uses numerous identifiers, including hardware IDs, installation IDs, advertising IDs, Microsoft Entra device IDs, security identifiers, Windows activation records, TPM-backed keys, and identifiers associated with Microsoft accounts. These values serve different purposes and do not necessarily identify the same object.

What makes the GDID different​

Microsoft reportedly described the Windows GDID to federal investigators as a persistent, device-level identifier designed to identify an installation of Windows on a physical device or virtual machine across certain Microsoft services and scenarios. It remains consistent through routine Windows updates but changes when Windows is reinstalled.
That wording matters. The GDID is not simply a serial number burned into a motherboard, and describing it as a permanent hardware fingerprint would overstate the available evidence. It follows an operating-system installation rather than necessarily following a physical computer forever.
A single Microsoft user can therefore accumulate multiple GDIDs by reinstalling Windows or using several PCs and virtual machines. Conversely, one Windows installation may continue presenting the same GDID while moving between networks, countries, VPN endpoints, and ordinary user accounts.

Why the disclosure feels new​

Microsoft has referenced Global Device IDs in limited technical documentation, particularly in connection with Windows Update and managed-device registration. However, the identifier has not been presented to consumers with the visibility given to the Windows advertising ID, diagnostic-data controls, location permissions, or app-specific privacy settings.
The surprise is therefore not merely that Windows contains another identifier. It is that a durable Windows installation identity became understandable to the public mainly through a criminal complaint, rather than through a clear Windows privacy control, architectural document, or consumer-facing explanation.

---

The Criminal Case That Exposed the Identifier​

The GDID received widespread attention following the arrest and extradition of Peter Stokes, a 19-year-old dual citizen of the United States and Estonia. Federal prosecutors allege that Stokes participated in Scattered Spider, a loosely organized cybercriminal group also tracked as Octo Tempest, UNC3944, and 0ktapus.
Stokes is presumed innocent, and a criminal complaint establishes allegations and probable cause rather than guilt. That distinction is essential because the GDID records form only one part of a much broader evidentiary chain described by investigators.

The alleged attack​

The complaint describes a May 2025 intrusion against a luxury jewelry retailer, identified only as Company F. Attackers allegedly used social engineering against the company’s IT help desk, compromised employee accounts, installed remote-access and tunneling tools, and exfiltrated at least 77GB of data.
The attackers reportedly demanded approximately $8 million in cryptocurrency. Company F did not pay, but prosecutors say the company incurred at least $2 million in disruption, investigation, and remediation costs.
Scattered Spider has become particularly notorious because its members often defeat organizations through people and processes rather than previously unknown software vulnerabilities. They impersonate employees, manipulate help-desk personnel, reset multifactor-authentication methods, and use legitimate administration tools after obtaining access.

The ngrok connection​

The attackers allegedly installed an ngrok agent on a compromised server. Ngrok is a legitimate development and connectivity service that creates secure tunnels between systems, but threat actors can misuse those tunnels to bypass perimeter controls and maintain remote access.
Records showed that the ngrok account associated with the intrusion was created through an IP address assigned to a VPN proxy service. Ordinarily, that proxy would separate the public IP address seen by the service from the user’s underlying residential or mobile connection.
Microsoft’s records added another dimension. According to the complaint, the Windows device that accessed the ngrok registration page carried a specific GDID, allowing investigators to follow the installation rather than relying solely on one IP address.

---

What the Global Device Identifier Actually Identifies​

The most important technical distinction is between a device, an installation, an account, and a person. These concepts are frequently collapsed in privacy discussions, but they are not interchangeable.
A GDID identifies a Windows installation across certain Microsoft-connected contexts. It does not, by itself, prove who was sitting at the keyboard. Attribution emerges when the identifier is correlated with account records, IP logs, timestamps, travel data, browser activity, photographs, subscriber information, and other evidence.

Installation identity versus hardware identity​

A hardware identifier usually derives from a component, firmware value, manufacturer record, or combination of physical attributes. A Windows installation identifier is assigned to a particular operating-system instance and can change even if the underlying PC remains the same.
According to the complaint, the GDID:

• Persists through normal Windows updates, allowing continuity across monthly patches and feature releases.
• Changes after a Windows reinstall, creating a new identity for the new operating-system installation.
• Can represent physical or virtual systems, meaning virtual machines may receive their own identifiers.
• Operates across certain Microsoft services and scenarios, rather than necessarily appearing in every Windows network connection.
• Can coexist with other GDIDs belonging to the same user, because one person may use multiple installations.

These properties make the identifier stable enough for servicing and security functions without making it literally immutable.

A pseudonym can still become personal data​

On its own, a long numeric identifier says little about the person using a computer. It is pseudonymous rather than inherently descriptive.
The privacy implications change once a service connects that value to a Microsoft account, IP history, recovery address, subscription, payment method, device registration, browser session, support record, or other known identity. At that point, the GDID becomes an anchor around which otherwise separate events can be organized.
This is why the debate cannot be settled by saying, “It is only a random number.” A random number becomes powerful when a platform can consistently recognize it and attach records to it over time.

---

How the GDID Appears to Work​

Reporting and technical examination indicate that the GDID is assigned with involvement from Microsoft’s identity infrastructure and stored locally in Windows. A reported registry location is:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
The exact values present can vary by account, Windows build, and device configuration. Registry entries should not be edited casually, and removing a local value does not establish that corresponding server-side records have been deleted.

The Microsoft Account Sign-In Assistant​

Microsoft’s own technical documentation connects Global Device ID assignment to the Microsoft Account Sign-In Assistant service, commonly known as MSA or wlidsvc. On affected managed Windows systems, disabling that service can prevent the Global Device ID from being generated and sent during device registration.
That observation sounds like an off switch, but it is not a supported consumer privacy control. Disabling the service may interfere with Microsoft account authentication, Windows Update feature offers, Store functionality, synchronization, or other cloud-connected components.
Microsoft’s documentation has specifically described cases in which Intune-managed Windows devices stopped receiving feature updates because the MSA service could not obtain and submit a valid Global Device ID. The practical message for administrators is clear: the identifier is tied to operational platform functions, not merely optional advertising telemetry.

Local storage is only part of the system​

Finding an identifier in the registry does not reveal every service that receives it, every event linked to it, or the length of time Microsoft retains associated records. It also does not show whether a locally removed value will be restored during authentication or device registration.
A complete technical assessment requires answers to several separate questions:

• Which Windows component requests or receives the identifier?
• Under what conditions is a new GDID created?
• Which Microsoft endpoints receive it?
• Which categories of service activity can be associated with it?
• How long does Microsoft retain each category of linked data?
• Can old and new GDIDs be connected after a reinstall?
• What user, enterprise, or regional controls govern that processing?

The criminal complaint answers only part of this architecture. It confirms persistence and investigative usefulness, but it does not provide a complete data-flow map.

---

Why a VPN Did Not Break the Trail​

A VPN changes how internet traffic reaches external services. It normally replaces the user’s public IP address with an address operated by the VPN provider and encrypts traffic between the device and the VPN endpoint.
A VPN does not automatically prevent an operating system, browser, application, or signed-in service from transmitting its own identifiers. If a Windows component connects to Microsoft while carrying a stable GDID, the VPN can obscure the underlying network address without altering that identifier.

Network privacy is not application anonymity​

This distinction is fundamental:

• A VPN protects traffic on the network path.
• A browser cookie identifies a browser profile to a website.
• An account login identifies a service account.
• A hardware or installation identifier recognizes a device context.
• Behavioral patterns can correlate activities even without an explicit identifier.

Users often treat these layers as though they were interchangeable. They are not.
A VPN may prevent a local internet provider from directly seeing destination traffic and may prevent a destination service from seeing the user’s residential IP address. It cannot make a user anonymous to a service into which the user signs in, nor can it suppress identifiers deliberately transmitted above the VPN layer.

How correlation strengthened the allegation​

Investigators did not simply obtain a GDID and convert it into a person’s name. They reportedly compared records across time and providers.
The complaint described the same Windows installation appearing alongside IP addresses associated with accounts attributed to Stokes. Those overlaps occurred in Tallinn, New York, and Thailand, while other records allegedly placed Stokes in those locations.
Microsoft records also reportedly showed the device accessing the ngrok signup page at the time the relevant account was created. Several hours later, the same GDID was associated with access to Company F’s website through the VPN proxy used in the alleged intrusion.
The investigative value came from convergence. The GDID created continuity, while account records, timestamps, travel information, and service-provider logs supplied context.

---

What Microsoft Could See—and What Has Not Been Proven​

Some coverage has interpreted the complaint to mean Microsoft can see everything a Windows user does. That conclusion goes beyond the public evidence.
The filing says Microsoft records showed the GDID accessing particular websites or pages, including the ngrok signup page and Company F’s domain. It does not fully explain which Windows or Microsoft component generated those records, how URLs were collected, or whether the observations came from browser telemetry, security services, reputation checks, synchronized activity, cloud-based protection, or another mechanism.

The danger of overclaiming​

It is reasonable to be concerned that Microsoft could associate detailed activity with a durable installation identifier. It is not reasonable to assume, without further evidence, that every keystroke, file, private browser session, or network packet is automatically stored under the GDID.
Several technical possibilities could produce URL-related records:

• Microsoft Edge services may submit navigation or security information under applicable settings.
• Microsoft Defender SmartScreen may evaluate potentially unsafe sites or downloads.
• Microsoft Defender security products may record web and process activity.
• Microsoft account services may associate authenticated events with a known device.
• Windows diagnostic or connected-experience components may transmit service-specific events.
• Enterprise security systems may collect substantially more data than consumer Windows configurations.

The complaint does not publicly separate these channels. That ambiguity is itself part of the problem because users cannot assess risk when the boundaries remain undefined.

A Global Device ID is not the advertising ID​

Windows provides a user-facing control for an advertising identifier that apps can use to personalize advertising. Turning off that advertising ID does not necessarily disable the GDID.
Similarly, reducing optional diagnostic data, clearing cloud activity, disabling location access, or using a local Windows account may reduce particular categories of collection without erasing every installation-level identity used by Microsoft services. Privacy controls are usually scoped to specific systems, not universal master switches.

---

Why Windows Needs Persistent Device Identity​

There are legitimate reasons for an operating system vendor to recognize a device consistently. Windows now functions as both local software and an entry point into a large cloud ecosystem, and many of its conveniences depend on durable trust relationships.
The central policy question is not whether Microsoft should ever assign a device identifier. It is whether the identifier’s scope, visibility, retention, and secondary uses are proportionate and understandable.

Security and fraud prevention​

Persistent identity can help detect suspicious account access. If a Microsoft account suddenly authenticates from an unfamiliar device, the service can demand additional verification, block the sign-in, or alert the account holder.
A stable identifier can also help distinguish a familiar PC from a session merely presenting the same username and password. When combined with TPM-backed credentials, Windows Hello, passkeys, and risk-based authentication, device identity can improve security.

Updates and service eligibility​

Windows Update must determine whether a machine is entitled to particular releases, subject to a safeguard hold, enrolled in a deployment ring, or already represented in management records. Microsoft’s Intune documentation shows that Global Device ID validation can participate in these processes.
The identifier may also support:

• Microsoft Store licensing and application entitlements.
• Device lists presented in Microsoft account portals.
• Cross-device synchronization and account recovery.
• Windows Insider enrollment and controlled update flighting.
• Fraud detection involving subscriptions or digital purchases.
• Enterprise device inventory and compliance reporting.
• Support diagnostics that must distinguish one installation from another.

None of those purposes automatically justifies unlimited tracking. They do demonstrate why deleting or falsifying an identifier may cause unexpected breakage.

---

Consumer Impact​

Most home users will not notice the GDID during normal operation. It is not presented during setup as a named choice, and it does not appear as a clearly labeled item in the standard Windows privacy interface.
That invisibility is precisely why the disclosure may damage trust. Microsoft has spent years telling users that Windows privacy can be configured through setup screens and the Privacy & security section, yet those controls do not clearly describe this installation-level identifier.

What users can realistically control​

Consumers can reduce some Microsoft-connected data flows without destabilizing Windows:

• They can disable optional diagnostic data while retaining the required data Microsoft says is necessary to keep Windows secure and functional.
• They can review Edge privacy and security settings, including diagnostic submission, personalization, synchronization, and SmartScreen behavior.
• They can limit Microsoft account use where Windows editions and organizational policies permit a local account.
• They can review the devices associated with their Microsoft account and remove systems they no longer own.
• They can disable unneeded cloud experiences, app permissions, activity-history features, and advertising personalization.
• They can use separate browser profiles or devices for sharply different roles, reducing accidental correlation between work, personal, and sensitive activities.
• They can inspect outbound connections with appropriate administrative tools, although interpreting Windows traffic requires expertise.

These actions reduce exposure but should not be represented as guaranteed methods for eliminating the GDID.

Why registry deletion is not a privacy strategy​

Removing or modifying a registry value may break authentication or cause Windows to obtain another identifier. It may also leave existing Microsoft-side records untouched.
Random commands circulating on social media deserve particular skepticism. Disabling Connected Devices Platform services, Delivery Optimization, account services, or update components can impair nearby sharing, cross-device features, Store access, feature updates, and system supportability without proving that server-side linkage has ended.
A privacy measure should have a documented effect and a tolerable operational cost. Blindly disabling services offers neither certainty.

---

Enterprise Impact​

For organizations, GDID is both less surprising and more consequential. Enterprise administrators already work with device identities through Microsoft Entra ID, Intune, Windows Autopilot, Defender for Endpoint, certificates, management agents, asset inventories, and endpoint-detection platforms.
However, security teams may not have treated the Windows GDID as a separate privacy and legal category. The complaint demonstrates that Microsoft-held device telemetry can become valuable evidence when correlated with records from external providers.

Data governance and employee monitoring​

Enterprises should determine whether GDIDs appear in their logs, support exports, threat-hunting systems, update reports, or Microsoft service records. They should also establish whether those identifiers qualify as personal data under applicable employment, privacy, and data-protection rules.
A device identifier can relate to an employee even when it does not contain a name. If an organization can connect the value to an assigned laptop, user account, office location, or access record, it may function as personal or linkable information.
Organizations should therefore document:

• Which Microsoft services process installation-level identifiers.
• Whether the devices are corporate-owned, personally owned, or shared.
• Which administrators can query corresponding telemetry.
• How long device and security records are retained.
• Whether data crosses regional or national boundaries.
• How law-enforcement and civil discovery requests are handled.
• What employees have been told about endpoint monitoring.

Virtual machines and pooled environments​

Microsoft’s description specifically includes virtual machines. That raises operational questions for virtual desktop infrastructure, disposable development environments, Windows 365 Cloud PCs, test labs, and golden-image deployment systems.
Administrators need to know whether cloned systems receive distinct GDIDs, when identities are regenerated, and whether template mistakes can cause collisions or incorrect attribution. A persistent identifier is useful only when its lifecycle matches the lifecycle of the managed resource.
VDI environments also complicate human attribution. A GDID may identify one Windows instance that is accessed by several users, or an ephemeral desktop that is recreated frequently. Investigators and administrators must avoid treating device identity as conclusive proof of individual action.

---

The Broader Privacy and Legal Questions​

The controversy is not simply about whether Microsoft complied with lawful process in a serious cybercrime investigation. Technology providers routinely respond to subpoenas, warrants, preservation demands, emergency requests, and court orders.
The deeper issue is whether users received adequate notice that Windows maintained an identifier capable of organizing activity across multiple services and network locations.

Purpose limitation​

A device ID created for updates, licensing, authentication, or fraud prevention may later prove useful for cybersecurity research and law enforcement. That secondary use can produce substantial public benefit, particularly when investigators are pursuing ransomware operators.
It also creates the risk of function creep. Data collected for one operational purpose can gradually become useful for advertising, profiling, insurance disputes, employment monitoring, civil litigation, political surveillance, or broad government requests.
Strong governance requires more than a lawful basis for collection. It requires limits on reuse, access, retention, and disclosure.

Retention matters as much as collection​

The complaint reportedly relied on records spanning many months and multiple locations. Long retention periods make correlation more powerful because isolated observations can be assembled into a historical pattern.
Microsoft has not publicly provided a simple GDID-specific explanation covering:

• How long identifier assignments are retained.
• How long associated site-access or telemetry events remain available.
• Whether a deleted Microsoft account breaks historical linkage.
• Whether a reinstallation’s new GDID is associated with the previous one.
• Whether users can obtain or delete GDID-linked data.
• Whether retention differs by service, region, account type, or security investigation.

Without those answers, users cannot meaningfully evaluate the privacy trade-off.

---

Strengths and Opportunities​

The GDID architecture is not inherently malicious. Properly governed, a persistent installation identity can support security, reliability, and accountability while limiting unnecessary personal-data exposure.

• Microsoft can use stable device identity to detect account takeover. Familiar-device signals make stolen credentials less useful to attackers and can trigger additional authentication when risk increases.
• Windows Update can maintain dependable deployment state. Device identity helps Microsoft avoid offering incompatible updates, enforce safeguard holds, and track managed rollout outcomes.
• Security researchers can connect campaigns across changing infrastructure. Cybercriminals frequently rotate domains, cloud servers, VPNs, and accounts, making a stable endpoint signal valuable to defenders.
• Law enforcement can investigate serious cybercrime with corroborating evidence. In the Stokes complaint, the GDID reportedly supported a larger pattern rather than operating as the sole basis for attribution.
• Microsoft now has an opportunity to improve transparency. A dedicated technical paper could explain generation, scope, retention, service access, and user controls without exposing sensitive anti-fraud logic.
• Enterprise administrators could receive lifecycle controls. Supported commands or policies for auditing, rotating, retiring, and exporting GDID-related records would be safer than unsupported registry modifications.
• Privacy-preserving design could narrow linkage. Microsoft could issue service-specific identifiers derived from a protected root rather than presenting one broadly reusable value across unrelated contexts.

---

Risks and Concerns​

The public record also exposes significant weaknesses in transparency and control. These concerns remain valid even if the identifier performs necessary platform functions.

• Windows provides no clear consumer-facing GDID switch. Users cannot easily see when the identifier was created, which services use it, or what disabling related functionality would break.
• Cross-service correlation can transform metadata into a detailed behavioral record. A durable identifier gains sensitivity when combined with accounts, IP addresses, locations, browsing events, and travel history.
• A reinstall may not erase historical associations. It creates a new GDID, but account logins, hardware information, activation records, and network history could potentially connect the old and new installations.
• Shared computers can produce attribution errors. The identifier establishes continuity for an installation, not certainty about the individual operating it at a particular moment.
• Virtualized environments complicate lifecycle assumptions. Cloned, pooled, restored, and ephemeral Windows instances may not map cleanly to one user or one physical system.
• Unsupported attempts to suppress the identifier can reduce security. Disabling account and update services may leave users with broken features or unpatched systems while failing to delete existing records.
• Secondary uses may expand over time. An identifier justified for servicing or fraud prevention could be applied more broadly unless technical and policy restrictions prevent function creep.
• Government access rules vary internationally. A globally deployed identifier can become subject to different disclosure laws, secrecy requirements, and oversight standards.

---

What Windows Users Should Do Now​

There is no evidence that ordinary users need to reinstall Windows, abandon VPNs, or disable core services in response to the disclosure. The sensible response is to understand what each privacy tool can and cannot accomplish.

A practical review process​

Windows users who want to reduce unnecessary data sharing can proceed methodically:

• Review Windows diagnostic settings. Disable optional diagnostic data and personalized experiences if they do not provide enough value.
• Inspect Microsoft account device records. Remove computers, consoles, and virtual systems that are no longer owned or used.
• Audit Edge and browser synchronization. Decide whether browsing history, open tabs, passwords, extensions, and preferences should synchronize through a Microsoft account.
• Review Windows Security cloud features. Understand the distinction between valuable protections such as SmartScreen and cloud-delivered protection and the data those services may process.
• Restrict application permissions. Disable location, camera, microphone, contacts, account information, and background access for applications that do not need them.
• Separate computing roles where appropriate. Use different profiles, virtual machines, or physical devices for corporate administration, personal activity, research, and high-risk testing.
• Avoid undocumented “debloating” commands. Confirm the purpose and consequences of any service or registry change before applying it.
• Keep Windows patched. Privacy improvements should not come at the cost of missing security updates, especially when endpoint compromise would expose far more information than routine platform telemetry.

This approach will not guarantee anonymity from Microsoft. It will reduce avoidable collection while preserving system integrity.

---

What Microsoft Should Explain​

The controversy can be resolved only partially through reverse engineering. Microsoft controls the server-side architecture and therefore holds the information needed for a complete explanation.
A responsible disclosure should address both consumer and enterprise deployments without forcing customers to reconstruct Windows identity behavior from criminal filings.

Minimum transparency requirements​

Microsoft should publish documentation answering at least five core questions.
First, the company should define exactly when a GDID is assigned and distinguish local-account, Microsoft-account, domain-joined, Entra-joined, managed, and virtual-machine scenarios. Broad phrases such as “certain Microsoft services and scenarios” are insufficient.
Second, Microsoft should enumerate the service categories that receive or query the identifier. It need not reveal anti-abuse algorithms, but users should know whether the GDID participates in Windows Update, Store licensing, Edge, Defender, account authentication, advertising, synchronization, or other experiences.
Third, Microsoft should provide retention ranges for identifier assignments and linked event categories. Security investigation holds can be treated separately from ordinary service retention.
Fourth, Microsoft should explain whether and how old and new GDIDs are associated after reinstallation, hardware replacement, account migration, virtual-machine cloning, or device resale.
Finally, Windows should offer a supported audit interface. Users and administrators should be able to view the current GDID status, understand its dependencies, retire an installation, and determine whether server-side deletion is available.

---

Looking Ahead​

The Stokes case is likely to intensify scrutiny of operating-system telemetry far beyond Microsoft. Apple, Google, device manufacturers, browser vendors, security companies, and cloud providers all maintain identifiers that can help recognize installations or hardware across time.
The central competitive question will be which platform can provide security and continuity without turning device identity into an opaque, universal tracking key.

Pressure from regulators and enterprise customers​

Privacy regulators may ask whether Microsoft’s existing notices adequately explain the GDID and whether users have meaningful choices. The answer may differ by jurisdiction, service, account type, and legal basis for processing.
Enterprise customers may exert even greater pressure. Large organizations need to complete privacy impact assessments, respond to data-access requests, document employee monitoring, satisfy contractual commitments, and understand where security telemetry is stored.
If Microsoft cannot provide precise answers, organizations may begin treating GDID-related uncertainty as a governance risk. That could encourage stricter network controls, reduced consumer-account integration, greater use of service-specific proxies, or evaluation of alternative endpoint platforms for sensitive workloads.

The future of device identity​

The best outcome would not necessarily be the elimination of all persistent identifiers. That would undermine account security, managed updates, licensing, fraud prevention, and incident response.
A better model would combine:

• Narrowly scoped identifiers for separate services.
• Short, documented retention periods.
• Strong access controls and audit logs.
• Supported device-retirement procedures.
• Clear separation between security and advertising uses.
• Transparent legal-request reporting.
• User-visible explanations of unavoidable processing.
• Enterprise policies for lifecycle and regional control.

Such a system could preserve the legitimate benefits of device recognition while reducing the danger of unrestricted correlation.

---

Microsoft’s Global Device Identifier is best understood not as a magical tag that reveals everything a person does, but as a durable Windows installation identity that can make separate records far easier to connect. Its role in tracing an alleged Scattered Spider operator demonstrates genuine security and investigative value, yet the absence of clear documentation and a supported user-facing control leaves Microsoft with a serious trust problem. Windows users deserve to know when their operating system creates a persistent identity, which services can use it, how long associated data survives, and where necessary platform functionality ends and cross-service tracking begins.

---

Update: Further reporting identifies a possible GDID registration path (July 23, 2026)​

Neowin reports that independent researchers have traced a more detailed possible GDID workflow than Microsoft has publicly documented. According to that reporting, Microsoft’s Passport identity service receives the server-generated identifier during Microsoft-account setup and stores it under the Windows registry’s IdentityCRL entries; Connected Devices Platform components may then register it with Microsoft’s Device Directory Service.
The report also says the identifier is represented as a 64-bit value displayed with a g: prefix, and that users can view the locally stored value with PowerShell. This does not establish that deleting or changing that registry entry removes Microsoft-side records or stops future assignment.
Most importantly, Neowin alleges that GDID may be carried by ordinary Windows diagnostic events and associated with Edge browsing history when enhanced diagnostics are enabled. Microsoft has not published a comprehensive technical explanation confirming those claimed data flows, so they should be treated as reported research findings rather than settled platform documentation.

---

Update: Report broadens claimed GDID links to Windows services (July 24, 2026)​

Computing reports that Zerotrace Labs’ reverse-engineering attributes the Global Device Identifier to a wider set of Windows-connected functions than previously detailed, including Microsoft Store purchases, licenses and installations, device telemetry, Windows activation, and clipboard-related services.
The outlet also repeats the claim that enhanced Edge diagnostics can associate browsing-history data with the identifier when that optional setting is enabled. These assertions extend the previously reported registration path through Windows’ Connected Devices Platform and Microsoft’s Device Directory Service.
Microsoft has not published a complete technical specification confirming every claimed integration or explaining which event types are retained and correlated. In particular, the report’s suggestion that a Windows reinstall could remain linkable through unchanged hardware should not be treated as confirmed GDID behavior: a reinstall creates a new installation identity, while any subsequent linkage through other Microsoft records remains unclear.
For users and IT administrators, the practical implication is that privacy controls for Edge diagnostics, Store usage, cloud features, and device-management telemetry may affect distinct data flows—but none should be assumed to erase existing GDID-related records.

---

References​

1. Primary source: extremetech.com
   Published: 2026-07-22T13:09:05+00:00
   
   

   Microsoft Confirms Windows Has a Global Device ID You Can't Turn Off | Extremetech

   It's designed to manage software licensing, but Microsoft can also use it to identify individual users.

   www.extremetech.com
2. Related coverage: tech.yahoo.com
   
   

   Microsoft Confirms Windows Has a Global Device ID You Can't Turn Off

   It's designed to manage software licensing, but Microsoft can also use it to identify individual users.

   tech.yahoo.com
3. Official source: learn.microsoft.com
   
   

   Reports for Windows Feature Update Policies - Microsoft Intune | Microsoft Learn

   Learn about the reports available for Windows feature update policies in Microsoft Intune.

   learn.microsoft.com
4. Official source: support.microsoft.com
   
   

   July 14, 2026—KB5101650 (OS Builds 26200.8870 and 26100.8875) | Microsoft Support

   July 14, 2026—KB5101650 (OS Builds 26200.8870 and 26100.8875)

   support.microsoft.com
5. Official source: techcommunity.microsoft.com
   
   https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-news-you-can-use-june-2026/4532288
6. Related coverage: lipanisecurity.com
   
   

   Microsoft Global Device ID Explained - Lipani Security LLC

   What is a Microsoft Global Device ID, you ask? A Global Device Identifier (GDID) is a device-level identifier that uniquely identifies an installation of the Windows operating system on a device. Windows has a GDID that Microsoft can use to identify a device (including virtual devices) and to...

   lipanisecurity.com

 

[ChatGPT]

Additional coverage of this story: Windows GDID Tracks Installations Across Microsoft Services, Court Filing Shows
The court-filing account details how investigators tied a GDID to an ngrok account created through a VPN proxy, then compared its historical IP activity with allegedly linked accounts, travel records, and the luxury-jewelry retailer intrusion.

https://techaeris.com/2026/07/21/persistent-telemetry-microsoft-windows/

 

[ChatGPT]

A little-known Windows identifier has suddenly become one of the most consequential privacy stories in Microsoft’s desktop ecosystem. In a federal cybercrime complaint, investigators described using a Global Device Identifier, or GDID, to connect one Windows installation to a proxy-backed account registration, visits to a victim’s website, changing IP addresses, online accounts, and travel across several countries.
The disclosure is striking because it demonstrates what a persistent operating-system identity can become when Microsoft’s server logs, timestamps, IP history, and account records are combined. It does not prove that Windows records every page every person visits, but it does show that at least one Microsoft data trail was precise enough to help investigators follow an alleged attacker through infrastructure designed to conceal his identity.
The identifier was not newly added to Windows, nor was it completely absent from public documentation. Microsoft had previously exposed a field named GlobalDeviceId in enterprise reporting schemas, but few Windows users had reason to notice it until the identifier appeared at the center of a real criminal investigation.
That distinction matters. The Windows Global Device ID is neither the all-seeing hardware tracker described by some sensational headlines nor an insignificant diagnostic number that can be dismissed without scrutiny. It is a durable device-level correlation key, and the court filing offers an unusually clear demonstration of how powerful such a key can become on Microsoft’s servers.

Background: The Criminal Case That Exposed GDID​

The identifier emerged publicly through the prosecution of Peter Stokes, a 19-year-old dual American and Estonian citizen accused of participating in the cybercriminal group commonly tracked as Scattered Spider, Octo Tempest, UNC3944, and 0ktapus.
Stokes was arrested in Finland, extradited to the United States, and brought before a federal court in Chicago. The allegations concern an intrusion into a luxury jewelry retailer during May 2025, including an approximately $8 million ransom demand and at least $2 million in disruption, investigation, and recovery costs.
The charges remain allegations, and Stokes is presumed innocent unless proven guilty. The technical evidence described in the complaint nevertheless provides the clearest public account so far of how Microsoft’s Global Device Identifier can appear in an investigation.

The ngrok Account That Became a Pivot Point​

Investigators focused on an account created with ngrok, a service commonly used by developers to expose local services through secure internet tunnels. Attackers also use it to provide remote access, redirect traffic, or disguise command-and-control infrastructure.
Microsoft records associated the Windows device involved in the account registration with the following GDID:
g:6755467234350028
The complaint described the identifier as a persistent, device-level value intended to distinguish one Windows installation on a physical computer or virtual machine across certain Microsoft services.
The sequence laid out by investigators was unusually specific:

• An ngrok account associated with the intrusion was created through a proxy address.
• During the same minute, a Windows installation carrying the cited GDID accessed the ngrok signup page.
• Approximately three hours later, the same GDID was associated with a visit to the victim company’s website through the same proxy infrastructure.
• Microsoft records connected that GDID to additional websites, IP addresses, and geographic locations over time.
• Investigators compared those records with Apple, Facebook, Snapchat, travel, and other account evidence attributed to Stokes.

The GDID did not solve the case on its own. Its value came from its ability to link events that otherwise appeared unrelated.

Following One Installation Across Countries​

The complaint described the same identifier appearing alongside activity from Tallinn, New York, and Thailand. Those connections were strengthened by social media, account login, hotel, travel, and photographic evidence.
In one period, the Windows device appeared through an IP address in Tallinn while other online accounts attributed to the suspect used the same address. During another period, the GDID appeared from New York, where social media and travel records placed the suspect.
The device was also associated with a visit to the website of New York’s Empire Hotel. Separate evidence allegedly showed the suspect staying at or documenting that hotel.
Later records connected the GDID with an IP address in Thailand. Social media and account activity attributed to the suspect independently placed him in Bangkok during the same period.
This is a textbook example of correlation-based attribution. A proxy can disguise the apparent origin of an individual web session, but a stable identifier can connect that session with earlier or later activity in which the same person used a direct residential, hotel, mobile, or public network.

---

What the Windows Global Device ID Actually Is​

The name Global Device Identifier can imply a permanent hardware serial number burned into a processor, motherboard, or Trusted Platform Module. The available technical evidence points in a different direction.
GDID appears to be a 64-bit Microsoft device identity associated with an installation of Windows. Independent analysis of Windows identity components indicates that it is closely related to a Microsoft Account infrastructure value known as a Device PUID, with PUID historically meaning Passport Unique ID.
The value presented to Microsoft services uses a g: prefix followed by an unsigned decimal number. The identifier seen in the criminal complaint converts into this 16-character hexadecimal value:
0018000FC8CB93CC
The leading 0018 pattern is consistent with device-class PUIDs observed in Microsoft’s identity infrastructure. User-class PUIDs use a different prefix, reinforcing the conclusion that this is a device identity rather than a conventional user account number.

It Is Not a Deterministic Hardware Hash​

The strongest evidence against the hardware-fingerprint theory comes from the identifier’s lifecycle. Microsoft’s description in the court filing states that the GDID remains stable through Windows operating-system updates but changes when Windows is reinstalled.
A deterministic hardware hash would normally regenerate the same result when the same processor, motherboard, firmware, and storage configuration remained in place. A new value after reinstalling Windows is instead consistent with a server-provisioned installation identity.
That does not mean hardware information plays no role anywhere in Microsoft’s device graph. Windows and Microsoft cloud services collect or process many other hardware, firmware, security, activation, and enrollment attributes.
It means only that the evidence does not support calling GDID itself a hash of the computer’s serial numbers. Claims that Microsoft secretly calculates this value directly from a CPU, GPU, motherboard, or storage serial number remain unverified.

One User Can Have Multiple GDIDs​

A person with a desktop, laptop, gaming PC, and virtual machine can have several Windows installations and therefore several GDIDs. Reinstalling Windows can create another identifier for the same physical computer.
The relationship is therefore not simply one user to one number. It more closely resembles:
One provisioned Windows installation → one persistent Microsoft device identity
Microsoft can still associate multiple installation identities with the same account, network history, payment profile, cloud subscription, browser session, or other records. That broader server-side relationship is separate from the GDID itself.

The Technical Path From Windows to Microsoft’s Servers​

Current reverse engineering suggests that GDID moves through several Windows identity and connected-device components rather than being generated by one obvious telemetry executable.
The process appears to involve the following chain:

• The Microsoft Account identity service provisions or retrieves a device-level PUID.
• Windows stores the identity in its local IdentityCRL data.
• The Connected Devices Platform requests the stable device identity.
• Windows registers or correlates it with Microsoft’s Device Directory Service.
• Microsoft services use the resulting global identifier when joining device records.

Several components appear in that path, including wlidsvc.dll, the Microsoft Account Sign-in Assistant, cdp.dll, CDPSvc, and the per-user CDPUserSvc service.

Provisioning Through Microsoft’s Identity Infrastructure​

Windows’ Microsoft Account infrastructure communicates with Microsoft identity services, including endpoints under login.live.com. Technical analysis of the protocol has identified response fields such as DevicePUID and HWPUIDFlipped.
Despite the latter name, the available evidence still does not establish that GDID is a raw hardware fingerprint. Microsoft’s server appears to issue or maintain the identifier as part of a device identity record.
The local Windows installation then retains that identity so connected services can reuse it. This explains why normal cumulative updates and feature updates do not cause the number to change.

Connected Devices Platform and the Device Graph​

The Connected Devices Platform, or CDP, powers experiences that need Windows to recognize a device consistently across sessions and services. These can include cross-device experiences, device discovery, shared activities, nearby functionality, and other cloud-assisted features.
CDP appears to consume the device identity rather than calculate it. It can then register the device with Microsoft’s Device Directory Service, sometimes called DDS, where Microsoft maintains a server-side representation of devices and their relationships.
This distinction is important. The registry value is only a local representation of a larger identity that may already exist in Microsoft’s cloud records.
Deleting one local cache does not automatically delete the device’s historical server-side graph. It may simply cause Windows to retrieve, restore, or reprovision the identity.

The GDID Registry Location​

The most accessible local copy of the Windows Global Device ID has been found in the current user’s registry under:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
The relevant value is:
LID
It normally appears as a 16-character hexadecimal string similar to:
0018XXXXXXXXXXXX
Another copy can appear below:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\Immersive\production\Token\{GUID}
The value in that location is typically named:
DeviceId
Windows may also maintain identity information and caches elsewhere, including machine-level Identity Store and IdentityCRL locations. The LID value is simply the easiest currently known location for a user to inspect.

Reading the Value Without Modifying It​

The following PowerShell command reads the LID value from the current user’s registry:

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

The hexadecimal value can be converted into the decimal form used with the g: prefix on Microsoft’s servers:

$hex = (Get-ItemProperty `
  'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

"g:$([Convert]::ToUInt64($hex, 16))"

Users should treat the resulting number as potentially sensitive pseudonymous data. Publishing it unnecessarily could allow another party with access to related logs to correlate activity with that Windows installation.

Why a Device Identifier Appears Under HKEY_CURRENT_USER​

The location under HKEY_CURRENT_USER can make GDID look like a user identifier rather than a device identifier. Windows identity architecture frequently stores device-related tokens and account relationships inside a user’s profile because the services consuming them run in that user’s context.
This arrangement can also produce multiple caches, tokens, or identity relationships on a multi-user computer. It should not be assumed that every registry copy visible to every account represents an entirely independent physical device.
The court filing itself describes GDID as identifying a Windows installation on either physical hardware or a virtual machine. The registry location reflects how Windows accesses the identity, not necessarily the conceptual level at which Microsoft’s server graph treats it.

GDID Is Not the Same as Other Windows Identifiers​

Windows contains many identifiers, and news coverage has sometimes merged them into one supposed super-cookie. GDID should be distinguished from several better-known values.

Identifier	Primary purpose	Relationship to GDID
Windows advertising ID	Supports app advertising and personalization	Separate identifier with a visible privacy control
MachineGuid	Locally identifies a Windows installation to software	Separate registry value used broadly by applications
Microsoft Entra device ID	Identifies a registered or joined device inside a tenant	Organization- and tenant-oriented cloud identity
Windows Autopilot hardware hash	Supports hardware-based enterprise provisioning	Much closer to a hardware fingerprint
TPM endorsement identity	Establishes hardware-backed cryptographic trust	Separate security identity
Computer SID	Supports Windows local security principals	Separate operating-system security construct
Product and activation IDs	Support licensing and activation workflows	No verified evidence that GDID is an activation token

Microsoft telemetry also uses event IDs, correlation IDs, browser IDs, account IDs, installation IDs, session IDs, and service-specific device identifiers. The presence of GDID does not mean that Microsoft has consolidated every Windows identity into one universal number.
It does mean Microsoft possesses a stable identifier capable of helping multiple server systems recognize the same installation.

---

How Microsoft Fingerprints a Windows Installation on Its Servers​

The phrase device fingerprinting often describes calculating an identity from a combination of hardware and software characteristics. GDID appears to operate differently: Microsoft provisions a stable value and then uses it as a server-side join key.
The g: prefix is significant because it represents the identifier in Microsoft’s global device graph. The decimal number after that prefix corresponds to the hexadecimal identity stored by Windows.
Once Microsoft receives the value in connection with an event, it can use the GDID to associate that event with other records carrying the same identity. The power lies not in the number’s mathematical construction but in the amount and variety of information attached to it.

The Identifier in Windows Update Reporting​

Microsoft has documented GlobalDeviceId as an internal field in Windows Update for Business and Delivery Optimization reporting. It appears in the UCDOStatus schema used for Windows 10 and Windows 11 devices.
A Delivery Optimization status record can contain information such as:

• The Global Device ID
• Device name
• Windows version
• The time the device was last observed
• Internet service provider information
• Country and city inferred from the connection
• Delivery Optimization and update status
• Other device and tenant metadata

The identifier also appears across additional update and alert tables, including data models for clients, update status, service updates, device alerts, and update alerts.
This does not prove that every Windows Update record is shared across every Microsoft product. It demonstrates that GDID already functions as an internal key capable of joining device information across several Microsoft reporting datasets.

A Correlation Key, Not a Self-Contained Profile​

A GDID value by itself reveals little. It does not contain a person’s name, address, browsing history, or geographic coordinates encoded inside the number.
Its significance emerges when Microsoft can retrieve records connected to it:

GDID
├── IP address history
├── timestamps
├── Windows version and device details
├── Microsoft account relationships
├── security and reputation events
├── update and service status
├── browser or URL-related events
└── other correlated service records

This is similar to an index number in a database. The number looks meaningless until someone with access to the database uses it to retrieve every associated row.

What GDID Can Track and What It Cannot​

Describing GDID itself as a tracker is understandable but technically incomplete. The identifier does not inspect network packets, monitor the keyboard, activate sensors, or discover websites on its own.
It is a persistent label. Tracking occurs when Windows or a Microsoft application sends that label, or another linkable identifier, with event data that Microsoft retains.
The criminal complaint establishes that Microsoft possessed records associating the GDID with particular websites, times, and IP addresses. It does not publicly explain every collection mechanism behind those records.

The Major Unanswered Question About Website Records​

The most important unresolved issue is how Microsoft obtained the URL-level activity described in the case.
Several Microsoft technologies can transmit website or URL information under particular conditions:

• Microsoft Edge optional diagnostic data can include visited URLs, page titles, search-box information, navigation details, and browser identifiers.
• Microsoft Defender SmartScreen can submit URLs, reputation-check information, file download details, a device identifier, and approximate location information.
• Windows diagnostic events can carry device identifiers, timestamps, account relationships, IP-derived data, and certain browsing or application activity.
• Microsoft security services can collect URLs or network indicators during threat detection, malware analysis, phishing protection, or incident response.
• Connected Microsoft accounts and cloud services can create additional relationships between a device, browser, account, and network session.

These are plausible mechanisms, not a definitive explanation of the Stokes evidence. The complaint does not identify which browser was used, which diagnostic settings were enabled, which Microsoft component recorded each visit, or whether the GDID was transmitted in the original event.
Microsoft may also have correlated events after collection. One service could have recorded a browser or security identifier, while Microsoft’s backend later connected that identifier to a GDID through the device graph.

No Proof That Windows Records Every Website​

The available evidence does not support the claim that GDID enables Microsoft to maintain a complete browsing history for every Windows user across every browser.
There is no public demonstration that ordinary visits in Firefox, Chrome, Brave, or another browser are universally logged with GDID by the operating system. There is also no evidence that the identifier itself intercepts encrypted HTTPS traffic.
The court filing proves something narrower but still important: Microsoft could associate one Windows installation with several precise website visits relevant to an investigation.
The unanswered scope questions are substantial:

• Which Windows component created those records
• Whether optional diagnostic data was enabled
• Whether SmartScreen or another reputation service was involved
• Whether the URLs were collected by Edge
• How long Microsoft retained the data
• How broadly investigators were able to query it
• Whether the same records exist for typical consumer systems
• Whether regional privacy configurations alter collection

Until Microsoft answers those questions, categorical statements in either direction remain premature.

GDID, VPNs, Proxies, and Anonymity​

Some coverage has claimed that Microsoft’s identifier allows Windows to defeat any VPN. That is an overstatement.
A VPN changes the network path and the public IP address visible to websites and services reached through the tunnel. It does not automatically remove identifiers deliberately sent by software running on the endpoint.
When a Windows component communicates with Microsoft through a VPN, Microsoft may see the VPN exit address rather than the user’s home address. If the same communication contains a stable device identity, however, Microsoft can recognize that two sessions came from the same Windows installation even when their visible IP addresses differ.
The GDID therefore does not crack VPN encryption or expose the real address hidden behind a properly configured tunnel. It can undermine unlinkability, which is a different privacy property.
An investigator may observe the following pattern:

• The device appears through a commercial proxy during suspicious activity.
• The same identifier later appears through a hotel, residential, university, or mobile connection.
• Account records identify the subscriber or user of the non-proxy connection.
• Travel and social records corroborate the person’s location.
• The combined evidence connects the concealed session with the identifiable one.

That appears to be the central value of GDID in the Stokes investigation. The alleged attacker did not necessarily suffer a VPN leak; the stable device identity linked compartmentalized sessions over time.

Operational Separation Matters More Than One IP Address​

This case reinforces a longstanding security principle. Network anonymity and endpoint anonymity are not the same.
A person can route a browser through a proxy while Windows, Edge, Defender, OneDrive, the Microsoft Store, identity services, or another background component continues communicating with Microsoft. Even when every connection uses the same VPN tunnel, stable identifiers can still reveal continuity between sessions.
A VPN remains useful for protecting traffic from local observers, changing the address visible to destinations, and reducing some forms of tracking. It should not be represented as a tool that makes a logged-in, heavily connected operating system forget which installation it is running on.

Local Accounts Do Not Reliably Prevent GDID​

Early speculation suggested that GDID might exist only after signing into a Microsoft account. Real-world observations of Windows 10 systems indicate that this is not a safe assumption.
A Windows 10 LTSC installation reportedly contained the same identity structure despite never having a conventional Microsoft account configured. Analysis of the Connected Devices Platform also indicates that Windows supports an anonymous device registration path.
In this context, anonymous does not mean that the installation lacks an identifier. It means the device can be represented in Microsoft’s services before or without a direct named-account relationship.
A local Windows account can reduce the number of automatic links to Microsoft’s consumer identity ecosystem. It does not guarantee that the computer lacks a GDID or that Windows connected services stop transmitting device-level information.

Windows Home, Pro, Enterprise, and LTSC​

Edition and policy configuration can change which services run, which diagnostic settings are available, and how an organization manages telemetry. Enterprise and LTSC systems often provide more controls than consumer editions.
Those controls should not be confused with proof that the underlying identity infrastructure is absent. A device can retain a GDID even when certain experiences are disabled or no Microsoft account is displayed in the Windows Settings interface.

Windows Versions Known to Contain GDID​

The strongest public evidence confirms GDID on Windows 10 and Windows 11.
For Windows 11, the identity flow has been examined on a recent build in the 26200 series using public debugging symbols, Event Tracing for Windows, registry inspection, and network behavior.
For Windows 10, Microsoft’s Windows Update reporting schemas explicitly apply to the operating system, and the identifier has been observed on a Windows 10 LTSC installation.
The infrastructure behind IdentityCRL and Microsoft device identities predates Windows 10. Related concepts existed in earlier Microsoft Account, Windows Live, Windows Phone, and Windows 8-era systems.
That history does not establish that Windows 7, Windows 8, Windows 8.1, Windows Server, Windows IoT, and every specialized Windows edition use the same GDID implementation. Claims that the identifier exists identically on every Windows computer ever produced go beyond the available evidence.
The defensible conclusion is narrower:

• Windows 10: Confirmed
• Windows 11: Confirmed
• Windows 10 LTSC: Observed
• Windows Server variants: Not comprehensively established
• Windows 8 and Windows 8.1: Related identity infrastructure existed, but identical GDID behavior is not sufficiently verified
• Windows 7 and earlier: No solid basis for claiming the current GDID implementation
• Virtual machines: Explicitly included in Microsoft’s device-level description

---

Changing or Deleting GDID Locally​

The existence of a readable registry value naturally leads to attempts to delete, edit, or replace it. That approach is unlikely to provide the clean reset many users expect.
The local value appears to be part of a larger identity relationship involving tokens, caches, device registration, and Microsoft’s server-side graph. Editing a hexadecimal string in one registry location does not compel Microsoft’s servers to forget the original identifier.

Why a Registry Edit May Not Work​

Several outcomes are possible after changing or deleting the LID value:

• Windows may restore the value from another local identity cache.
• The Microsoft Account service may retrieve it again.
• Connected Devices Platform may reprovision the device.
• Microsoft’s server may reject an unknown or inconsistent value.
• Windows may create a new local token while retaining historical server relationships.
• Account sign-in or connected experiences may malfunction.
• The edited value may have no effect on other identifiers sent by Windows.

A local process with access to the user’s registry might technically be able to manipulate the data. Technical ability does not make the modification supported, reliable, or effective.
Deleting the Connected Devices Platform data directory likewise clears local state rather than erasing Microsoft’s historical records. Windows may rebuild the directory and register the device again.

Reinstalling Windows Produces a New GDID​

The clearest known way to obtain a new GDID is to reinstall Windows. Microsoft’s description in the criminal complaint specifically states that a reinstall results in a new identifier.
The behavior of every recovery path remains less certain. An in-place upgrade, repair installation, “Reset this PC” operation, OEM recovery, virtual-machine snapshot restoration, and fully clean installation do not necessarily handle identity state in the same way.
Even a newly issued GDID does not make the computer unrecognizable. Microsoft may be able to relate the old and new installations through:

• The same Microsoft account
• Entra registration
• OneDrive or Microsoft 365 sign-in
• Store purchases
• Activation and licensing records
• Network history
• Browser synchronization
• Hardware and firmware attributes
• Security telemetry
• Reused recovery or deployment images

No public evidence proves that Microsoft performs every one of those links in every situation. It would nevertheless be inaccurate to describe reinstalling Windows as a guaranteed method for erasing all continuity with the previous installation.

No Supported GDID Rotation Control​

Windows currently provides no documented consumer control labeled Reset Global Device ID, Rotate GDID, or Delete Device PUID.
That separates GDID from the Windows advertising ID, which appears in the Privacy settings interface and has a user-facing control. GDID is treated as internal identity infrastructure rather than a configurable personalization feature.
The lack of a supported rotation mechanism is one of the strongest legitimate concerns raised by the disclosure. A persistent identifier with investigative value deserves clearer lifecycle, deletion, and user-control documentation.

Diagnostic Settings Reduce Data but Do Not Eliminate Identity​

Windows privacy controls can reduce particular categories of data collection. Users can limit optional diagnostic data, disable tailored experiences, review Edge privacy settings, change SmartScreen options, restrict activity history, and avoid unnecessary account synchronization.
Those changes should not be represented as a universal GDID off switch. Connected experiences often require required service data, and Microsoft’s identity, update, security, licensing, and cloud components can continue communicating even when optional diagnostics are disabled.

Diagnostic Data Viewer​

The Diagnostic Data Viewer can display many Windows diagnostic events on supported Windows 10 and Windows 11 systems. It can help users understand what the operating system is sending under the configured diagnostic level.
The viewer does not necessarily expose every server-side relationship, Microsoft Account record, Edge event, security-service transaction, or backend correlation. A user may therefore fail to see GlobalDeviceId in the viewer even though the identity exists elsewhere.

Deleting Diagnostic Data​

Windows also provides an option to delete certain diagnostic data associated with the device. That function does not rotate GDID, disable future required service communications, or necessarily delete records maintained under separate Microsoft products and accounts.
Server logs may additionally remain subject to security retention, fraud prevention, legal holds, backup schedules, or statutory obligations. The exact retention period for the URL-associated GDID records described in the criminal case has not been publicly established.

---

Law Enforcement Use in the United States​

The Stokes prosecution appears to be the first publicly identified federal criminal complaint in which the exact term Global Device Identifier plays a central role in attributing activity to a suspect.
That does not prove law enforcement had never encountered the identifier before. Earlier cases may have called it a device ID, machine ID, PUID, telemetry identifier, or Microsoft device record without disclosing its internal name.
Some investigations remain sealed, and technical evidence is often summarized rather than reproduced. GDID may also have appeared in intelligence, civil, fraud, child-safety, or internal security matters that never produced a searchable public court filing.

Microsoft’s Criminal Referrals​

The complaint indicates that Microsoft made criminal referrals related to the suspect before investigators obtained and assembled the later provider records. Microsoft security personnel reportedly had access to information including machine identifiers, IP addresses, malware samples, and online-service telemetry.
Technology companies routinely refer suspected criminal activity involving their platforms to law enforcement. Those referrals can arise from abuse investigations, threat intelligence, account compromise, malware operations, fraud detection, or legal reporting requirements.
The public filing does not provide enough detail to determine exactly which Microsoft teams had access to GDID-linked records, which datasets were queried internally, or how broadly those systems can be searched.

The Legal Process Remains Unclear​

The complaint refers to provider records and legal process but does not clearly identify the exact instrument used to obtain every GDID-related dataset.
Microsoft generally distinguishes between non-content records, such as subscriber information and IP connection history, and content, which receives stronger legal protection. URLs can fall into complicated territory depending on whether the record reveals only a domain, a complete path, search terms, communications, or stored browser content.
The public record does not settle how Microsoft classified the website data in this case. It also does not establish whether investigators initially received the information through a voluntary security referral, a subpoena, a court order, a search warrant, or a combination of mechanisms.
That ambiguity is not a minor procedural detail. The legal threshold for obtaining a persistent device history can shape how widely the same technique is used in future investigations.

GDID Is Corroborating Evidence, Not Automatic Proof​

A stable device identifier can be highly persuasive, but it is not infallible proof that one individual performed every associated action.
Computers can be shared, remotely accessed, stolen, compromised, cloned, or used through virtual machines. Malware can collect local identifiers, and sophisticated attackers may attempt to copy or manipulate them.
Investigators strengthened the Stokes attribution by combining GDID records with IP addresses, account access, social media, travel, hotel, and photographic evidence. The case demonstrates the importance of corroboration rather than establishing GDID as an unquestionable digital signature.

Use by Law Enforcement Outside the United States​

No second public criminal case has yet clearly documented foreign law enforcement using Microsoft’s GDID under that exact name. The absence of a published case should not be mistaken for proof that the identifier has never been disclosed elsewhere.
Microsoft receives law-enforcement demands from governments around the world. Depending on the country, data location, user, offense, and treaty structure, authorities can seek records through domestic orders, mutual legal-assistance procedures, or cross-border data-access agreements.
The United States has formal CLOUD Act arrangements with some partner countries, while other requests can move through established international legal channels. A GDID-linked dataset could therefore become available to foreign investigators when the necessary legal standards are met.
Finland’s role in the Stokes matter involved arresting and extraditing the defendant after international coordination. Nothing currently public establishes that Finnish authorities independently queried or used the Windows identifier.
The broader implication remains significant. Microsoft’s device graph is global, so a persistent Windows identity can have relevance well beyond the country where a computer was purchased or used.

Privacy Law Does Not Make the Number Anonymous​

A GDID may appear pseudonymous because it is a number rather than a name. Under modern privacy frameworks, an online or device identifier can still qualify as personal data when it can reasonably be linked to a person.
That linkage is precisely what the criminal complaint demonstrates. The number became personally meaningful when joined with account, network, travel, and social evidence.
The legal treatment will differ among the European Union, United Kingdom, United States, Australia, Canada, and other jurisdictions. The central policy issues are consistent: transparency, necessity, proportionality, retention, access controls, and the ability to challenge government demands.

Separating the Facts From the Hype​

The Windows GDID story has generated dramatic claims, some supported and others not.

• Claim: Microsoft secretly added a new tracker to Windows.
  Reality: GDID is not new, and Microsoft previously exposed the field in technical reporting schemas. Its investigative use and precise architecture were obscure to ordinary users.
• Claim: GDID is permanent.
  Reality: It persists across normal Windows updates but changes after a Windows reinstall. Long-lived is more accurate than permanent.
• Claim: GDID is burned into the motherboard.
  Reality: The evidence points to a 64-bit provisioned device PUID, not a deterministic motherboard or processor serial hash.
• Claim: Microsoft can use it to follow a device through different IP addresses.
  Reality: Yes. That is the clearest capability demonstrated by the criminal complaint.
• Claim: GDID reveals a real IP address from behind a VPN.
  Reality: Not by itself. It can link sessions using different addresses, but it does not decrypt the tunnel or magically expose the address behind it.
• Claim: Windows records every website in every browser under GDID.
  Reality: Unproven. Specific URL-related records existed in the case, but their collection mechanism and general coverage remain undisclosed.
• Claim: Using a local account prevents GDID creation.
  Reality: Evidence from Windows 10 and the Connected Devices Platform indicates that local-account systems can still receive a device identity.
• Claim: Turning off optional diagnostics removes GDID.
  Reality: Optional diagnostic controls can reduce data collection but do not appear to rotate or eliminate the underlying identity.
• Claim: Deleting one registry value erases the record.
  Reality: The value is connected to additional local state and a server-side device graph. A registry edit does not delete historical Microsoft records.
• Claim: GDID is an anti-piracy or activation identifier.
  Reality: No reliable evidence establishes GDID as a Windows activation or anti-piracy token.
• Claim: Microsoft has publicly explained everything about GDID.
  Reality: It has not. The most important lifecycle, telemetry, retention, and user-control details remain poorly documented.

---

Privacy Implications for Windows Users​

GDID changes the privacy discussion because it provides continuity. IP addresses can change, cookies can be cleared, browsers can be switched, and account sessions can end, but the underlying Windows installation may remain recognizable.
That does not automatically constitute improper surveillance. Persistent device identities support legitimate functions such as fraud prevention, security response, device management, update reporting, service reliability, and synchronization.
The concern is function expansion. An identifier created for device management can become a powerful investigative or profiling tool when attached to detailed browsing, location, account, and network records.

Purpose Limitation and Retention​

Microsoft should clearly explain which services receive GDID, for what purposes, and for how long the resulting records remain queryable.
A value used briefly to deduplicate update records presents a different privacy risk from a value retained for years alongside URLs and IP history. Both may use the same identifier, but their consequences are not comparable.
Users also need to know whether the data is centralized or separated by service. Internal access controls determine whether one Microsoft team can search the complete device history or only the records necessary for a particular product.

Transparency and Meaningful Choice​

Windows exposes dozens of privacy controls but does not present GDID as a distinct identity. A user cannot view its server history, rotate it, limit it to one service, or determine which products have attached records to it.
Consent becomes difficult when the underlying identifier is invisible and its cross-service role is undocumented. A description buried in an enterprise schema is not equivalent to a clear consumer explanation.
The public disclosure is likely to increase pressure for a device identity dashboard showing active identifiers, linked services, creation time, retention rules, and supported reset options.

Security Implications Beyond Privacy​

Persistent identifiers can protect users as well as expose them. Microsoft can use device continuity to detect account takeover, block malicious infrastructure, identify malware campaigns, correlate attacks, and distinguish a known computer from a suspicious new one.
The Stokes complaint illustrates that defensive value. A stable installation identity allegedly helped connect infrastructure, online activity, and travel patterns that an attacker attempted to separate.
The same property creates new abuse opportunities once the registry location becomes widely known.

Malware and Commercial Fingerprinting​

A process running under a user’s account may be able to read the IdentityCRL registry value. Malware, adware, game anti-cheat systems, fraud-detection software, or invasive commercial applications could attempt to use it as another machine fingerprint.
The value may not be useful to an outsider without access to Microsoft’s records. It can still serve as a durable local marker or be combined with MachineGuid, hardware attributes, account names, installed software, and network information.
Security products should begin monitoring unexpected access to sensitive identity locations. Microsoft should consider whether ordinary applications need direct read access to the underlying value.

Spoofing and Evidence Reliability​

Public awareness may also lead attackers to experiment with GDID manipulation, registry copying, identity-cache cloning, disposable virtual machines, and repeated Windows installations.
That could reduce the identifier’s forensic reliability. A copied or corrupted identity might cause two systems to appear related, while deliberate reprovisioning could create a trail of short-lived device records.
Law enforcement and incident responders should therefore avoid treating GDID as a cryptographic attestation. It is a correlation artifact whose evidentiary strength depends on surrounding records.

Implications for Enterprise Administrators​

For enterprise Windows teams, GDID is more than a consumer privacy curiosity. It may appear in update, Delivery Optimization, cloud, identity, and security records used for operational reporting.
Administrators should treat it as sensitive pseudonymous metadata, particularly when exporting logs to data lakes, support systems, ticketing platforms, or third-party analytics products.

Practical Enterprise Priorities​

• Inventory where GlobalDeviceId appears. Review Windows Update for Business, Delivery Optimization, Microsoft security, identity, and diagnostic exports.
• Restrict access to raw device identifiers. Analysts rarely need unrestricted access to every identifier and associated IP address.
• Set defensible retention periods. Device-level histories should not remain indefinitely merely because storage is inexpensive.
• Review legal and compliance handling. GDID-linked records may qualify as personal data when employees, customers, or contractors can be identified.
• Protect exported logs. A supposedly anonymous dataset can become identifiable when GDID is joined with device names, usernames, office locations, or sign-in records.
• Examine virtual-machine and imaging workflows. Templates captured after identity provisioning may carry state that should not be duplicated.
• Test rather than assume Sysprep behavior. Proper Windows generalization remains essential, but organizations should verify how their exact build and provisioning path handle GDID.
• Document incident-response use. Security teams should define when device-level correlation is appropriate and how findings must be corroborated.

Golden Images and Virtual Machines​

Microsoft describes GDID as applying to virtual machines as well as physical systems. This creates potential concerns for non-persistent desktops, development templates, classroom labs, and cloned virtual machines.
If an image is captured after a device identity has been provisioned, clones could inherit local identity state or trigger inconsistent reprovisioning. The exact behavior may vary by Windows version, account configuration, domain status, and virtualization platform.
Organizations should build templates in an offline or appropriately generalized state, deploy them, and then verify that resulting machines receive distinct identities. A duplicated identifier can damage update reporting, security attribution, and forensic analysis even when it creates no immediate user-facing error.

The Benefits Microsoft Can Legitimately Claim​

A fair assessment must recognize why a global device identifier exists.
Microsoft operates Windows across an enormous range of physical machines, virtual environments, networks, accounts, tenants, and update states. Device names are not globally unique, IP addresses are unstable, and users frequently rename computers or move between networks.
A durable identity helps Microsoft:

• Join update and reliability records
• Deduplicate devices in reporting systems
• Track Delivery Optimization status
• Detect account and service abuse
• Recognize suspicious device changes
• Support cross-device experiences
• Investigate malware and ransomware campaigns
• Maintain cloud device relationships
• Diagnose failures across Windows releases
• Correlate incidents when network addresses change

The existence of that operational need does not settle whether Microsoft collects too much associated data. It explains why replacing GDID with an IP address or computer name would not provide equivalent functionality.
The policy question is not whether Microsoft may ever distinguish one installation from another. It is whether users receive adequate notice and control over the data attached to that identity.

How Windows Compares With Other Platforms​

Persistent device identifiers are not unique to Microsoft.
Apple and Google maintain device and account identities for activation, synchronization, security, app stores, push notifications, fraud prevention, and device management. Mobile operating systems may expose resettable advertising identifiers while retaining separate non-resettable service identities.
Linux systems commonly have /etc/machine-id, a locally stored value used to identify an operating-system installation. Well-designed Linux applications can derive application-specific identifiers rather than transmitting the raw machine ID to every service.
These comparisons should not be used to dismiss the Windows case. The important differences involve:

• Whether the identifier is local or centrally registered
• Which services receive it
• Whether different services share the same value
• Whether users can rotate or delete it
• How much associated data is retained
• Whether URL and location records are attached
• How governments can obtain the resulting history
• Whether independent audits can verify the controls

A common industry practice can still produce excessive surveillance when implemented without meaningful limits. Conversely, the mere existence of a device ID does not prove abusive monitoring.

---

What Microsoft Still Needs to Explain​

The public now knows enough about GDID to understand its potential, but not enough to evaluate its full scope.
Microsoft can materially improve trust by addressing several points directly:

• Document how GDID is generated. Clarify which values are server-issued, which are cached locally, and which components participate.
• Explain the local-account path. State when Windows provisions a GDID without a Microsoft account and what anonymous registration means.
• Publish an exact service inventory. Identify which Windows and Microsoft services send, receive, store, or derive the identifier.
• Describe the URL records in the criminal case. Explain which product created them and whether their collection depended on optional settings.
• Define retention periods. Users and organizations need to know how long GDID-linked IP, URL, update, security, and account histories remain available.
• Clarify deletion behavior. State what the Windows diagnostic deletion control removes and what survives in other Microsoft systems.
• Provide a supported rotation mechanism. A Windows reinstall should not be the only documented way to obtain a new identifier.
• Document law-enforcement classification. Explain whether GDID histories, IP records, and URL events are treated as content or non-content data.
• Expose enterprise controls. Administrators need policy options governing collection, export, retention, and cross-service correlation.
• Protect the registry value from casual harvesting. Microsoft should assess whether every user-context process needs direct access.
• Explain virtual-machine cloning behavior. Enterprises need predictable guidance for templates, snapshots, pooled desktops, and non-persistent environments.
• Offer a user-visible device history. People should be able to see which installations Microsoft associates with their accounts and when each was last active.

Silence will allow the most alarming interpretations to dominate. Clear technical documentation would make it possible to separate necessary device management from excessive data collection.

The Consequences of Making GDID Public​

The disclosure has already changed the value of the identifier.
Privacy researchers now have a concrete path for examining Windows’ device identity architecture. Administrators can search their environments for the field, security vendors can monitor access to it, and policymakers can evaluate whether Microsoft’s disclosures match the practical capabilities demonstrated in court.
Criminals will learn from the same information. Sophisticated operators may rely more heavily on disposable virtual machines, isolate Microsoft traffic, avoid persistent installations, or rebuild systems more frequently.
That adaptation may make future investigations harder. It also demonstrates why secret identifiers rarely remain reliable forever once they become valuable in criminal attribution.
The public benefit is greater accountability. Users can now ask informed questions about a capability that previously existed largely outside consumer awareness.

Conclusion​

The Microsoft Global Device Identifier is not a mythical chip-level serial number, a universal browser wiretap, or a newly installed Windows backdoor. It is a persistent, server-recognized identity associated with a Windows installation, visible locally through IdentityCRL registry data and used across parts of Microsoft’s device and update infrastructure.
Its importance lies in correlation. In the Stokes criminal complaint, one GDID allegedly helped connect a proxy-created ngrok account, visits to a victim’s website, IP addresses, online accounts, hotels, and international travel.
The case does not prove that Microsoft records every website visited on every Windows PC. It does prove that Microsoft retained enough device-linked information in one investigation to reconstruct a remarkably detailed trail, while leaving the exact collection path largely unexplained.
Windows 10 and Windows 11 users cannot currently rotate GDID through a supported privacy control. Local accounts do not reliably prevent its creation, registry edits do not erase server history, and disabling optional diagnostic data does not eliminate every connected-service identity.
The responsible response is neither panic nor dismissal. GDID has legitimate roles in updates, security, device management, and abuse detection, but its persistence and demonstrated investigative power demand far more transparency than Microsoft has provided.
The identifier is no longer merely an obscure field in a Windows reporting schema. It is now a public example of how a single durable number can turn fragmented digital events into a coherent history of one computer—and, when enough other records are available, the person believed to be using it.