Historical Context and Naming

Microsoft’s consumer identity system began as .NET Passport (later Windows Live ID, and today Microsoft Account / MSA). Within that system, PUID (Passport Unique Identifier) was the internal name for unique numeric identifiers assigned to users and, later, devices.

• User PUIDs typically carry a namespace prefix of 0x0003.
• Device PUIDs carry a namespace prefix of 0x0018.

The Device PUID is therefore a specialized Passport Unique Identifier issued for a specific Windows installation (physical hardware or virtual machine) when that installation is provisioned against a Microsoft Account. In public technical reporting and court documents from 2026, the same value is frequently referred to as the GDID (Global Device Identifier), often displayed in the form g: followed by a decimal number.

Formal Definition

The Device PUID is a 64-bit integer assigned by Microsoft’s consumer identity servers. It uniquely labels a specific installation of the Windows operating system (on physical hardware or a virtual machine) for use across certain Microsoft services and scenarios.

Microsoft has described it, in formal legal filings, as:

“a persistent, device-level identifier designed to uniquely identify an installation of a Windows operating system on a device, either a physical device (e.g., a mobile phone or laptop) or virtual machine, across certain Microsoft services and scenarios.”

It is not:

• A hardware serial number or hash of hardware components
• A locally generated GUID or UUID
• A user account identifier (those use a different namespace)
• An advertising ID or diagnostic telemetry ID in the conventional sense

Technical Characteristics

How It Is Created

1. Windows (via the Microsoft Account service wlidsvc) contacts Microsoft identity endpoints.
2. The request includes various device context (including hardware descriptors).
3. The server returns a Device PUID (sometimes referenced in responses as <ps:DevicePUID> or related fields such as HWPUIDFlipped).
4. The value is written into the current-user registry hive.
5. Background components—most notably the Connected Devices Platform (cdp.dll / CDPSvc)—read the value and register it into Microsoft’s Device Directory Service, the identity graph that supports cross-device features.

Because the value is stored in the current-user hive, any process running as the logged-in user can read it; administrative elevation is not required.

What It Is Used For

The Device PUID functions as a stable indexing key for:

• Digital license and activation state tied to a Microsoft Account
• Microsoft Store purchases, app installations, and licensing
• Cross-device experiences (Phone Link, cloud clipboard, Nearby Share, activity history, etc.)
• Internal telemetry surfaces such as UCDOStatus.GlobalDeviceId in Delivery Optimization and Windows Update reporting
• Broader identity-graph operations inside Microsoft’s Device Directory Service

It allows Microsoft services to recognize “this particular Windows installation” across sessions, IP address changes, and many system modifications.

Key Distinctions from Related Identifiers

• Versus hardware identifiers (SMBIOS UUID, CHIDs, activation hardware hashes, TPM endorsement keys, disk serials, MACs): Those are derived from physical or firmware data and remain stable across OS reinstalls when the hardware is unchanged. The Device PUID is installation-scoped and is reassigned on a clean install.
• Versus user PUIDs: User identifiers live in a different numeric namespace (0x0003…) and identify Microsoft Accounts rather than installations.
• Versus ordinary GUIDs: GUIDs are typically 128-bit, generated locally, and used for software objects; the Device PUID is 64-bit, server-assigned, and used for installation identity.

Summary

The Device PUID is a server-minted, 64-bit Passport Unique Identifier that Microsoft assigns to a Windows installation. It is stored locally in clear text, registered into Microsoft’s device identity graph, and used as a durable handle for licensing, Store operations, cross-device features, and related services. It is deliberately scoped to the installation rather than the underlying hardware, which is why a reinstall produces a new value while hardware fingerprints remain constant.

How the Device PUID Is Created and Stored

High-Level Creation Flow

The Device PUID is not generated on the client. Windows never computes it from local hardware, random numbers, or any other local data. Instead:

1. A Windows system service contacts Microsoft’s identity infrastructure.
2. Microsoft’s servers assign a new 64-bit value (or associate an existing one under certain conditions).
3. The server returns the value to the client.
4. Windows stores it locally and later registers it into broader Microsoft services.

