How to Find a Windows Product Key (Including Embedded OEM Keys)

A machine needs a rebuild, the sticker is long gone, and the ticket says "find the Windows key" as if it were one thing. There are four places a Windows licence can live, and the right command depends on which one you have. This guide covers how to find a Windows 10 product key (and a Windows 11 one) from the firmware, from the registry and from Microsoft's own records, and what to do when every method comes back empty.

The Four Kinds of Windows Licence

Microsoft's own support page lists where a product key comes from by how you got Windows: a new PC, a boxed copy, a digital purchase, a free upgrade, a volume agreement. For a technician, that list collapses into four cases, and each one answers "where is the key" differently.

The thing to know before you run anything: a digital licence has no key to find. Microsoft's activation page (updated September 2025) describes it as "a method of activation in Windows 11 that doesn't require you to enter a product key". If Settings shows a digital licence, the search is over before it starts, and the fix is to link a Microsoft account, not to hunt for 25 characters.

Pull the Firmware Key From an OEM Machine

Since Windows 8, manufacturers have embedded the product key in the firmware under a scheme Microsoft calls OEM Activation 3.0. The key sits in the ACPI table of the motherboard and Windows reads it during setup, which is why a clean install on a Dell or Lenovo activates with no sticker and no typing.

Windows exposes that key through the Software Licensing Service. Two commands return it.

powershell
# PowerShell (works on Windows 10 and 11, including 24H2 where wmic is gone)
(Get-CimInstance -ClassName SoftwareLicensingService).OA3xOriginalProductKey

cmd
:: Command Prompt, older builds that still ship wmic
wmic path SoftwareLicensingService get OA3xOriginalProductKey

A blank line is a result too. It means the firmware carries no key: the machine was never sold with Windows preinstalled, or it was built from parts, or the board was replaced. A blank answer on a machine that is activated points to one of the other three cases.

One caveat that catches people who read the number and stop: the firmware key is the key the machine shipped with. If someone upgraded Home to Pro through the Store, or entered a retail key later, the firmware key still says Home. It tells you what the manufacturer sold, not what is running.

Read What's Installed With slmgr

slmgr.vbs is the script Microsoft ships for the Software Licensing Service, and its display switches don't need elevation. Three are worth memorising.

cmd
slmgr /dli
slmgr /dlv
slmgr /xpr

/dli shows the edition, the licence channel and the last five characters of the installed key. Microsoft's reference describes it as licence information "for the installed active Windows edition". Those five characters are enough to match a key against a record in your documentation or a reseller's order history, and they're all Windows will show you for a retail key, because the full key is deliberately not kept in a readable place.

/dlv is the verbose version, and the line to read is the one that names the channel: Retail, OEM:DM (the firmware key), Volume:GVLK (a KMS client) or Volume:MAK. That one word tells you which of the four cases you're in.

/xpr shows the activation expiry. Microsoft notes it is "primarily useful for KMS clients, because MAK and retail activation is perpetual". On a KMS client you'll see a date; on anything else, "permanently activated".

For a one-liner that pairs the installed edition with the firmware key, the PowerShell below reads both classes at once. It's the same pair a sysadmin on r/sysadmin was scripting in March 2025 when their output said Pro on machines that had been upgraded in place to Enterprise, which is the firmware-key caveat again: OA3xOriginalProductKey reports what shipped, SoftwareLicensingProduct reports what's licensed now.

powershell
$lic = Get-CimInstance SoftwareLicensingProduct -Filter "Name like 'Windows%'" |
       Where-Object { $_.PartialProductKey }
[pscustomobject]@{
  Edition    = $lic.Name
  Channel    = $lic.ProductKeyChannel
  Last5      = $lic.PartialProductKey
  Status     = $lic.LicenseStatus      # 1 = licensed
  FirmwareKey = (Get-CimInstance SoftwareLicensingService).OA3xOriginalProductKey
}

When the Key Is "Not Available"

Three situations produce an empty result, and they need three different answers.

The firmware returns nothing and Settings says digital licence. This is the common one on a machine that took the free Windows 10 or 11 upgrade, or had a key entered once and then forgotten. The licence is tied to the hardware hash on Microsoft's side, and the only thing worth doing is linking a Microsoft account to it in Settings. Microsoft's activation page is explicit that linking is what lets the Activation troubleshooter reactivate the machine after a motherboard swap. Document the account, not a key.

