Windows Hello for Business: Passwordless authentication for Windows shops

Microsoft is trying to get rid of that sticky note that you see taped to everyone’s office monitor. You know, the one with the password on it. The one with all of the old passwords crossed off one by one, each one subtly different from the last — an exclamation point turning into an ampersand, a one into a two.

Enterprises have really done this to themselves. The passwords that most organizations require — which have to be complex, with long strings of numbers and specially cased phrases with some (but not all! heavens no, not the one you want) symbols — are difficult to remember. There’s no hope except to write them down. Then you have to reset them every so often. Then they get recycled. And on and on the cycle goes.

[ Download our editors’ PDF password managers buyer’s guide for enterprises and individuals today! ]

Luckily for Windows shops, Microsoft has introduced an enterprise-quality method of using biometric identification and authentication without requiring the purchase of high-end hardware — and it is baked right into Windows 10 and 11.

In this piece, I want to take a look at this innovation, called Windows Hello for Business (WHFB), explain how it works, and show how to enable it to secure your enterprise while eliminating the need for your users to handle cumbersome passwords.

How Windows Hello for Business works

Windows Hello is the most common and most widely known of the biometric authentication schemes that Windows supports. It lets Windows 10 and 11 users who have devices with fingerprint readers or special cameras log into Windows via fingerprint or facial recognition. The consumer version of Windows Hello is a device-specific mechanism and doesn’t transport between a user’s devices, so they will need to make a PIN or gesture on each device they want to use.

Windows Hello for Business takes the Hello idea and bundles it with management tools and enforcement techniques to ensure a uniform security profile and enterprise security posture. WHFB uses Group Policy or mobile device management (MDM) policies, usually enforced with Microsoft Intune, for management and enforcement, and leverages key- and certificate-based authentication in most cloud-focused scenarios for maximum protection. The PINs and gestures created by users work across devices in the WFHB model.

Windows Hello acts on one of two fronts: It can scan one’s fingerprint, or it can take an infrared picture of a user’s face and perform analysis on it. (Hello also supports iris scanning, but since iris cameras are better suited to phones than to laptops or desktop displays, the former two methods are more practical for the enterprise.)

It pairs these unique physical attributes of each user with cryptographic keys that replace passwords as authentication methods. These keys are stored within specialized security hardware, or are encrypted in software, and unlocked only after Windows deems them authentic. For organizations uninterested in biometrics, Windows Hello also supports PIN usage to replace passwords transmitted over the network.

Windows Hello protects Microsoft accounts (the accounts you use to log in to Microsoft cloud services, Xbox, Microsoft 365 and the like), domain accounts that are part of a corporate Active Directory deployment, domain accounts joined to an Azure Active Directory domain (these are relatively new), and accounts protected by federated identity providers that support the Fast ID Online 2.0 (FIDO2) protocol.

Why is Windows Hello considered stronger than a traditional password? For one, security is always better in threes — the best method of authentication is to provide something you have, something you know, and something you are. In this case, Windows Hello can authenticate users by satisfying all three rules: something you have (your private key, which is protected by your device’s security module), something you know (the PIN that is used by default by Windows Hello from the point of registration onward), and something you are (either your face, which is exceedingly difficult to copy and use in a malicious way, or your fingerprint, which again without removing digits is difficult to copy and use nefariously).

What is most interesting is that all of these biometrics are stored on the local device only and are not centralized into the directory or some other authentication source; this means credential harvesting attacks are no good against Windows Hello-enabled accounts simply because the credentials do not exist in the place that would be hacked. While it is technically possible each device’s trusted platform module, or TPM, could be hacked, an attacker would have to crack each individual user’s machine, versus simply executing a successful attack against a single vulnerable domain controller.

Hello’s biometric verification requires specialized hardware: webcams or cameras designed to see in infrared can pick up the differences between a photograph of a person and the real presence of that person. Most laptop manufacturers are now including Hello-compliant cameras in their corporate lines of devices. You can also purchase these compliant cameras separately, making a staged rollout possible.

Fingerprint readers, of course, have been around for years. Essentially, all fingerprint readers compatible with any version of Windows can also be used with Windows Hello; however, Microsoft says the newest generations of readers pick up more on the first touch or swipe, eliminating the need to swipe again and again as some previous models required.

It is important to note that you can use fingerprint sensors, facial cameras, PIN entry, or a combination of approaches in your organization. In fact, a user can register a fingerprint, face print, and PIN on the same device so they can choose which authentication method to use when logging in. Each of these authentication methods is called a “gesture,” and the gesture action is the key that begins the unlocking of public and private keys and verification of a user’s identity.