This process is typically triggered during device provisioning against a Microsoft Account, though related fallback registration paths exist even in some local-account scenarios.

Detailed Creation Sequence

Step 1 — Service Initiation

The primary actor is the Microsoft Account service, implemented in wlidsvc (Windows Live ID service). When Windows needs to provision or re-register a device identity, this service initiates a request to Microsoft’s identity endpoints (historically centered on login.live.com and related Passport/PPCRL endpoints).

Step 2 — Outbound Request

wlidsvc sends a structured request (SOAP-based PPCRL / Passport protocol). The payload includes a block of device information containing multiple hardware descriptors. Observed component tags in network traces include:

• System manufacturer and product name (SMBIOS-derived)
• SMBIOS system serial number and UUID
• Disk serial numbers
• Network adapter MAC addresses and bus information
• TPM-related data
• Additional values (some still only partially documented publicly)

These descriptors provide context so the server can perform association or uniqueness checks; they are not used by the client to calculate the PUID itself.

Step 3 — Server-Side Assignment

Microsoft’s identity servers generate or retrieve a 64-bit Device PUID. Device-class identifiers fall into the 0x0018 namespace. The server includes the value in its response, commonly appearing in fields such as <ps:DevicePUID> or related response elements (sometimes referenced in analysis as HWPUIDFlipped).

Step 4 — Client Reception

Windows receives the server-assigned value as a string. No local cryptographic derivation or hashing of the returned value occurs for the purpose of creating the identifier.

Local Storage

Once received, the Device PUID is written to the Windows registry in clear text:

Hive / Path:  HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties
Value name:   LID
Type:         REG_SZ (string)
Format:       16 hexadecimal characters (example pattern: 0018XXXXXXXXXXXX)

Key properties of this storage:

• Located in the current-user hive (HKCU), so it is readable by any process running as the logged-in user.
• No administrative privileges are required to read or (in many cases) modify the value.
• Stored without encryption, DPAPI protection, or other obfuscation in the registry location itself.
• The hexadecimal string can be converted to the decimal “g:” form used in telemetry and legal records (e.g., g:6755467234350028).

Additional related identity state may appear in other IdentityCRL locations, token caches, or Credential Manager entries, but the primary, authoritative local copy of the Device PUID is the LID value described above.

Subsequent Registration and Propagation

After local storage:

• The Connected Devices Platform (implemented in cdp.dll and running as the CDPSvc / related services) reads the value, typically via APIs such as GetStableDeviceIdFromProvider.
• The platform registers the identifier into Microsoft’s Device Directory Service (the backend identity graph that powers Phone Link, cloud clipboard, Nearby Share, activity history, and other cross-device features).
• Other components surface or report the same value. A documented example is Delivery Optimization, which exposes it as UCDOStatus.GlobalDeviceId in Azure Monitor / Windows Update for Business telemetry schemas.

This registration step is what makes the identifier useful across Microsoft’s service ecosystem; the local registry value alone would be insufficient for cross-service correlation.

Persistence and Lifecycle Behaviors

• The stored value survives normal Windows feature updates, quality updates, and most configuration changes.
• A clean reinstallation of Windows generally results in a new Device PUID being assigned on the next provisioning contact with Microsoft servers.
• Server-side historical associations linked to a previous PUID are not automatically deleted when a new one is issued.
• Because the value lives in the user hive, it is tied to the user profile that performed the provisioning. Multiple user profiles on the same installation can involve additional identity state.

Summary of Creation and Storage

In short, the Device PUID is created exclusively on Microsoft’s servers during a network-based provisioning exchange, returned to the client, stored in plain text in the current-user registry, and then propagated into Microsoft’s broader device identity systems. This design separates the act of assignment (server) from the act of local caching and subsequent use (client and backend services).

Primary Uses of the Device PUID Inside Microsoft’s Ecosystem

This identifier functions as a stable, installation-scoped key that allows Microsoft systems to recognize and correlate a specific Windows installation.

1. Digital Licensing and Windows Activation

The Device PUID helps bind digital licenses to a particular Windows installation and its associated Microsoft Account.

