generating a device‑related identifier

Hi @Anjali Narvekar ,

Thanks for reaching out.

The currently recommended API is
SystemIdentification.GetSystemIdForPublisher()
from the Windows.System.Profile namespace.
→ Official method documentation: https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentification.getsystemidforpublisher

This has emerged as the preferred choice:

• It generates a stable, device-bound ID that is scoped to your publisher (all apps published by you on the same device will see the same ID; apps from other publishers will see completely different values).
  → Explanation of publisher scoping & uniqueness: https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentification.getsystemidforpublisher#remarks
• The ID survives most real-world changes: app reinstalls, Windows upgrades, restarts, and — in the majority of cases — even full clean installs of Windows.
  → Persistence / durability documented here: https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentification.getsystemidforpublisher#remarks
• It is generated from the most stable sources the system can access (in priority order):
  1. TPM (Trusted Platform Module) → highest stability
  2. UEFI firmware → still very reliable
  3. Registry fallback → least persistent (can change after a clean Windows install or major reset)
     → Detailed explanation of each source (Tpm, Uefi, Registry): https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentificationsource

You should always check the .Source property to understand how trustworthy the ID is on that particular machine.

Here’s a simple code sample:

using Windows.System.Profile;
using Windows.Security.Cryptography;

var info = SystemIdentification.GetSystemIdForPublisher();

if (info == null || info.Source == SystemIdentificationSource.None)
{
    // Rare case — treat as new/unknown device
    return null;
}

string deviceId = CryptographicBuffer.EncodeToHexString(info.Id);
// or: string deviceId = Convert.ToBase64String(info.Id.ToArray());

string source = info.Source.ToString(); // "Tpm", "Uefi", or "Registry"

// Typically send both deviceId + source to your server

• If Source is Tpm or Uefi → treat the ID as highly reliable and use it as the main license key
• If Source is Registry → treat it as temporary (consider allowing a one-time reactivation or additional verification)
  → Guidance on handling different sources: https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.systemidentification.getsystemidforpublisher#remarks

It’s far too sensitive to driver updates, CPU microcode patches, storage controller changes, etc.

→ HardwareIdentification class reference (notice the reduced recommendation): https://learn.microsoft.com/en-us/uwp/api/windows.system.profile.hardwareidentification

Give it a try on a few different machines (ones with TPM and some older ones without) and check what. values you’re getting. If anything looks unexpected (e.g., mostly falling back to Registry or IDs changing unexpectedly), just reply with more details (Windows build, device type, Source value) and I’ll help dig deeper.

Hope this clears things up and gives you a solid path forward!

Hi

How can i trust the SystemIdentification API for my UWP app which is already in production for a long time with millions of users using it. Do you have any insights on any other public applications which are using this API.

Also in case I decide to go ahead with this API, can you suggest which all windows OS hardware models and connected devices I need to test before rolling out in production

For generating a stable and reliable per-device identifier in UWP applications, you can consider the following Microsoft-supported APIs:

1. SystemIdentification: This API is indeed a preferred option for generating device-related identifiers. It provides a unique system identifier based on the app publisher ID or user ID. You can use the GetSystemIdForPublisher method to obtain an identifier that is specific to the app publisher on the current device. This identifier is unique for each system and persists across restarts, reinstalls, and upgrades of Windows, making it suitable for licensing tied to a device.
2. Identifiers from System Firmware: Identifiers derived from system-provided firmware information, such as those obtained from the Trusted Platform Module (TPM) or Unified Extensible Firmware Interface (UEFI), are appropriate in UWP. These identifiers are designed to be stable and can provide a reliable means of uniquely identifying a device.
3. Publisher-Scoped Identifiers: UWP apps should consider using publisher-scoped identifiers as they ensure that the identifier is unique to the publisher across all users on that device. This approach helps maintain a consistent association between the app and the device, which is crucial for scenarios like licensing.

In summary, using the SystemIdentification API along with identifiers from system firmware is a recommended approach for achieving a stable device association in UWP applications.