WHFB deployment models

When deploying WHFB, organizations can choose from three distinct deployment models: cloud-only, hybrid, and on-premises.

The cloud-only deployment model is tailored for organizations possessing solely cloud identities, without dependencies on on-premises resources. In this model, devices are predominantly connected to the cloud, and users exclusively interact with cloud-based assets such as SharePoint and OneDrive. Notably, there’s no necessity for certificates to access on-premises resources or services like VPN, as all required resources are hosted within Azure. This is sometimes known in Microsoft-speak as the “cloud Kerberos trust” model, introduced in early 2022.

The hybrid deployment model is particularly well-suited for organizations meeting specific criteria: It is an ideal choice for organizations that employ federated Azure Active Directory, synchronize identities to Azure AD through Azure Active Directory Connect, utilize applications hosted within Azure AD, and aim to provide a unified single sign-in experience for both on-premises and Azure AD resources.

Additionally, this model supports non-destructive PIN reset functionalities for both certificate trust and key trust models. Requirements include the Microsoft PIN Reset Service, which is essential for Windows 10 versions 1709 to 1809 Enterprise Edition (with no licensing requirement since version 1903), and the “Reset above lock screen” feature, available in Windows 10 version 1903. This option also uses 2022’s cloud Kerberos trust model, but it integrates with more features and capabilities to enable security key-based sign-in to AD.

The on-premises deployment model is specifically tailored for organizations that do not rely on cloud identities or Azure Active Directory-hosted applications. In this model, support for destructive PIN reset is available for both certificate trust and key trust models, ensuring robust security measures. To implement this model, organizations need to meet certain requirements, including the utilization of the “Reset from settings” feature for Windows 10 version 1703 Professional, the “Reset above lock screen” feature for Windows 10 version 1709 Professional, and the inclusion of the “I forgot my PIN link” feature for Windows 10 version 1903.

The cloud-only model is obviously the easiest to configure and deploy and is appropriate for businesses that have entirely migrated their identity infrastructure to the cloud. The other two models require some work on your certificate infrastructure to federate securely. The choice will be fairly simple depending on your current environment and starting point.

Enforcing WHFB through Group Policy

As you might imagine, you set up Windows Hello and enforce it throughout the enterprise organization through the use of Group Policy. Within the Group Policy Management Console, you can find policy settings under Policies > Administrative Templates > Windows Components > Windows Hello for Business in both the User configuration and the Computer configuration hives. The important policies to configure are:

• Use Windows Hello for Business: Set this to Enabled to get started with the deployment.
• Use biometrics: Set this to Enabled to enable fingerprint- or face-recognition gestures instead of supporting only a PIN.

Using Microsoft Intune to deploy WHFB

To create a WHFB policy, start by signing in to the Microsoft Intune admin center. Once logged in, navigate to Devices > Enroll devices > Windows enrollment > Windows Hello for Business.

(If you’re using a high screen resolution, note the very small scrollbar at the bottom of the right pane — all of the configuration options are buried there. It is easy to miss.)

Here, you have three options for configuring WHFB. You can enable it, which is fairly self-evident. You can also choose Disabled, which you can use to turn off WHFB during device enrollment. Note that even if WHFB is disabled, you can still configure other related settings. This setting gives you control over various aspects of WHFB, even though it won’t enable it. Or you can opt for Not configured, which is like the old Group Policy “not configured” state in that no settings are changed or set. This means existing WHFB settings on Windows 10 and Windows 11 devices will remain unchanged, and the other settings on the pane are grayed out.

IDG

The settings you can change as part of your configuration preferences are:

• Use a Trusted Platform Module (TPM): Decide whether TPM is required or preferred for provisioning WHFB.
• Minimum PIN length and Maximum PIN length: Set the range for PIN lengths to ensure secure sign-in.
• Lowercase letters in PIN, Uppercase letters in PIN, and Special characters in PIN: Choose whether these character types are allowed, required, or not allowed in users’ PINs to enforce stronger PIN security.
• PIN expiration (days): Specify how often users must change their PINs for security purposes.
• Remember PIN history: Decide whether to restrict the reuse of previously used PINs.
• Allow biometric authentication: Choose whether biometric authentication methods (facial recognition, fingerprint) can be used as alternatives to PINs.
• Use enhanced anti-spoofing, when available: Configure the use of anti-spoofing features on devices that support it to enhance facial recognition security.
• Allow phone sign-in: Enable or disable the use of a remote passport as a companion device for desktop computer authentication, provided the device is Azure Active Directory joined.
• Use security keys for sign-in: When enabled, this setting allows remote control of Windows Hello Security Keys for all computers within the organization.