• When Windows activates or re-validates a digital license, the identifier participates in the broader device identity that Microsoft’s licensing services maintain.
• It supports scenarios in which a license is tied both to an account and to an installation, enabling features such as license reactivation after hardware changes or reinstallation (subject to Microsoft’s licensing rules).
• Related hardware hashes are also transmitted during activation, but the Device PUID provides the installation-level handle that persists across updates.

2. Microsoft Store and Application Licensing

Microsoft Store operations rely on the Device PUID as an indexing key for:

• Purchases and ownership records
• App installations and updates
• License entitlement checks for Store apps and games
• UWP / Microsoft Store app licensing enforcement

Because the identifier is consistent for the life of an installation, the Store can recognize previously licensed software on that same Windows instance even after IP address changes or certain system modifications.

3. Cross-Device and Continuity Features

The Connected Devices Platform (CDP) reads the local Device PUID and registers it with Microsoft’s Device Directory Service. This registration underpins many continuity experiences:

• Phone Link (linking Android or iOS devices to the Windows PC)
• Cloud clipboard
• Nearby Share
• Timeline / activity history synchronization
• Other cross-device roaming and handoff features

In these scenarios the Device PUID acts as the canonical identifier for “this Windows installation” within Microsoft’s device identity graph.

4. Telemetry, Diagnostics, and Update Infrastructure

Several Microsoft telemetry and update systems surface or report the identifier:

• Delivery Optimization exposes it as UCDOStatus.GlobalDeviceId in Azure Monitor and Windows Update for Business schemas. Microsoft documents this field as a “Microsoft global device identifier… used by Microsoft internally.”
• Diagnostic and telemetry pipelines can stamp events with the Device PUID, allowing correlation of data from the same installation across different services and time periods.
• Windows Update and related servicing components can use it for device-level tracking of update status, delivery, and peer-to-peer sharing behavior.

5. Identity Graph and Account-Linked Services

Once registered in the Device Directory Service, the Device PUID becomes part of Microsoft’s larger identity graph. This enables:

• Association between a Windows installation, one or more Microsoft Accounts, and other registered devices
• Consistent recognition of the installation across authentication, token issuance, and service authorization flows
• Backend operations that need a durable device-level key independent of changing network addresses or transient session identifiers

6. Support, Abuse Investigation, and Legal Process

Because the identifier is stable for an installation and appears in multiple service logs, it can be used (under appropriate legal process) to:

• Correlate activity across Microsoft properties that involve the same Windows installation
• Assist in investigations where an installation-level identifier is more useful than an IP address or advertising ID
• Link licensing, Store, and telemetry records during support or fraud-related reviews

Court documents have publicly referenced the GDID/Device PUID in this context, confirming its role as a persistent installation identifier that Microsoft can locate across its systems.

Summary Table of Primary Uses

Design Rationale

Microsoft designed the Device PUID to answer a specific question: “Which Windows installation is this?” Hardware fingerprints answer a different question (“Which physical or virtual machine is this?”). By maintaining both, Microsoft can support licensing integrity, cross-device experiences, and service-level operations while still distinguishing between an installation and the underlying hardware.

The identifier’s server-assigned nature and registration into the Device Directory Service make it particularly useful for any scenario that requires recognizing the same Windows installation across time, network changes, and multiple Microsoft products.

Privacy, Persistence, and Limitations of the Device PUID

A. Persistence Characteristics

The Device PUID is engineered for stability within a single Windows installation:

• Survives ordinary changes: Feature updates, quality updates, most configuration modifications, and many driver or software installations leave the value unchanged.
• Tied to the installation, not the hardware: A clean reinstallation of Windows generally causes Microsoft’s servers to issue a new Device PUID on the next provisioning contact. The previous identifier is not reused for the new installation.
• Server-side history remains: While the local value is replaced after a reinstall, records previously associated with the old Device PUID on Microsoft’s servers are not automatically erased. Historical associations can therefore persist independently of the local registry value.
• User-hive scope: Because the primary local copy resides in HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID, it is associated with the user profile that performed the provisioning. Other profiles on the same machine may maintain separate or related identity state.

