How to Change Your HWID in Windows (2026)

To change your HWID, you have to change enough of the identifiers that form the machine's fingerprint, not edit one universal number. Windows can alter OS-generated values such as MachineGuid, a volume serial, or a network-adapter override, but normal Windows settings cannot rewrite the firmware identifiers stored by the motherboard, drives, NIC, and TPM. A complete change therefore requires the relevant set to move together and stay changed after a reboot.

What people mean by "changing your HWID"

HWID is shorthand for a composite hardware identity. It is a collection split between values supplied by firmware and devices, which Windows mostly reads, and values generated by Windows, which the operating system can replace. If you need the vocabulary behind that distinction, start with the full anatomy of a hardware ID.

That split resolves the argument you see in forum threads. A registry value can be changed, so the claim that no part of an HWID can ever change is too broad. The opposite claim, that one registry edit gives the computer a new hardware identity, is equally misleading because the firmware tier stays where it was.

The useful question is not whether a displayed number changed. Ask which layer produced that number, what else still identifies the machine, and whether the change survives a driver reset, a Windows reinstall, and a reboot. Most manual methods reach one input. A hardware fingerprinting system can read many.

The two tiers, and why only one of them matters

The firmware and device tier begins below Windows. SMBIOS exposes the motherboard UUID, baseboard serial, and SMBIOS/BIOS serial from platform firmware. A drive controller reports the disk firmware serial.

A NIC carries a burned-in MAC address in EEPROM, while a TPM 2.0 device has an endorsement key rooted in the security hardware. CPU and GPU device identifiers can add context, although many identify a model or device class rather than a unique unit.

Secure Boot belongs in the collection too, but its state is a trust signal rather than a unique serial. Windows can report whether Secure Boot is enabled; toggling it does not create a new motherboard identity. The TPM 2.0 endorsement key is also different from a registry GUID: applications can request evidence tied to the TPM, but regedit cannot replace that hardware root.

The OS tier contains MachineGuid at HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid, HwProfileGuid under HKLM\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\0001, and MachineId at HKLM\SOFTWARE\Microsoft\SQMClient\MachineId. It also includes the volume serial (sometimes shown as VolumeID), machine SID, product ID, and computer name. These values are real inputs, but they describe a Windows installation or volume, not the physical board or drive controller.

A disk serial and a volume serial are especially easy to confuse. Win32_DiskDrive.SerialNumber reports the drive controller's firmware value. The volume serial is a short identifier in a partition's boot sector. Changing the second does nothing to the first.

The same layer distinction explains what identifier rewriting actually involves.

Read your current values first

Take a baseline before judging any method. The commands below only read values; none changes hardware, firmware, the registry, or an adapter setting. Save the results somewhere separate from any disk you may later reformat, and do not publish the output because several entries are stable device identifiers.

The legacy examples are included so you can recognize older guides. wmic is deprecated on current Windows builds and may not be installed, which is why the Get-CimInstance forms come first. If the values point to a possible hardware-level restriction, the work out which identifiers are likely in play flow can help you separate an HWID problem from another ban type.

1. Open PowerShell as administrator so the read queries can see the relevant system classes.

2. Read the SMBIOS system UUID. The legacy form is shown on the second line.

   Get-CimInstance Win32_ComputerSystemProduct | Select-Object UUID
   wmic csproduct get uuid

3. Read the baseboard product and serial number.

   Get-CimInstance Win32_BaseBoard | Select-Object Product, SerialNumber
   wmic baseboard get product,serialnumber

4. Read the BIOS serial.

   Get-CimInstance Win32_BIOS | Select-Object SerialNumber
   wmic bios get serialnumber

5. Read every disk firmware model and serial.

   Get-CimInstance Win32_DiskDrive | Select-Object Model, SerialNumber
   wmic diskdrive get model,serialnumber

6. Read the C: volume serial.

   cmd /c vol C:

7. Read the MAC address and status of each network adapter.

   Get-NetAdapter | Select-Object Name, MacAddress, Status
   getmac /v

8. Read MachineGuid without editing it.

   reg query "HKLM\SOFTWARE\Microsoft\Cryptography" /v MachineGuid

9. Save the complete output to a text file on a USB drive or another separate location. PowerShell's Out-File can capture command output without changing the identifiers being queried.

Every method, and what it actually reaches

The deciding test is coverage, not whether one utility reports a different string. This map shows which layer each common method reaches and what remains available to a composite fingerprint.

