Everything that makes Windows Hello for Business (WHfB) more secure than a password comes down to one chip: the Trusted Platform Module (TPM). The TPM is what makes the private key unexportable - it never leaves the hardware, so a stolen credential cannot be replayed on another machine. But the TPM is also where a surprising number of Hello problems start: software-key fallback you did not intend, a lockout that blocks PIN entry, and firmware-TPM quirks on consumer hardware. This post explains how WHfB uses the TPM, how to require it properly, and how to diagnose the TPM-side failures.
The problem: "Hello isn't asking for hardware"
Two failure shapes bring admins here. The first is silent and dangerous: WHfB provisioned a credential in software because the device had no usable TPM, and nobody required hardware - so the "unexportable key" security guarantee simply is not there. The second is loud: a user cannot enter their PIN at all, or Hello throws errors, because the TPM has gone into lockout after too many failed operations. Same chip, opposite symptoms.
Why it happens: the TPM is optional unless you make it mandatory
During provisioning, WHfB generates the credential's key pair and, if a TPM is present, the TPM generates and seals the private key so it can never be exported. If the device has no usable TPM, WHfB will - by default - fall back to generating and encrypting the key in software. That fallback keeps Hello working on TPM-less hardware, but a software key does not carry the anti-theft guarantee. The default is "prefer TPM, accept software," and only a policy makes it "require TPM."
RequireSecurityDevice), some of your fleet may be running WHfB on software keys and you would never know from the portal. On those devices the credential is no more hardware-bound than a stored secret. Require the security device explicitly - do not assume every device provisioned into the TPM.How WHfB uses the TPM
The mechanics are worth understanding because they explain both the security and the failure modes. The credential's protector key (tied to your PIN or biometric) performs a TPM seal operation using the gesture as entropy - so the key can only be released on this TPM, by this gesture. TPM-enabled devices also generate an attestation block proving the key really lives in hardware. That seal is the anti-replay property: move the on-disk data to another machine and it is useless, because the sealing TPM is not there.
How to verify: diagnose the TPM state
Get-Tpm is the one command that answers "is the TPM present, ready, and healthy?" The fields that matter: TpmPresent, TpmReady, and the lockout fields:
If LockedOut : True, the TPM has seen too many failed authorisation attempts and has throttled itself - that is why the PIN is being rejected. Most TPMs self-heal after a cooldown (LockoutHealTime); the fix is usually to wait, not to reset anything. A cleared or reset TPM, by contrast, destroys the sealed keys and forces re-provisioning of Hello for every user on the device - so clearing the TPM is a last resort, not a first step.
The fix, part 1: require the TPM
The Intune Settings Catalog toggle lives here:
Set the hardware-security-device policy so provisioning only happens on a usable TPM, and optionally exclude TPM 1.2:
| Channel | Setting | Value |
|---|---|---|
| Intune (Settings Catalog) | Windows Hello for Business › Require Security Device | true |
| CSP | .../PassportForWork/{TenantId}/Policies/RequireSecurityDevice | True |
| CSP (exclude 1.2) | .../PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12 | True |
| Group Policy | Computer Config › Admin Templates › Windows Components › Windows Hello for Business › Use a hardware security device | Enabled |
Group Policy writes the requirement to the registry, which is where you can confirm it actually applied:
The fix, part 3: know the firmware-TPM quirks
Many business laptops do not have a discrete TPM chip - they use a firmware TPM baked into the CPU: Intel Platform Trust Technology (PTT) or AMD firmware TPM (fTPM). These are legitimate TPM 2.0 implementations, but they have known real-world quirks:
- Some AMD fTPM firmware caused system stutter until a firmware update - and the update can clear the fTPM, wiping Hello credentials, if not handled carefully.
- PTT/fTPM can be disabled in BIOS/UEFI, which makes
Get-TpmreportTpmPresent : False- and then WHfB either falls back to software or (if you required hardware) refuses to provision. - A BIOS update or a "clear TPM" toggle in firmware silently invalidates every sealed key on the box.
Proof it worked
A correctly hardware-backed device shows Get-Tpm with TpmPresent : True, TpmReady : True, LockedOut : False; the WHfB policy shows RequireSecurityDevice enforced; and provisioning succeeded (so the key is sealed in hardware, not software). On a TPM-less device with the requirement enforced, Hello correctly does not provision - which is the intended, secure result.
Get-Tpm across the fleet first: any device reporting TpmPresent : False or TpmReady : False is a candidate for a software-key Hello credential today. Fix the TPM state (enable PTT/fTPM in firmware, update firmware) on those devices before you flip RequireSecurityDevice, so you harden the credential rather than just knocking those users off Hello.References
- WHfB policy settings - Use a hardware security device (RequireSecurityDevice)
- How Windows uses the Trusted Platform Module
- How Windows Hello for Business works (container, TPM seal)
- Trusted Platform Module documentation
Script for this post is in Daily-Tasks.