These properties make the identifier durable for the life of an installation while still allowing a fresh start after a complete OS reinstall.

B. Privacy Implications

The Device PUID functions as a stable correlator rather than a content-monitoring mechanism:

• Cross-service linkage: Once registered in Microsoft’s Device Directory Service, the same identifier can appear in licensing records, Microsoft Store activity, Delivery Optimization telemetry (UCDOStatus.GlobalDeviceId), cross-device feature logs, and other service data. This enables Microsoft systems to recognize “the same Windows installation” across different products and time periods.
• Independence from network address: Changing IP addresses, using a VPN, or switching networks does not alter the Device PUID. Correlation therefore does not rely on the client’s current network location.
• Combination with other identifiers: When combined with a Microsoft Account identifier (user PUID / CID), hardware fingerprints transmitted during provisioning, and other telemetry, the Device PUID contributes to a stronger overall identity signal. Alone it identifies an installation; in combination it can support more precise attribution.
• Local visibility: The value is stored in plain text in the current-user registry and can be read by any process running as that user. No administrative rights are required to inspect it.
• No documented user-facing disablement: There is no official setting that prevents assignment of a Device PUID once the relevant provisioning or registration flow occurs. Attempts to delete or block only the local registry value are typically incomplete because related identity state exists elsewhere and the value can be re-registered.

In legal and investigative contexts, the identifier has been used (under appropriate process) as a durable installation-level handle that survives IP rotation and certain system changes.

3. Key Limitations

Understanding what the Device PUID cannot do is as important as understanding what it can:

Practical Boundaries for Users and Administrators

• Reinstallation is the most reliable local way to obtain a new Device PUID, though it does not purge historical server-side data linked to the prior value.
• Local-account-only configurations may still trigger device-registration paths in some Windows versions; full isolation from Microsoft identity services is difficult on a standard consumer installation.
• Enterprise / managed environments can apply additional controls through policy, but the underlying Device PUID mechanism remains part of the platform’s identity architecture.
• Forensic or investigative use relies on the combination of the Device PUID with other signals; the identifier by itself does not contain personal data such as a user’s name or email address.

Summary

The Device PUID is a persistent, installation-scoped identity token that survives normal Windows updates and network changes, enabling consistent recognition of a Windows installation across Microsoft’s licensing, Store, cross-device, and telemetry systems. Its privacy significance stems from this correlating power rather than from any direct content collection.

Its principal limitations are equally clear: it is not a hardware-derived fingerprint, it is replaced by a reinstall, it does not itself log user activity, and local attempts to suppress it do not remove server-side history or fully prevent re-registration. These characteristics define both its utility inside Microsoft’s ecosystem and the realistic boundaries of any effort to manage or mitigate it.

Relationship of the Device PUID to GDID and Its Format

Core Relationship

The Device PUID and the GDID are the same underlying 64-bit identifier.

• Device PUID is the internal technical name that originates in Microsoft’s Passport / Microsoft Account identity system. It is the value assigned by Microsoft’s servers and stored locally by Windows.
• GDID (Global Device Identifier) is the name under which the same value appears in public technical reporting, telemetry schemas, Azure Monitor documentation, and legal filings.

In short: every GDID is a Device PUID, and the Device PUID is what Microsoft’s identity infrastructure actually issues and stores. The two labels simply reflect different contexts—one internal to the Passport identity stack, the other used when the identifier is surfaced more broadly as a “global device” handle.

Microsoft’s own description in court documents refers to it as a “persistent, device-level identifier designed to uniquely identify an installation of a Windows operating system,” confirming that the publicly named GDID is this installation-scoped Device PUID.

Numeric Structure and Namespace

The value is a 64-bit unsigned integer. Microsoft identity systems use namespace prefixes to distinguish types of PUIDs:

• Device-class identifiers begin with the prefix 0x0018.
• User-class identifiers (Microsoft Account PUIDs) begin with 0x0003.

This prefixing allows systems to tell at a glance whether a given PUID refers to a Windows installation or to a user account.

Common Formats

The same 64-bit value is represented in several interchangeable forms depending on context:

Conversion is straightforward:

