TPM and Windows Hello for Business: Require It, Diagnose It, and the Firmware-TPM Traps

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."

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.

These are the fields that matter from that output, decoded:

The fix, part 1: require the TPM

Configure it via Intune (Settings Catalog)

1. Sign in to the Intune admin center.
2. Go to Devices › Configuration (under Manage devices), then select Create › New Policy.
3. Set Platform to Windows 10 and later, and Profile type to Settings catalog. Select Create.
4. Give the profile a name (for example WHfB - Require TPM), then select Next.
5. Select Add settings, search for Windows Hello for Business in the settings picker, and tick Require Security Device. Close the picker.
6. Set Require Security Device to True. Optionally also add Exclude Security Devices › TPM 1.2 and set it to True if you want to keep old TPM 1.2 hardware out of scope.
7. Select Next, assign the profile to a pilot group first (not All devices), then Next › Create.

Configure it via Group Policy

1. On a management workstation or domain controller, open the Group Policy Management Console (gpmc.msc).
2. Right-click the organizational unit (OU) containing your target computer objects and select Create a GPO in this domain, and Link it here.... Name it (for example WHfB - Require TPM).
3. Right-click the new GPO and select Edit to open the Group Policy Management Editor.
4. Navigate to Computer Configuration › Administrative Templates › Windows Components › Windows Hello for Business.
5. Double-click Use a hardware security device, set it to Enabled, and select OK.
6. Close the editor. The policy applies at the next Group Policy refresh (or run gpupdate /force on a test machine to apply it immediately).

Both channels write the same underlying setting to different registry roots. Here is the full reference table for all four values:

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-Tpm report TpmPresent : 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.

Here is a real run of Get-TpmWhfbHealth.ps1 from this series, against a device that has a healthy TPM but has not yet had RequireSecurityDevice enforced - exactly the borderline case this post is about:

Read this exactly the way the earlier sections describe: the TPM itself is healthy and not locked out, so nothing is currently broken, but RequireSecurityDevice is not enforced, so this device's Hello credential is hardware-backed by luck, not by policy. Enforcing the setting from "The fix, part 1" above turns this from a lucky pass into a guaranteed one.

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

Want this checked automatically across the fleet instead of one device at a time? Below is a matching Intune Proactive Remediation pair: a detection script that flags TPM lockout and unenforced RequireSecurityDevice fleet-wide, and a remediation script that is deliberately report-only - it logs the finding to a CSV and the Application event log rather than silently patching policy or clearing a TPM, because neither of those is safe to automate blind.