The firmware returns a key, but the machine won't activate with it. A sysadmin on r/sysadmin lost activation on twelve OEM-licensed blades after the 24H2 update in January 2025, and OA3xOriginalProductKey came back empty while the registry showed a different key than the one that had activated them. The thread below is a useful warning that firmware keys are read at install, and that a later edition upgrade or board change can leave the registry and the firmware disagreeing. In that case the answer was the original keys from the purchase records, which is the point of keeping them.

It's a retail key and nobody kept the card. Microsoft's support page (updated February 2026) says it plainly: Microsoft only keeps a record of product keys bought from the Microsoft online store, visible under Order history in the Microsoft account. A key bought from any other retailer lives in that retailer's order email or digital locker. If the box, the email and the locker are all gone, there's no recovery route, and the clean option is to activate with the digital licence the machine already earned the first time that key was used.

Fleets: KMS, MAK and the Key You Never Type

Once the count passes a handful of machines, nobody should be reading keys off firmware. Volume activation replaces the per-device key with one of three methods, and each one changes what "find the key" means.

KMS. Client machines carry a Generic Volume License Key (GVLK), which is public and identical on every device of that edition, and activate against a KMS host on your network. The host needs a Customer Specific Volume License Key (CSVLK) from the Volume Licensing Service Center. Microsoft's planning guide (updated 2025) sets the activation threshold at 25 client machines, or 5 servers, before the host will activate anything, and slmgr /xpr on a client shows when its 180-day activation next needs renewing. The "key" on a KMS client is nothing to find; the key that matters is on the host.

MAK. A Multiple Activation Key activates against Microsoft directly, a fixed number of times. Microsoft's guide describes it as working "like a retail key, except that a MAK is valid for activating multiple computers", and points to it for machines that are isolated or too few to reach the KMS threshold. The MAK lives in the VLSC and in whatever you pushed it with; slmgr /dlv on a client shows Volume:MAK and the last five characters.

Active Directory-based activation. Domain-joined machines activate against an activation object in the forest instead of a KMS host, and Microsoft's guide only asks that they touch a domain controller once every 180 days. No key on the device at all.

The thread below is the fleet version of this whole post: an admin unwinding Enterprise E3 back to Pro, planning to pull the firmware key with OA3xOriginalProductKey and re-inject it with slmgr /ipk. The useful replies point at Microsoft's subscription activation docs, which say the E3 step-up reads the firmware Pro key underneath and steps back down on its own, and warn that a key pushed with /ipk puts a machine on a KMS or MAK channel that unassigning a licence group won't undo. Run slmgr /dli first and read the channel before touching anything.

Inventory the Keys Before the Audit Asks

The cheap version of all of this is to collect the channel, the last five characters and the firmware key from every machine once, and keep it next to the purchase records. That turns the next rebuild from a search into a lookup, and it's the Windows row of a software license audit answered before anyone sends a letter.

The script below runs on any Windows 10 or 11 device and writes one line per machine. Push it through whatever you use to run scripts across a fleet; OpenFrame can run it across a client's devices and collect each machine's output in one place.

powershell
$lic = Get-CimInstance SoftwareLicensingProduct -Filter "Name like 'Windows%' and PartialProductKey is not null"
$svc = Get-CimInstance SoftwareLicensingService
[pscustomobject]@{
  Device      = $env:COMPUTERNAME
  Edition     = $lic.Name
  Channel     = $lic.ProductKeyChannel
  Last5       = $lic.PartialProductKey
  Licensed    = ($lic.LicenseStatus -eq 1)
  FirmwareKey = $svc.OA3xOriginalProductKey
  KmsHost     = $svc.KeyManagementServiceMachine
} | ConvertTo-Csv -NoTypeInformation

Two rows deserve a second look when the CSV comes back: a Retail channel with no matching purchase record, and an OEM:DM channel whose firmware key is blank. The first is a key you can't prove you own; the second is a machine that will not reactivate itself after a board swap. Both belong in the same place the IT asset lifecycle records live, because the licence outlasts the hardware in one case and dies with it in the other.

Here's a short walkthrough of the Settings and command-line routes on Windows 11 for anyone who wants to see them on screen:

The Short Version

Check Settings first: if it says digital licence, link a Microsoft account and stop looking for a key. On an OEM machine, read the firmware with OA3xOriginalProductKey. On everything else, slmgr /dlv tells you the channel and the last five characters, and the purchase record holds the rest. On a fleet, the key lives on the KMS host or in the VLSC, not on the device.

If the search started because a machine needs a fresh install, the factory reset guide covers the reinstall paths that keep the activation, and the PowerShell commands post has the rest of the licensing queries sorted by the ticket you're on.