• Take the 16-character hex string from the registry.
• Interpret it as a 64-bit unsigned integer.
• Prefix the decimal result with g: to obtain the GDID form commonly seen in public documents.

Comparison with Other Identifier Formats

To avoid confusion with similar-looking values:

The Device PUID / GDID is deliberately narrower (64-bit) and carries the distinctive g: decimal presentation in many external references, making it visually distinct from ordinary GUIDs.

Practical Recognition

When examining a system or a log:

• A 16-character hex string starting with 0018 in the IdentityCRL registry location is the local Device PUID.
• The same value written as g: followed by a long decimal number is the GDID form used in telemetry and public records.
• Both representations refer to exactly the same identifier.

Summary

The Device PUID is the formal, internal identity token issued by Microsoft’s Passport-derived systems. The GDID is simply the public-facing and telemetry-facing name for that same token. It is a 64-bit value belonging to the device namespace (0x0018), stored locally as a hexadecimal string and frequently displayed externally in the compact g:decimal form. Recognizing these equivalent representations is essential for correctly interpreting registry data, telemetry, and any public discussion of the identifier.

How the Microsoft Device PUID relates to hardware identifiers

Core Distinction: Installation Identity vs. Hardware Fingerprint

The Device PUID is not a hardware identifier and is not computed from hardware data on the client.

• It is a 64-bit value assigned by Microsoft’s identity servers (via endpoints such as login.live.com) during device provisioning, typically when Windows contacts Microsoft Account services.
• Windows stores the returned value locally (as a hexadecimal string under HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID) but does not generate it from local hardware measurements.
• Evidence that it is installation-scoped rather than hardware-scoped: a clean reinstall of Windows produces a new Device PUID/GDID, even if the underlying motherboard, disks, TPM, and network adapters remain unchanged. A pure hardware hash would regenerate the same result under identical hardware conditions.

In Microsoft’s own description (from court filings), it is “a persistent, device-level identifier designed to uniquely identify an installation of a Windows operating system on a device… across certain Microsoft services and scenarios.” The key phrase is “installation of a Windows operating system,” not the physical hardware itself.

What Hardware Identifiers Actually Are

Windows and Microsoft services use several categories of hardware-derived identifiers for different purposes:

These are deterministic or semi-deterministic fingerprints of the physical (or virtual) machine. CHIDs, for example, are ranked sets of GUIDs generated every boot from different combinations of SMBIOS fields; lower-numbered CHIDs are more specific.

How Device PUID and Hardware Identifiers Interact

Although the Device PUID itself is server-assigned and installation-scoped, the provisioning process that requests it transmits hardware descriptors. Technical analyses of the network traffic (SOAP requests from wlidsvc to Microsoft identity endpoints) show that the client includes component tags containing:

• System manufacturer and product name
• SMBIOS system serial and UUID
• Disk serial numbers
• MAC addresses and related network adapter details
• TPM-related information
• Additional undocumented or partially documented values

Microsoft’s servers receive this hardware context when minting or associating the Device PUID. On the server side, the identity graph (Device Directory Service) can therefore link:

• A particular Device PUID (installation identity)
• To one or more hardware fingerprints
• And to Microsoft Account user identifiers

This creates a durable association even though the PUID value itself is not a hash of the hardware. The same physical machine can receive a new PUID after reinstallation, yet server-side records may still correlate the new installation with prior hardware signatures and account activity.

In licensing and activation flows, Windows separately sends a hardware hash. Digital licenses are often bound both to the Microsoft Account and to hardware characteristics; the Device PUID participates in the broader device-graph identity that supports Store, licensing, and cross-device features.

Practical Implications of the Relationship

