Windows Hello for Business: trust models and PIN policy

Passwords are the credential attackers steal most often: phished, sprayed, keylogged, dumped from memory or reused from another breach. Windows Hello for Business replaces the password at Windows sign-in with an asymmetric key pair generated on the device and protected by its TPM. The user unlocks the key with a PIN or biometric gesture; the private key never leaves the device, and there is nothing reusable to phish.

This guide covers the decisions that matter for security: which trust model to use, how to force hardware-backed keys, how to set PIN policy, and how to confirm that users and administrators are actually signing in with Hello rather than falling back to a password. It builds on the Credential Protection series, where Credential Guard protects what is left in memory.

How it works in brief

At provisioning, Windows creates a key pair in the TPM for the user and registers the public key with Microsoft Entra ID (and, depending on the trust model, Active Directory). At sign-in, the user unlocks the private key locally and uses it to authenticate: to Entra ID for a Primary Refresh Token, and to Active Directory for a Kerberos ticket. The PIN is a local unlock gesture, not a shared secret.

Two properties make it valuable:

• Phishing resistance. There is no password to type into a fake page, and the key only works on the device where it was created.
• No reusable secret on the wire. An attacker capturing network traffic or relaying authentication gets nothing that works elsewhere.

Step 1: choose the trust model

For hybrid (AD + Entra ID) environments, the trust model decides how a Hello sign-in gets a Kerberos ticket from your domain controllers.

Cloud Kerberos trust removes the two usual pain points: no PKI for the Hello keys, and no provisioning delay while the public key syncs to AD. Its requirements are specific: Windows 10 21H2 with KB5010415 or Windows 11 21H2 with KB5010414 or later on clients; domain controllers on Windows Server 2016 with KB4534307, Server 2019 with KB4534321, or Server 2022/2025; enough writable domain controllers in every site where users authenticate; and users synced to Entra ID. Members of privileged built-in groups (Domain Admins and similar) cannot use it, because the AzureADKerberos object's password replication policy denies them, and Microsoft advises against relaxing that.

Cloud-only (Entra joined, no on-premises AD) deployments do not need a trust model at all.

Step 2: create the Entra Kerberos object (cloud Kerberos trust)

Cloud Kerberos trust relies on a read-only-domain-controller-style object in each domain, which lets Entra ID issue partial Kerberos tickets that your DCs trust. Create it from a machine with the AzureADHybridAuthenticationManagement module, as a member of Domain Admins (and Enterprise Admins for the forest) and with an Entra account holding the Hybrid Identity Administrator role:

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$upn    = "admin@contoso.com"
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn

This creates an AzureADKerberos computer object in the Domain Controllers OU and a krbtgt_AzureAD account. Treat both as Tier 0 assets: the key of krbtgt_AzureAD lets whoever controls it influence ticket issuance. Rotate it periodically with the same module (Set-AzureADKerberosServer -RotateServerKey) and keep the Entra accounts that can manage it in your Tier 0 admin model.

Step 3: configure the policy

With Group Policy, the settings live under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Hello for Business:

In Intune, you can set a tenant-wide default under Devices > Enrollment > Windows Hello for Business, but for control and targeting use an Endpoint security > Account protection policy or the settings catalog. Both use the PassportForWork CSP, with settings such as Use Windows Hello For Business, Use Cloud Trust For On Prem Auth and Require Security Device. Avoid configuring the same device from both the tenant-wide default and a targeted policy, which makes troubleshooting harder. If a device receives Windows Hello for Business settings from both Group Policy and Intune, Group Policy wins and the Intune settings are ignored.

Step 4: require TPM-backed keys

If a device has no usable TPM, Windows can fall back to a software key, which malware running as the user or an attacker with the disk can target far more easily. Use a hardware security device (Intune: Require Security Device) prevents that fallback: devices without a suitable TPM do not provision Hello at all.

Check TPM state before you enforce it, especially on older desktops and VMs:

Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, ManufacturerVersion

Refusing TPM 1.2 avoids older chips with weaker algorithms and a history of firmware issues. The same TPM protects BitLocker keys, so a TPM inventory serves both projects.

On Windows 11 hardware that supports it, Enhanced Sign-in Security adds VBS isolation for biometric data and the sign-in path. It depends on specific sensors and firmware, so check device support before listing it as a requirement.

Step 5: set PIN policy

PIN complexity lives under Computer Configuration > Policies > Administrative Templates > System > PIN Complexity (Intune: PIN Complexity settings in the same account protection profile).

The real protection against guessing is TPM anti-hammering, which locks out after repeated wrong PINs. Keep the defaults for that unless you have a specific reason.

Enable PIN recovery (Use PIN Recovery in policy, EnablePinRecovery in the CSP) so users can reset a forgotten PIN through the Microsoft PIN reset service without destroying and re-provisioning their key. That keeps "I forgot my PIN" from becoming a helpdesk password reset.

Step 6: administrators and the password that remains

Windows Hello does not delete the user's password; it stops users typing it. To get the full benefit:

• Enable the passwordless experience, which hides the password credential provider for the last user who signed in with Hello or a FIDO2 key (Authentication/EnablePasswordlessExperience in the Policy CSP). It requires Windows 11 22H2 with KB5030310 or later, Microsoft Entra join and MDM management; hybrid joined and AD-joined devices are out of scope.
• For admins, provision Hello for the tier admin account on the PAW, and use Conditional Access to require phishing-resistant authentication for admin roles in Entra ID. Under cloud Kerberos trust, Tier 0 accounts in privileged built-in groups cannot get an on-premises TGT this way, so plan another sign-in method for them, such as smart cards.
• Remember that RDP to a server generally still needs a credential the server accepts. Remote Credential Guard can use your Hello sign-in because Kerberos requests stay on the client; test your specific combination.

What breaks

• Devices without a usable TPM do not provision once hardware keys are required.
• Users who have never signed in on the corporate network, under key trust, can wait for key sync before on-premises resources work. Cloud Kerberos trust avoids this delay.
• Shared devices used by many people: each user provisions their own key, and there is a per-device limit on Hello registrations.
• Applications that prompt for the Windows password directly (old VPN clients, some line-of-business apps) instead of using integrated sign-in.

Verify it

1. Provisioning state. Run dsregcmd /status as the user. Under User State, NgcSet : YES means a Hello key exists. For cloud Kerberos trust, OnPremTgt : YES (under SSO State) shows the user received an on-premises ticket through Entra ID.
2. Provisioning events. Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin records whether provisioning launched: event 358 when prerequisites pass and 360 when they do not, with the failing prerequisite listed.
3. Sign-in method. In the Entra sign-in logs, filter for Windows sign-ins and check the authentication method shows Windows Hello for Business. A large share of password sign-ins on provisioned devices means users are bypassing Hello.
4. Hardware-backed coverage. With the hardware security device policy on, devices without a ready TPM do not provision at all. Compare NgcSet coverage against the Get-Tpm inventory from Step 4 to find devices that silently never enrolled.

Checklist

• Trust model chosen; cloud Kerberos trust for hybrid unless a documented exception
• AzureADKerberos object created per domain and treated as Tier 0, key rotation scheduled
• Hello enabled by one policy source, hardware security device required, TPM 1.2 refused
• PIN minimum 6, no expiration, PIN recovery enabled
• Admins provisioned on PAWs; phishing-resistant auth required for admin roles
• Passwordless experience enabled where supported
• dsregcmd and events 358/360 used to track provisioning coverage

Windows Hello for Business removes the most stolen credential on Windows from daily use. For a definition to share with stakeholders, see Windows Hello for Business in the glossary.