A MachineGuid change is genuine, but narrow. It replaces one installation GUID and leaves the motherboard tables, disk controller serials, burned-in MAC, and TPM identity untouched. Guides that point to HwProfileGuid or HKLM\SOFTWARE\Microsoft\SQMClient\MachineId have the same limitation: they operate inside the OS tier. They do not make firmware recalculate anything.

The adapter route writes a NetworkAddress property that the driver applies when the interface binds. Traffic may use the presented address, yet the factory value remains in the NIC EEPROM and can still be exposed through a path that does not rely on that override. Resetting the adapter, replacing its driver, or reinstalling Windows can remove the property. The change is easy to undo without noticing.

Volume-serial tools create a different trap. They can rewrite the short volume identifier stored in the partition boot sector, often called VolumeID, while the drive firmware serial reported through WMI stays identical. Seeing a new result from the volume command proves only that the partition value moved. It says nothing about the physical drive identity.

A clean installation deserves only one row here because it is a separate decision. The identifier-survival breakdown in which of these a Windows reinstall changes on its own shows why formatting can remove installation residue without replacing the firmware tier.

Why partial changes do not hold

A fingerprint comparison is a similarity problem. If one input changes while most of the SMBIOS, storage, network, and platform inputs remain stable, the resulting set can still resemble the stored machine closely. The actual inputs, weights, and threshold are private to each anti-cheat. Anyone promising an exact minimum is guessing.

Partial rotation can also create a recognizable pattern: OS-generated GUIDs keep moving while the motherboard UUID, BIOS serial, and disk firmware serial never do. BattlEye reads a set, not a single value, and the same composite principle explains why a changed MAC alone is weak evidence of a new machine. The list of the titles that enforce hardware-level bans spans several engines and publishers, each with its own enforcement rules.

Engines used by more than one title can collect the same classes of identifier across their rosters, so reuse of a flagged machine creates cross-game exposure. Ban lists remain publisher-controlled, however; a ban in one game does not automatically ban every title using the same engine. The narrower point is that rotating one Windows value does not erase the stable device values available elsewhere.

Reversion makes manual changes weaker again. A driver update can discard an adapter override, and a reinstall regenerates installation GUIDs and volume metadata while rediscovering the same firmware underneath. A value surviving one reboot proves persistence for that value only. It does not prove the composite identity stayed changed.

What a full change actually requires

Three properties separate a full change from a collection of tweaks: coverage, simultaneity, and persistence. Coverage means moving every supported input in the relevant fingerprint rather than one convenient GUID. Simultaneity means the set changes coherently in one pass instead of drifting through a series of partial profiles. Persistence means the rewritten values survive a restart without a resident process.

A temporary, per-session approach fails that last test. Its presented values depend on the tool being available and reapplying them after boot, so the old identity can return when the session layer is absent. The deeper comparison of why persistence is the property that matters explains the operational difference without treating a changed screen as proof.

TraceX Spoofer is designed around the persistent model: it rewrites the supported identifier set in one pass. You run TraceX once, restart, verify that the values remain changed, and delete the tool. There is no daemon or background session to preserve.

If your read-only baseline shows that the full hardware set is the problem, you can move the whole set in one pass. Setup is one-time.

A rewrite does not remove an account sanction, reverse a server-side finding, or guarantee access to a particular game. It changes the machine-side identifiers available for future comparison. Keeping that boundary clear prevents you from blaming the hardware layer for an account-level restriction.

The risks worth taking seriously

Windows activation uses a hardware-derived hash, so substantial identifier changes can trigger reactivation. The outcome depends on the licence and account state; do not assume it will fail or recover automatically. Record your activation details and make sure you have a legitimate recovery path before changing anything.

Registry edits carry a more ordinary risk. If you overwrite an original GUID without recording it, you may be unable to restore the previous state cleanly. A typo in an unrelated key can also break the component that reads it. That is why this guide provides an audit procedure, not a sequence of registry write commands.

Low-level methods deserve a firmer boundary. Firmware flashing can brick a board, and driver-loading techniques can destabilize Windows or weaken its security model. This post gives no steps for either, no TPM-clear procedure, and no way around driver protections. The guide to the real risk profile of low-level identifier writes separates normal restart and activation concerns from methods that can damage the system.

The useful standard is simple: preserve a read-only baseline, know which tier a method touches, and reject any claim that treats one changed field as a new computer. A complete result is visible across the set and remains there after the reboot.