• Reinstallation behavior: New OS install → new Device PUID. Hardware identifiers remain stable if components are unchanged. Server-side history associated with the old PUID is not automatically erased.
• Hardware changes: Replacing major components (motherboard, TPM, primary disk, etc.) can alter hardware hashes and CHIDs. The existing Device PUID on that installation generally continues until the OS is reinstalled or the identity state is reset.
• Virtual machines and clean installs: A new VM or a freshly imaged physical machine receives its own Device PUID upon contacting Microsoft services. The value is not predetermined by the hypervisor or physical host hardware.
• Local accounts vs. Microsoft Account: Some analyses indicate an anonymous or fallback device-registration path exists even without a full Microsoft Account sign-in, still resulting in a Device PUID. Full account provisioning strengthens the linkage.
• Forensic and tracking context: Combining a Device PUID with hardware fingerprints, account identifiers (user PUIDs/CIDs), and telemetry creates a robust cross-service identity. Changing IP addresses (VPN, etc.) does not alter either the PUID or the underlying hardware signatures.

Important Things to Know About the Device PUID

Several points are worth highlighting because they affect real-world expectations, mitigation attempts, and risk assessment.

1. It Can Appear Even Without a Microsoft Account

Early analysis assumed a full Microsoft Account sign-in was required. Later research corrected this: the Connected Devices Platform (CDP) maintains an anonymous device registration path.

As a result, a Device PUID / GDID can still be generated and registered on installations that use only a local account. Completely avoiding the identifier therefore requires more than simply declining to sign in with a Microsoft Account.

2. Local Deletion Is Cosmetic

Deleting the registry value (HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties\LID) does not permanently remove the identifier.

• When the value is tied to a Microsoft Account, Windows can re-fetch the same Device PUID from Microsoft’s servers the next time identity or Store-related components contact the backend.
• Background services (wlidsvc, CDP components) can recreate or restore related state.
• Server-side records remain untouched by any local change.

A clean OS reinstall is the reliable way to obtain a new local value; it does not erase historical server-side associations.

3. One Account Can Accumulate Multiple Device PUIDs

Because each clean installation receives its own Device PUID, a single Microsoft Account can be linked over time to multiple GDIDs (one per installation or reinstall). Microsoft’s systems are capable of correlating these successive identifiers back to the same account.

4. Server-Side History Outlives the Local Value

Even after a reinstall produces a new Device PUID, prior records associated with the old identifier remain on Microsoft’s infrastructure. Signing back into the same Microsoft Account after a reinstall gives the backend a clear opportunity to link the new installation to the previous identity history.

5. Practical Mitigation Attempts Have Clear Trade-offs

Community tools and techniques have emerged that attempt to:

• Disable or restrict the Connected Devices Platform and Delivery Optimization services
• Block selected Device Directory Service / reporting endpoints (via hosts file or firewall rules)
• Wipe known local identity caches

These approaches can reduce future reporting of the identifier. They do not:

• Erase existing server-side records
• Prevent Microsoft from already possessing the identifier
• Leave the full Microsoft ecosystem (Store, account sign-in, OneDrive, Xbox, Phone Link, etc.) fully intact in most cases

Blocking the core identity endpoints (especially those required for Microsoft Account authentication) tends to break sign-in and dependent features. There is no clean, official, zero-impact opt-out.

6. Official Visibility Remains Minimal

Microsoft’s public documentation of the identifier is extremely limited—primarily a brief description of GlobalDeviceId in Azure Monitor / Delivery Optimization schemas as an internal Microsoft device identifier. There is no consumer-facing privacy control, settings page, or detailed explanation equivalent to the controls offered for advertising IDs or diagnostic data.

7. Combination Risk

The Device PUID becomes significantly more powerful when combined with other signals that Windows or Microsoft services already possess or receive:

• Microsoft Account identifiers (user PUIDs / CIDs)
• Hardware descriptors transmitted during provisioning
• IP addresses, timestamps, and service-specific logs

Alone it identifies an installation; in combination it supports stronger attribution.

Bottom Line

The most important additional realities are:

• A local account does not guarantee absence of a Device PUID.
• Local deletion or simple registry edits do not eliminate it.
• Server-side history and account linkage survive reinstalls.
• Effective reduction of future reporting usually requires accepting functional trade-offs in Microsoft services.
• The identifier has already demonstrated real-world investigative utility.

These points complete the practical picture: the Device PUID is a durable, server-anchored installation identifier that is harder to avoid or fully neutralize than many users initially assume, while remaining scoped to Microsoft’s own ecosystem rather than serving as a universal tracking cookie.