Common questions about Windows Hello for Business

Windows Hello represents the biometric framework provided in Windows. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.

Three main reasons:

1. A PIN is tied to a device: one important difference between an online password and a Hello PIN is that the PIN is tied to the specific device on which it's set up. That PIN is useless to anyone without that specific hardware. Someone who obtains your online password can sign in to your account from anywhere, but if they obtain your PIN, they'd have to access your device too. The PIN can't be used anywhere except on that specific device. If you want to sign in on multiple devices, you have to set up Hello on each device
2. A PIN is local to the device: an online password is transmitted to the server. The password can be intercepted in transmission or obtained from a server. A PIN is local to the device, never transmitted anywhere, and it isn't stored on the server. When the PIN is created, it establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for authentication. When you enter your PIN, you unlock the authentication key, which is used to sign the request that is sent to the authenticating server. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key
3. A PIN is backed by hardware: the Hello PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Windows doesn't link local passwords to TPM, therefore PINs are considered more secure than local passwords. User key material is generated and available within the TPM of the device. The TPM protects the key material from attackers who want to capture and reuse it. Since Hello uses asymmetric key pairs, users credentials can't be stolen in cases where the identity provider or websites the user accesses have been compromised. The TPM protects against various known and potential attacks, including PIN brute-force attacks. After too many incorrect guesses, the device is locked

The statement A PIN is stronger than a password is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the Multifactor Unlock feature.

To compromise a Windows Hello credential that TPM protects, an attacker must have access to the physical device. Then, the attacker must find a way to spoof the user's biometrics or guess the PIN. All these actions must be done before TPM anti-hammering protection locks the device.

Windows Hello enables biometric sign-in with fingerprint, iris, or facial recognition. When you set up Windows Hello, you're asked to create a PIN after the biometric setup. The PIN enables you to sign in when you can't use your preferred biometric because of an injury or because the sensor is unavailable or not working properly. If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in, you would have to sign in using your account and password, which doesn't provide you with the same level of protection as Hello.

Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IdP before the IdP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.

Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Microsoft Entra ID and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.

Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation prompts the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.

The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. There isn't a policy setting to adjust the caching.

When you enroll in Windows Hello, a representation of your biometrics, called an enrollment profile, is created more information can be found on Windows Hello face authentication. This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see Windows Hello biometrics in the enterprise.

Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it's stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash.

Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.

Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. An IT administrator may configure policy settings, but it's always a user's choice if they want to use biometrics or PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to Start > Settings > Accounts > Sign-in options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.

To remove Windows Hello and any associated biometric identification data from the device, open Start > Settings > Accounts > Sign-in options. Select the Windows Hello biometrics authentication method you want to remove, and then select Remove. The action unenrolls from Windows Hello biometrics authentication and deletes the associated biometrics template database file. For more details, see Windows sign-in options and account protection (microsoft.com).

Starting in Configuration Manager, version 2203, Windows Hello for Business deployments using Configuration Manager are no longer supported.

You can delete the Windows Hello for Business container by executing the command certutil.exe -deleteHelloContainer.

If the user can sign in with a password, they can reset their PIN by selecting the I forgot my PIN link in the Settings app or from the lock screen, by selecting the I forgot my PIN link on the PIN credential provider.

For on-premises deployments, devices must be connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid deployments can onboard their Microsoft Entra tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see PIN reset.

Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. The algorithm counts the number of steps required to reach the next digit, overflowing at 10 ('zero'). So, for example:

• The PIN 1111 has a constant delta of (0,0,0), so it isn't allowed
• The PIN 1234 has a constant delta of (1,1,1), so it isn't allowed
• The PIN 1357 has a constant delta of (2,2,2), so it isn't allowed
• The PIN 9630 has a constant delta of (7,7,7), so it isn't allowed
• The PIN 1593 has a constant delta of (4,4,4), so it isn't allowed
• The PIN 7036 has a constant delta of (3,3,3), so it isn't allowed
• The PIN 1231 doesn't have a constant delta (1,1,2), so it's allowed
• The PIN 1872 doesn't have a constant delta (7,9,5), so it's allowed

This check prevents repeating numbers, sequential numbers, and simple patterns. It always results in a list of 100 disallowed PINs (independent of the PIN length). This algorithm doesn't apply to alphanumeric PINs.

To help Microsoft keep things working properly, to help detecting and preventing fraud, and to continue improving Windows Hello, diagnostic data about how people use Windows Hello is collected. For example:

• Data about whether people sign in with their face, iris, fingerprint, or PIN
• The number of times they use it
• Whether it works or not All this is valuable information that helps Microsoft building a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. Learn more about diagnostic data in Windows.

