Key Takeaways

  • Windows can create a persistent Global Device Identifier (GDID) after a device connects to Microsoft services.
  • Microsoft documents the identifier as GlobalDeviceId and shows it in the format g:<number>, describing it as an internal Microsoft device identifier.
  • Independent testing by IT-Connect found that deleting the local registry value was temporary because Windows recreated it after reconnecting.
  • Blocking the Microsoft endpoints involved can affect sign-in, Microsoft Store, OneDrive, Microsoft 365, Delivery Optimization, and other Windows features.
  • Businesses should identify their actual privacy objective, test changes on a small device group, and use supported Windows policies wherever possible.

A Windows PC can carry an identifier that remains associated with the device across network changes. It is called the Global Device Identifier, or GDID.

The identifier deserves attention from security and privacy teams because it is generated at the device level, not from the public IP address used for a connection. Changing networks or enabling a VPN therefore does not remove a locally stored device identifier if Windows sends it to an online service.

Microsoft acknowledges the field in its Windows Update for Business reporting schema. A recent IT-Connect investigation went further by observing when the value appeared, what happened after it was deleted, and which Windows functions were affected when related communications were blocked.

The findings are useful, but they need careful interpretation. A registry value that can be located is not the same thing as a supported privacy control, and blocking a shared Microsoft identity endpoint can disable much more than one identifier.

What Is Windows GDID?

Microsoft's UCDOStatus schema documentation defines GlobalDeviceId as a Microsoft global device identifier used internally. Its example uses the format g:9832741921341.

On the device, IT-Connect found the underlying LID value in the current user's registry at:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties

The value is named LID and is stored as hexadecimal data. Converting that value to an unsigned integer and adding the g: prefix produces the documented GDID format.

This matters because a persistent device identifier can help a service associate events with the same Windows installation even when the user changes Wi-Fi networks, public IP addresses, or VPN exit locations. That does not, by itself, prove how every Microsoft service uses the identifier or how long every related record is retained. Microsoft’s public schema describes the field, but it does not provide a complete public lifecycle for it.

How to Check Whether a GDID Exists

Administrators can inspect the current user's LID without changing the system. The following PowerShell command is read-only:

$lid = Get-ItemPropertyValue `
  -Path 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties' `
  -Name LID `
  -ErrorAction SilentlyContinue

if ($null -ne $lid) {
  "g:$([Convert]::ToUInt64($lid, 16))"
}

No output means the value was not present for the user running the command at that moment. It does not prove that the device has never had an identifier, that another user profile has none, or that no other device identifiers exist in Windows.

Treat the result as one inventory signal. Avoid collecting these values centrally unless there is a defined security or compliance purpose, appropriate access control, and a retention policy. A device identifier is itself data that should be handled deliberately.

Why Registry Deletion Does Not Solve the Problem

IT-Connect tested a new Windows 11 installation configured with a local account and initially kept offline. The researchers reported that no LID was present while the machine remained disconnected. After internet access was enabled, the value appeared within seconds.

They then deleted the value and disconnected the machine. According to their test, Windows created it again after the next connection. They also observed traffic involving login.live.com during the provisioning process.

This is an independent lab result, not a Microsoft guarantee that every Windows build, edition, configuration, and region will behave identically. It nevertheless illustrates an important distinction: deleting a local copy does not prevent the operating system from requesting or restoring it.

A cleanup script may make a registry query return nothing for a short period while leaving the provisioning path intact. That is not a durable control and can create a false sense of protection.

Blocking GDID Has More Than One Meaning

Before changing firewall, DNS, or Windows service settings, define the intended result. These are different goals:

  1. Remove the current registry value. This affects the local copy but may not stop recreation.
  2. Prevent initial provisioning. IT-Connect's test indicates that blocking login.live.com before the first online connection can do this, but the endpoint also supports major Microsoft identity functions.
  3. Reduce later reporting paths. This can involve Connected Devices Platform or Delivery Optimization services and their network destinations. It does not necessarily remove an existing GDID or stop every Microsoft connection.

None of these actions makes a Windows device anonymous. Windows and installed applications can use other identifiers, accounts, certificates, management records, or service-specific data.

Why Blocking login.live.com Is High Impact

The most direct blocking method described in the IT-Connect test is also the least suitable for general business deployment. login.live.com is part of Microsoft's account and authentication infrastructure.

Blocking it can interfere with:

  • Microsoft account sign-in
  • Microsoft Store access and application licensing
  • OneDrive authentication
  • Microsoft 365 sign-in flows
  • Windows applications that depend on Microsoft identity

An endpoint shared by several services is a poor candidate for an organization-wide deny rule unless those services are intentionally prohibited and the impact has been tested. Existing sessions may also hide the effect until a token expires or a user changes devices, making an incomplete pilot look successful.

Delivery Optimization and Connected Device Tradeoffs

Some GDID-related communications observed by researchers overlap with Windows Delivery Optimization and Connected Devices Platform functions. Microsoft lists *.do.dsp.mp.microsoft.com among Delivery Optimization endpoints and explains that the service uses cloud coordination for peer delivery.

Disabling services or blocking destinations such as Delivery Optimization endpoints may reduce particular communications, but it can also remove peer caching, increase internet bandwidth use, or affect cross-device experiences. The outcome depends on Windows version, management state, and policy configuration.

For bandwidth and peer-to-peer concerns, use documented controls first. Microsoft's Delivery Optimization reference supports managed download modes such as HTTP only, LAN peering, group peering, internet peering, and simple mode. The Delivery Optimization overview explains how those modes depend on Microsoft’s cloud service.

These policies are designed to manage update delivery behavior. Microsoft does not document them as a universal switch for disabling GDID, so they should not be represented as one.

Community projects such as no-gdid combine endpoint and service changes. They can be useful for lab analysis, but they are not Microsoft-supported policy baselines. Review every command, test application and update behavior, and prepare a reversal procedure before considering them.

A Safer Business Response

For a managed Windows estate, start with evidence rather than a blanket block:

  1. Record the Windows versions, editions, account types, and management platforms in scope.
  2. Inspect a representative sample for the LID and capture only the data needed for the review.
  3. Decide whether the concern is device identification, Microsoft account use, Delivery Optimization, regulatory disclosure, or network minimization.
  4. Check existing Intune, Group Policy, firewall, proxy, and DNS settings before adding a new control.
  5. Build a pilot group that includes Microsoft 365, Store, OneDrive, update, and line-of-business application users.
  6. Measure sign-in, licensing, update delivery, bandwidth, and event-log effects across token renewals and restarts.
  7. Document ownership, exceptions, monitoring, and rollback before wider deployment.

Privacy requirements should also be addressed through governance. Confirm what device data is collected, why it is needed, who can access it, and how long it is retained. A technical block is only one possible control and may be less effective than account, management, and data-retention changes.

Final Assessment

Windows GDID is a real, documented identifier, and IT-Connect's testing suggests that simply deleting its registry value does not provide a lasting opt-out. Preventing its creation or limiting associated traffic is possible only with meaningful tradeoffs, because the observed endpoints and services also support authentication, applications, connected-device features, and update delivery.

There is no public, supported Microsoft setting documented as a dedicated “disable GDID” switch. For businesses, the defensible approach is to define the privacy objective, verify the behavior on the Windows builds actually deployed, favor supported policies, and introduce network restrictions only after a controlled impact test.

Computer On Site can assess Windows endpoint privacy, identity dependencies, Delivery Optimization, and management policies, then design a tested control plan that protects business access as well as privacy requirements.