Enrolling devices in WHFB: the process, and how it works

For new devices you unbox and are ready to deploy, upon your initial sign-in to the device, you’ll be prompted to enroll in WHFB, assuming you have configured the settings described in the previous section. You’ll need to make sure the user has their multifactor authentication device (typically their cell phone for texts, the Microsoft Authenticator app, or another MFA app) nearby, as enrollment can’t proceed without it — you’ll either get prompted for a code if you’re already enrolled in MFA, or you’ll need to set it up and be prompted to do before proceeding with the WHFB part of the process.

IDG

At the time of enrollment, after the MFA is verified, the enrollment screen will prompt either for a PIN or, if the device supports it, another supported gesture like a thumbprint scan.

For existing devices, you can kick off enrollment fairly easily. In Windows 11, click the Start menu, search for Enroll, and then choose Enroll only in device management. The same process described above begins.

So what’s happening behind the scenes here? As part of the enrollment process, Windows generates a pair of keys, a public half and a private half, and stores them both in the hardware TPM module, or if a device does not have a TPM, it encrypts the keys and stores them in software. This first key pair is associated with the user’s PIN “gesture” and is known as a protector key. If a user registers additional biometric gestures, then each one will have a different protector key that wraps around the authentication key. While the container is designed to have only one authentication key, multiple copies of that single authentication key can be wrapped up with the different protector keys associated with the different gestures registered on the device.

There is also an administrative key that Windows automatically generates so that credentials can be reset when necessary, and the TPM also has its normal block of data that contains attestations and other TPM-related information.

Going fully passwordless with WHFB 

If you have machines joined to a Microsoft Entra ID domain (née Azure Active Directory) and you have Windows 11 22H2 with the September 2023 Update on those machines and you’re using Microsoft Intune — admittedly an aggressive and limited target deployment as of this writing in late fall 2023 — then you can take advantage of a newly released, easily deployed passwordless experience for those machines only.

There are a couple of ways to enable this. The first is to use the Settings catalog policy feature and set Enable Passwordless Experience to enabled. To do this, log in to Intune, go to Devices > Configuration Profiles, and choose Create Profile. Under Platform, select Windows 10 or later, click Create, and then in Configuration Settings, click Add Settings, find the Authentication section, and then check Enable Passwordless Experience.

The second way is to use a custom policy. For more on this option, you can pop over to the recently updated documentation on Microsoft’s Learn site.

Key points to consider

Some important points to remember:

• Credentials enrolled in WHFB can be bound to individual laptops, desktops, or mobile devices, and the access token one gets after successful credential verification is also limited to that single device.
• During an account’s registration process, Active Directory, Azure AD, or the Microsoft account service checks and authenticates the validity of the user and associates the Windows Hello public key to a user account. The keys — both the public and private halves — can be generated in the TPM modules versions 1.2 or 2.0, or they can live in software for devices without the right TPM hardware. The Windows Hello gesture does not roam between devices and is not shared with the server; it is stored locally on a device and never leaves the device. When the PIN is entered or the face or fingerprint is applied, Windows uses the private key stored in the TPM to sign data transmitted to the authentication source.
• According to Microsoft: “Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers’ domains to help ensure user privacy.” In practice, this means that keys get commingled within one secure container, although they are delineated by their native identity provider so that the wrong key is not sent to the wrong provider.
• A note for the future: In current Insider Preview editions of Windows 11, the EnablePasswordlessExperience policy can be enabled to suppress password prompts during various Windows authentication scenarios and seamlessly integrate passwordless recovery methods like WHFB PIN resets when required. Your users will notice that password prompts are removed from the user experience in common areas like device logon, in-session authentication, administrative tasks, and elevation prompts. This is expected to make it into the “RTM” or regular deployment channels within the next 12 months, and of course you’ll need the WHFB deployment settings buttoned up for it to be useful, but it’s certainly something to watch for.

The last word

Security experts for years have been calling for the death of passwords, but that goal has always been deferred by the lack of a seamless, affordable, user-friendly alternative for authentication. In practice, it was always going to take Microsoft putting biometric features inside Windows, the most popular operating system, to spur enough organizations to look into passwordless authentication.

While it is unlikely that your shop is a position to remove passwords entirely — at least not yet — new machines you deploy can work with this option by default, and as you migrate to Windows 11 over time at your own pace, you can slowly but surely work WHFB into your security profile.

This article was originally published in September 2017 and most recently updated in November 2023.