Introduction: Stop guessing—measure Windows Hello Readiness
Windows Hello for Business (WHfB) is a game-changer for modern security, replacing passwords with a phishing-resistant, two-factor sign-in. It relies on a device-bound key unlocked by a PIN or biometric gesture. However, a successful deployment hinges on critical prerequisites—like a healthy device registration state, correct policy model, and a supported TPM.
Failing to verify these requirements before you enforce policies leads to chaos: devices fail to enrol, users see cryptic errors like “PIN isn’t available,” and your help desk is overwhelmed.
This guide provides a comprehensive WHfB readiness checklist, a powerful JSON-emitting PowerShell script, and actionable operational patterns for Intune.
What Does “Ready” Mean for Windows Hello?
Before you deploy any WHfB policies, you must baseline a few key signals. This readiness checklist is your first step to a successful rollout.
1. Phishing-Resistant Strategy: Think of WHfB as a critical part of a broader Zero Trust security model. It’s not just a single setting you flip on; it’s a strategic move toward a phishing-resistant, passwordless environment. Plan it as a program, not a project.
2. Trust Model Clarity: This is a frequent point of failure. If you enable the Use certificate for on-premises authentication policy, Windows will expect a user sign-in certificate. This setting overrides Cloud Kerberos trust. If your goal is to use Cloud Kerberos, you must ensure the certificate trust policy is not configured anywhere.
3. Policy Consistency: Only use one channel to configure WHfB: either the PassportForWork CSP via Intune or Group Policy Objects (GPOs). Mixing contradictory settings can lead to unexpected behaviour and silent failures.
4. Hardware & OS: Prefer devices with TPM 2.0 and modern Windows 10/11 builds. Microsoft recommends excluding TPM 1.2 devices or allowing them to fall back to software keys only when necessary, as TPM 1.2 can introduce policy quirks.
5. Device Registration & PRT: A healthy Primary Refresh Token (PRT) is non-negotiable for WHfB. Verify the device’s state using dsregcmd /status. Pay close attention to the AzureAdPrt and SSO/Attempt Status outputs to troubleshoot registration issues.
6. Unlock Assurance: By default, WHfB unlocks the device-bound key with a single gesture (PIN or biometric). For a higher level of security, consider configuring Multi-factor unlock to require additional trusted signals, such as network or presence, for authentication.
A Ready-to-Use Windows Hello Readiness Script
This PowerShell script checks for essential readiness signals, including TPM 2.0 status, biometric device detection, and OS version. It then emits a compressed JSON object, which is perfect for integration with automation platforms like Intune Remediations, ConfigMgr, or a Log Analytics pipeline.
# TPM (Win32_Tpm via CIM)
$tpm = Get-CimInstance -Namespace "Root\CIMv2\Security\MicrosoftTpm" -ClassName Win32_Tpm -ErrorAction SilentlyContinue
$spec = if ($tpm) { ($tpm.SpecVersion -join ',') } else { $null }
$hasTpm2 = $false
if ($spec) { $hasTpm2 = ($spec -match '(^|[^0-9])2\.0([^0-9]|$)') }
# Biometric devices (PnP)
$biometric = Get-PnpDevice -Class Biometric -ErrorAction SilentlyContinue |
Select-Object FriendlyName, InstanceId, Status
# OS version
$os = Get-CimInstance -Class Win32_OperatingSystem
$osCompatible = ([version]$os.Version -ge [version]'10.0.19041') # adjust baseline for your estate
$result = [pscustomobject]@{
TPM = [pscustomobject]@{
Present = [bool]$tpm
SpecVersion = $spec
IsTpm2 = $hasTpm2
}
Biometric = [pscustomobject]@{
Detected = ($biometric -and $biometric.Count -gt 0)
Devices = $biometric
}
OS = [pscustomobject]@{
Version = $os.Version
BuildNumber = $os.BuildNumber
Compatible = $osCompatible
}
}
$result | ConvertTo-Json -Depth 6 -Compress
Why these cmdlets? Get-CimInstance is the modern WMI API, while Win32_Tpm exposes the critical TPM specification. Get-PnpDevice reliably enumerates biometric devices, and ConvertTo-Json -Compress ensures the output is machine-readable and lightweight.
You can deploy the script using Intune Remediations. If you’d like to learn more about how to do this, check out my blog: How to Deploy PowerShell Script via Intune: A Complete Guide for IT Admins
What “good” looks like (and how to fix “bad”)
| Readiness signal | Good | If Not Good… | Why it matters |
|---|---|---|---|
| TPM | IsTpm2: true | Consider excluding TPM 1.2 devices from provisioning or accepting software keys with caution. Plan hardware upgrades over time. | TPM 2.0 secures the Hello private key in hardware, offering a higher level of protection than 1.2. |
| Biometric | Detected: true (device list shown) | Resolve driver or sensor issues. PIN-only is acceptable, but biometrics improve the user experience. | Better UX drives user adoption. Biometrics still unlock the same secure, device-bound key. |
| OS | Modern Windows 10/11 build | Patch devices and align your minimum build version in compliance policies. | Newer OS builds have improved WHfB provisioning, logging, and dsregcmd diagnostics. |
| Device Registration | AzureAdJoined: YES and AzureAdPrt: YES (from dsregcmd /status) | Troubleshoot PRT issues by checking network connectivity, time skew, and following the Entra join/SSO troubleshooting guide. | A healthy PRT is fundamental for Single Sign-On (SSO) and the token issuance required for WHfB flows. |
| Trust Model | Cloud Kerberos trust enabled, Cert trust not configured | If you are using Cloud Kerberos, ensure UseCertificateForOnPremAuth is not enabled in any policy. If using Certificate trust, deploy the user sign-in certificate first. | Certificate trust settings override Cloud Kerberos, which can silently block provisioning and lead to hard-to-diagnose errors. |
Why teams stumble: the policy trap you can avoid
A common mistake in many organisations is leaving the Use certificate for on-premises authentication setting enabled in a legacy GPO or an older Intune policy, even when they intend to use Cloud Kerberos trust.
Windows will see the certificate-trust setting, expect a user sign-in certificate, and fail the WHfB readiness check. This results in cryptic “policy evaluation failed” events. The solution is simple: double-check both Intune Settings Catalog (PassportForWork CSP) and any GPOs in scope to ensure certificate trust is disabled on the machines you want to use Cloud Kerberos.
To validate your readiness, use the Event Viewer. Navigate to Applications and Services Logs → Microsoft → Windows → User Device Registration. A successful provisioning ends with Event ID 300 (Windows Hello successfully created). Readiness blockers often show up as Event ID 360 or 362 with a specific reason.
Beyond the basics: Multi-factor unlock (the right way)
You might be tempted to force PIN and biometric together, but the recommended pattern is Multi-factor unlock—you still unlock the device-bound key with a single gesture (PIN or biometric), plus trusted signals (for example, presence, network, or location) for extra assurance at unlock. This keeps usability high while raising the bar against shoulder-surfing or stolen gestures.
A useful tactic is to pilot multi-factor unlock with a small group, collecting feedback on unlock latency and false negatives from presence/network signals before wider enablement. (If you operate in regulated environments, align this with your risk-based access and token protection strategy.) Microsoft Learn
Operationalising this in Intune (so it helps at scale)
Pattern 1 — “Gate before enforce.”
Use the readiness script as an Intune Remediation detection script. Only assign the WHfB policy to devices that pass your specific gates, such as TPM 2.0+ and a modern OS. This method prevents policy from even attempting to deploy on incompatible devices, dramatically reducing errors.
Pattern 2 — “Detect → educate.”
For devices that fail a readiness gate, use Intune to trigger a notification to the end-user. For example, a pop-up in the Company Portal could say, “Windows Hello isn’t available because no fingerprint sensor was detected.” This proactive communication reduces help desk tickets and sets clear user expectations.
Pattern 3 — “Logs + dsregcmd baseline.”
Train your service desk to capture the output of dsregcmd /status and the relevant Event IDs (300/360/362) from Event Viewer. This simple practice dramatically shortens the time it takes to identify the root cause, distinguishing between policy problems, registration issues, and network problems.
How to interpret the script output (with examples)
- TPM.IsTpm2 → If
true, you’re aligned with Microsoft guidance to prefer TPM 2.0 and exclude 1.2 where possible. Iffalse, plan a hardware path or accept software keys with risk trade-offs. Microsoft Learn - Biometric.Detected →
truemeans users can enroll fingerprint/face for a better first-run experience; iffalse, you can still run PIN-only, but set user expectations. Microsoft Learn - OS.Compatible → Keep the baseline at a modern build (e.g., Windows 10 2004+/Windows 11) to benefit from richer
dsregcmddiagnostics (Attempt Status) and provisioning improvements. Microsoft Learn
For an end-to-end readiness view, augment this with a fleet job that also parses dsregcmd /status into JSON and checks KeyIso (CNG Key Isolation) is running—WHfB relies on the protected key store provided by that service.
Conclusion: Make Windows Hello Readiness your first success metric
Passwordless projects often fail because they focus on enforcement before measurement. By starting with a lightweight readiness script, clarifying your trust model, and implementing smart Intune operational patterns, you can transform “mystery failures” into predictable, actionable outcomes.
Start by running the JSON script on a pilot group. Feed the results into a dashboard to trend your fleet’s TPM coverage and biometric sensor availability. Once you have a clear picture of your readiness, you can confidently flip the policy switch for that cohort
