Plan a Windows Hello for Business deployment

This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.

This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure.

Using this guide

There are many options available for deploying Windows Hello for Business, ensuring compatibility with various organizational infrastructures. While the deployment process may appear complex, most organizations will find that they have already implemented the necessary infrastructure. It is important to note that Windows Hello for Business is a distributed system and requires proper planning across multiple teams within an organization.

This guide aims to simplify the deployment process by helping you make informed decisions about each aspect of your Windows Hello for Business deployment. It provides information on the options available and assists in selecting the deployment approach that best suits your environment.

How to proceed

Read this document and record your decisions. When finished, you should have all the necessary information to evaluate the available options and to determine requirements for your Windows Hello for Business deployment.

There are seven main areas to consider when planning a Windows Hello for Business deployment:

Deployment options

The goal of Windows Hello for Business is to enable deployments for all organizations of any size or scenario. To provide this type of granular deployment, Windows Hello for Business offers a diverse choice of deployment options.

Deployment models

It's fundamentally important to understand which deployment model to use for a successful deployment. Some aspects of the deployment might have already been decided for you based on your current infrastructure.

There are three deployment models from which you can choose:

Trust types

A deployment's trust type defines how Windows Hello for Business clients authenticate to Active Directory. The trust type doesn't affect authentication to Microsoft Entra ID. For this reason, the trust type isn't applicable to a cloud-only deployment model.

Windows Hello for Business authentication to Microsoft Entra ID always uses the key, not a certificate (excluding smart card authentication in a federated environment).

The trust type determines whether you issue authentication certificates to your users. One trust model isn't more secure than the other.

The deployment of certificates to users and domain controllers requires more configuration and infrastructure, which could also be a factor to consider in your decision. More infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you must activate the Device Writeback option in Microsoft Entra Connect.

There are three trust types from which you can choose:

Key trust and certificate trust use certificate authentication-based Kerberos when requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.

The goal of Windows Hello for Business cloud Kerberos trust is to provide a simpler deployment experience, when compared to the other trust types:

• No need to deploy a public key infrastructure (PKI) or to change an existing PKI
• No need to synchronize public keys between Microsoft Entra ID and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
• FIDO2 security key sign-in can be deployed with minimal extra setup

Cloud Kerberos trust requires the deployment of Microsoft Entra Kerberos. For more information about how Microsoft Entra Kerberos enables access to on-premises resources, see enabling passwordless security key sign-in to on-premises resources.

PKI requirements

Cloud Kerberos trust is the only hybrid deployment option that doesn't require the deployment of any certificates. The other hybrid and on-premises models depend on an enterprise PKI as a trust anchor for authentication:

• Domain controllers for hybrid and on-premises deployments need a certificate for Windows devices to trust the domain controller as legitimate
• Deployments using the certificate trust type require an enterprise PKI and a certificate registration authority (CRA) to issue authentication certificates to users. AD FS is used as a CRA
• Hybrid deployments might need to issue VPN certificates to users to enable connectivity on-premises resources

Authentication to Microsoft Entra ID

Users can authenticate to Microsoft Entra ID using federated authentication or cloud (nonfederated) authentication. Requirements vary based on trust type:

To learn more:

• Federation with Microsoft Entra ID
• Password hash synchronization (PHS)
• Pass-through authentication (PTA)

Device registration

For on-premises deployments, the server running the Active Directory Federation Services (AD FS) role is responsible for device registration. For cloud-only and hybrid deployments, devices must register in Microsoft Entra ID.

Multifactor authentication

The goal of Windows Hello for Business is to move organizations away from passwords by providing them with a strong credential that enables easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication. However, the user must provide a second factor of authentication before Windows provisions a strong credential:

• For cloud-only and hybrid deployments, there are different choices for multifactor authentication, including Microsoft Entra MFA
• On-premises deployments must use a multifactor option that can integrate as an AD FS multifactor adapter. Organizations can choose from non-Microsoft options that offer an AD FS MFA adapter. For more information, see Microsoft and non-Microsoft additional authentication methods

For more information:

• Configure Microsoft Entra multifactor authentication settings
• Manage an external authentication method in Microsoft Entra ID

MFA and federated authentication

It's possible for federated domains to configure the FederatedIdpMfaBehavior flag. The flag instructs Microsoft Entra ID to accept, enforce, or reject the MFA challenge from the federated IdP. For more information, see federatedIdpMfaBehavior values. To check this setting, use the following PowerShell command:

Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl

To reject the MFA claim from the federated IdP, use the following command. This change impacts all MFA scenarios for the federated domain:

Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp

If you configure the flag with a value of either acceptIfMfaDoneByFederatedIdp (default) or enforceMfaByFederatedIdp, you must verify that your federated IDP is correctly configured and working with the MFA adapter and provider used by your IdP.

Key registration

The built-in Windows Hello for Business provisioning experience creates a device-bound asymmetric key pair as the user's credentials. The private key is protected by the device's security modules. The credential is a user key, not a device key. The provisioning experience registers the user's public key with the identity provider:

Directory synchronization

Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose:

• Hybrid deployments use Microsoft Entra Connect Sync to synchronize Active Directory identities (users and devices) or credentials between itself and Microsoft Entra ID. During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Microsoft Entra ID. Microsoft Entra Connect Sync synchronizes the Windows Hello for Business public key to Active Directory. This synchronization enables SSO to Microsoft Entra ID and its federated components.

  Important

  Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Microsoft Entra ID and Active Directory.

• On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA server, which sends data to the MFA cloud service to perform the verification

Device configuration options

Windows Hello for Business provides a rich set of granular policy settings. There are two main options to configure Windows Hello for Business: configuration service provider (CSP) and group policy (GPO).

• The CSP option is ideal for devices that are managed through a Mobile Device Management (MDM) solution, like Microsoft Intune. CSPs can also be configured with provisioning packages
• GPO can be used to configure domain joined devices and where devices aren't managed via MDM

Licensing for cloud services requirements

Here are some considerations regarding licensing requirements for cloud services:

• Windows Hello for Business doesn't require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as MDM automatic enrollment and Conditional Access do
  • Devices managed via MDM don't require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, users must manually enroll devices in the MDM solution, such as Microsoft Intune or a supported non-Microsoft MDM
• You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication for the Windows passwordless features
  • Some Microsoft Entra multifactor authentication features require a license. For more information, see Features and licenses for Microsoft Entra multifactor authentication.
• Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature

Operating System requirements

Windows requirements

All supported Windows versions can be used with Windows Hello for Business. However, cloud Kerberos trust requires minimum versions:

Windows Server requirements

Windows Hello for Business can be used to authenticate against all supported Windows Server versions as a domain controller. However, cloud Kerberos trust requires minimum versions:

The minimum required domain functional and forest functional levels are Windows Server 2008 R2 for all deployment models.

Prepare users

When you are ready to enable Windows Hello for Business in your organization, make sure to prepare the users by explaining how to provision and use Windows Hello.

To learn more, see Prepare users.

Next steps

Now that you've read about the different deployment options and requirements, you can choose the implementation that best suits your organization.