Auditing Windows Hello for Business: Passwordless Posture Done Right

How to verify Windows Hello for Business is enforced, key-based, and not silently falling back to convenience PINs or passwords.

Windows Hello for Business (WHfB) is Microsoft's answer to the password: a phishing-resistant, hardware-bound credential that lives in the TPM and never travels the wire. On paper it's the single biggest lift you can give an endpoint's identity posture. In practice, a lot of "passwordless" deployments are passwordless in name only — the policy is configured but not enforced, keys land in software instead of the TPM, and the old password stays fully usable as a silent fallback. This post is about auditing the gap between "we turned Hello on" and "an attacker actually can't replay a stolen password."

Why WHfB is worth auditing

A traditional password is a shared secret: it can be phished, sprayed, relayed, and replayed from anywhere. WHfB replaces it with an asymmetric key pair. The private key is generated on the device, protected by the TPM, and released only after a local gesture (PIN or biometric). The gesture unlocks the key on that machine — it is not a password sent to a server. That's what makes WHfB phishing-resistant: there is no reusable secret to steal.

But three misconfigurations quietly erase most of that benefit:

Software key fallback. If the TPM is missing, disabled, or the policy allows it, the key can be generated in software — where it can be exported by a sufficiently privileged attacker. Hardware attestation is the whole point; losing it means WHfB is just a nicer login screen.
Password not disabled. WHfB provisioning does not automatically retire the password. Unless you explicitly remove the password credential provider, the account's password remains valid for RDP, network logons, and pass-the-hash — so the phishable secret you meant to eliminate is still live.
Weak PIN policy. The convenience PIN is device-local, but a 4-digit numeric PIN with no lockout undermines the gesture that guards the key. PIN complexity and TPM anti-hammering are what keep a stolen laptop from being brute-forced.

Where the posture actually lives

WHfB policy is expressed as registry values under the PassportForWork key, pushed by GPO or MDM. The signal you want is not "is there a policy blob" but "do the effective values enforce hardware, disable the password, and set a sane PIN policy." The keys that matter:

HKLM\SOFTWARE\Policies\Microsoft\PassportForWork
  Enabled            = 1     ; WHfB provisioning is on
  RequireSecurityDevice = 1  ; TPM required, no software key fallback
  UsePassportForWork = 1

HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\PINComplexity
  MinimumPINLength   >= 6
  Digits             = 1
  UppercaseLetters   = 2 (allowed) / lowercase / special as policy dictates
  History            >= 0

And the fallback you want gone — the password credential provider — is controlled separately (and via AllowDomainPINLogon / "Turn on convenience PIN sign-in" it can be re-enabled by accident). A real audit checks all three planes together, because any one of them left open reopens the phishable path.

Confirm the key is really in the TPM

Configuration says the TPM is required; attestation tells you whether it was actually used. On a provisioned device:

certutil -user -key -csp "Microsoft Passport Key Storage Provider"

A healthy result lists the WHfB key backed by the Passport KSP, which brokers to the TPM. If keys show up under a software KSP, hardware protection was skipped — treat that as a finding even when RequireSecurityDevice reads 1, because a machine may have been provisioned before the policy tightened. Pair this with TPM presence and readiness (2.0, owned, not in a reduced-functionality state) so you know the hardware root of trust is genuinely available.

The checklist WinSentinel runs

WinSentinel's identity and encryption audit modules roll these into concrete, single-machine findings so you don't have to eyeball registry values by hand:

WHfB enabled and enforced — provisioning on, and RequireSecurityDevice = 1 so there is no software-key escape hatch.
TPM 2.0 present, owned, and ready — the hardware root WHfB depends on (cross-checked with the encryption module's TPM and BitLocker findings).
PIN complexity — minimum length ≥ 6 and a policy that isn't just four digits, so the local gesture is defensible.
Password fallback posture — flags when the account password is still a fully usable network credential, i.e. the phishable secret WHfB was supposed to retire is still live.
Convenience PIN sign-in — catches the accidental re-enable that downgrades a hardware-bound credential back to a soft one.

Each finding maps to CIS and NIST identity controls and carries a remediation, so a "passwordless" rollout can be verified instead of assumed. Run it locally with:

winsentinel audit --module identity
winsentinel audit --module encryption

The takeaway

Passwordless is a posture, not a checkbox. The value of Windows Hello for Business comes entirely from three properties holding at once: the key is in hardware, the PIN that guards it is strong, and the old password is no longer a usable fallback. Miss any one and you've bought a friendlier login screen, not phishing resistance. Audit all three — on every machine, on a schedule — and treat a drift on any of them as the regression it is.

Free on a single machine, unlimited: WinSentinel audits WHfB, TPM, PIN policy, and password fallback locally and tells you exactly where the passwordless story breaks.