No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.

The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN.

If the user attempts to unlock the device by entering random PINs, after three unsuccessful attempts the credential provider will display the following message: You've entered an incorrect PIN several times. To try again, enter A1B2C3 below. Upon entering the challenge phrase A1B2C3, the user will be granted one more opportunity to enter the PIN. If unsuccessful, the provider will be disabled, leaving the user with the only option to reboot the device. Following the reboot, the aforementioned pattern repeats.

If unsuccessful attempts continue, the device will enter a lockout state, lasting for 1 minute after the first reboot, 2 minutes after the fourth reboot, and 10 minutes after the fifth reboot. The duration of each lockout increases accordingly. This behavior is a result of the TPM 2.0 anti-hammering feature. For more information about the TPM anti-hammering feature, see TPM 2.0 anti-hammering.

Yes. You can use the on-premises Windows Hello for Business deployment and combine it with a non-Microsoft MFA provider that doesn't require internet connectivity to achieve an air-gapped Windows Hello for Business deployment.

The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.

No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.

Review Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the Windows 10 scenario and the Device writeback scenario. Your environment may include other attributes.

Yes, if you're using federated hybrid deployment, you can use any non-Microsoft that provides an AD FS MFA adapter. A list of non-Microsoft MFA adapters can be found here.

Windows Hello for Business works with any non-Microsoft federation servers that support the protocols used during the provisioning experience.

Windows Hello for Business is not designed to work with local accounts.

Read Windows Hello biometric requirements for more information.

Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.

A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.

If a user has signed into their Microsoft Entra registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Microsoft Entra resources. The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.

It's possible to Microsoft Entra register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.

For more information, see Microsoft Entra registered devices.

Windows Hello for Business is a feature of the Windows platform.

No, Microsoft Entra Domain Services is a separately managed environment in Azure, and hybrid device registration with cloud Microsoft Entra ID isn't available for it via Microsoft Entra Connect. Hence, Windows Hello for Business doesn't work with Microsoft Entra Domain Services.

Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".

Both types of authentication provide the same security; one is not more secure than the other. The trust models of your deployment determine how you authenticate to Active Directory. Both key trust and certificate trust use the same hardware-backed, two-factor credential. The difference between the two trust types is the issuance of end-entity certificates:

• The key trust model authenticates to Active Directory by using a raw key. Key trust doesn't require an enterprise-issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed)
• The certificate trust model authenticates to Active Directory by using a certificate. Therefore, you need to issue certificates to users. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing CA

Convenience PIN provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to Windows Hello for Business. New Windows deployments should deploy Windows Hello for Business and not convenience PINs.

No. While it's possible to set a convenience PIN on Microsoft Entra joined and Microsoft Entra hybrid joined devices, convenience PIN isn't supported for Microsoft Entra user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.

Windows Hello for Business is the modern, two-factor authentication for Windows. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business.

For a list of required URLs, see Microsoft 365 Common and Office Online.

If your environment uses Microsoft Intune, see Network endpoints for Microsoft Intune.

Yes, you can use an external Windows Hello compatible camera if a device has an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see IT tools to support Windows 10, version 21H1. If ESS is enabled, see Windows Hello Enhanced Sign-in Security.

Some laptops and tablets with keyboards that close may not use an external Windows Hello compatible camera or other Windows Hello compatible accessory when the computer is docked with the lid closed. The issue has been addressed in Windows 11, version 22H2.

Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.

You can use multifactor unlock to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see Multifactor Unlock.

Windows Hello for Business cloud Kerberos trust is a trust model that enables Windows Hello for Business deployment using the infrastructure introduced for supporting security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices. Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see cloud Kerberos trust deployment.

This feature doesn't work in a pure on-premises AD domain services environment.

Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud Kerberos trust will work.

Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller when:

• a user signs-in for the first time or unlocks with Windows Hello for Business after provisioning
• attempting to access on-premises resources secured by Active Directory

Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP if a certificate is enrolled into Windows Hello for Business for this purpose. As an alternative, consider using Remote Credential Guard which doesn't require to deploy certificates.

No, only the number necessary to handle the load from all cloud Kerberos trust devices.

In a hybrid deployment, a user's public key must sync from Microsoft Entra ID to Active Directory before it can be used to authenticate against a domain controller. This sync is handled by Microsoft Entra Connect and will occur during a normal sync cycle.

Remote Desktop Protocol (RDP) doesn't support using key-based authentication as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see Deploying certificates to key trust users to enable RDP. As an alternative, consider using Remote Credential Guard which doesn't require to deploy certificates.