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.
Tip
If you have a Microsoft Entra ID tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the Microsoft 365 admin center.
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:
| Deployment model | Description | |
|---|---|---|
| 🔲 | Cloud-only | For organizations that only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint Online, OneDrive, and others. Also, since the users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in cloud services. |
| 🔲 | Hybrid | For organizations that have identities synchronized from Active Directory to Microsoft Entra ID. These organizations use applications registered in Microsoft Entra ID, and want a single sign-on (SSO) experience for both on-premises and Microsoft Entra resources. |
| 🔲 | On-premises | For organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID. These organizations use on-premises applications, integrated in Active Directory, and want an SSO user experiences when accessing them. |
Note
- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests"
- Migration from on-premise to hybrid deployment requires redeployment
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:
| Trust type | Description | |
|---|---|---|
| 🔲 | Cloud Kerberos | Users authenticate to Active Directory by requesting a TGT from Microsoft Entra ID, using Microsoft Entra Kerberos. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization. Cloud Kerberos trust uses the same infrastructure required for FIDO2 security key sign-in, and it can be used for new or existing Windows Hello for Business deployments. |
| 🔲 | Key | Users authenticate to the on-premises Active Directory using a device-bound key (hardware or software) created during the Windows Hello provisioning experience. It requires to distribute certificates to domain controllers. |
| 🔲 | Certificate | The certificate trust type issues authentication certificates to users. Users authenticate using a certificate requested using a device-bound key (hardware or software) created during the Windows Hello provisioning experience. |
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
Tip
Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
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
| Deployment model | Trust type | PKI required? | |
|---|---|---|---|
| 🔲 | Cloud-only | n/a | no |
| 🔲 | Hybrid | Cloud Kerberos | no |
| 🔲 | Hybrid | Key | yes |
| 🔲 | Hybrid | Certificate | yes |
| 🔲 | On-premises | Key | yes |
| 🔲 | On-premises | Certificate | yes |
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:
| Deployment model | Trust type | Authentication to Microsoft Entra ID | Requirements | |
|---|---|---|---|---|
| 🔲 | Cloud-only | n/a | Cloud authentication | n/a |
| 🔲 | Cloud-only | n/a | Federated authentication | Non-Microsoft federation service |
| 🔲 | Hybrid | Cloud Kerberos trust | Cloud authentication | Password hash sync (PHS) or Pass-through authentication (PTA) |
| 🔲 | Hybrid | Cloud Kerberos trust | Federated authentication | AD FS or non-Microsoft federation service |
| 🔲 | Hybrid | Key trust | Cloud authentication | Password hash sync (PHS) or Pass-through authentication (PTA) |
| 🔲 | Hybrid | Key trust | Federated authentication | AD FS or non-Microsoft federation service |
| 🔲 | Hybrid | Certificate trust | Federated authentication | This deployment model doesn't support PTA or PHS. Active Directory must be federated with Microsoft Entra ID using AD FS |
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.
| Deployment model | Supported join type | Device registration service provider |
|---|---|---|
| Cloud-only | Microsoft Entra joined Microsoft Entra registered |
Microsoft Entra ID |
| Hybrid | Microsoft Entra joined Microsoft Entra hybrid joined Microsoft Entra registered |
Microsoft Entra ID |
| On-premises | Active Directory domain joined | AD FS |
Important
For Microsoft Entra hybrid joined guidance, review Plan your Microsoft Entra hybrid join implementation.
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
Important
Beginning July 1, 2019, Microsoft doesn't offer MFA Server for new deployments. New deployments that require multifactor authentication should use cloud-based Microsoft Entra multifactor authentication.
Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service MFA requests. To ensure uninterrupted authentication services and to remain in a supported state, organizations should migrate their users' authentication data to the cloud-based Azure MFA.
| Deployment model | MFA options | |
|---|---|---|
| 🔲 | Cloud-only | Microsoft Entra MFA |
| 🔲 | Cloud-only | Non-Microsoft MFA, via external authentication method in Microsoft Entra ID or federation |
| 🔲 | Hybrid | Microsoft Entra MFA |
| 🔲 | Hybrid | Non-Microsoft MFA, via external authentication method in Microsoft Entra ID or federation |
| 🔲 | On-premises | AD FS MFA adapter |
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:
| Deployment model | Key registration service provider |
|---|---|
| Cloud-only | Microsoft Entra ID |
| Hybrid | Microsoft Entra ID |
| On-premises | AD FS |
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
| Deployment model | Directory sync options |
|---|---|
| Cloud-only | n/a |
| Hybrid | Microsoft Entra Connect Sync |
| On-premises | Azure MFA server |
Important
Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service MFA requests. To ensure uninterrupted authentication services and to remain in a supported state, organizations should migrate their users' authentication data to the cloud-based Azure MFA.
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
| Deployment model | Device configuration options | |
|---|---|---|
| 🔲 | Cloud-only | CSP |
| 🔲 | Cloud-only | GPO (local) |
| 🔲 | Hybrid | CSP |
| 🔲 | Hybrid | GPO (Active Directory or local) |
| 🔲 | On-premises | CSP |
| 🔲 | On-premises | GPO (Active Directory or local) |
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
| Deployment model | Trust type | Cloud services licenses (minimum) | |
|---|---|---|---|
| 🔲 | Cloud-only | n/a | not required |
| 🔲 | Hybrid | Cloud Kerberos | not required |
| 🔲 | Hybrid | Key | not required |
| 🔲 | Hybrid | Certificate | Microsoft Entra ID P1 |
| 🔲 | On-premises | Key | Azure MFA, if used as MFA solution |
| 🔲 | On-premises | Certificate | Azure MFA, if used as MFA solution |
Important
Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service MFA requests. To ensure uninterrupted authentication services and to remain in a supported state, organizations should migrate their users' authentication data to the cloud-based Azure MFA.
Operating System requirements
Windows requirements
All supported Windows versions can be used with Windows Hello for Business. However, cloud Kerberos trust requires minimum versions:
| Deployment model | Trust type | Windows version | |
|---|---|---|---|
| 🔲 | Cloud-only | n/a | All supported versions |
| 🔲 | Hybrid | Cloud Kerberos | - Windows 10 21H2, with KB5010415 and later - Windows 11 21H2, with KB5010414 and later |
| 🔲 | Hybrid | Key | All supported versions |
| 🔲 | Hybrid | Certificate | All supported versions |
| 🔲 | On-premises | Key | All supported versions |
| 🔲 | On-premises | Certificate | All supported 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:
| Deployment model | Trust type | Domain controller OS version | |
|---|---|---|---|
| 🔲 | Cloud-only | n/a | All supported versions |
| 🔲 | Hybrid | Cloud Kerberos | - Windows Server 2016, with KB3534307 and later - Windows Server 2019, with KB4534321 and later - Windows Server 2022 - Windows Server 2025 |
| 🔲 | Hybrid | Key | All supported versions |
| 🔲 | Hybrid | Certificate | All supported versions |
| 🔲 | On-premises | Key | All supported versions |
| 🔲 | On-premises | Certificate | All supported 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.
To learn more about the deployment process, chose a deployment model and trust type from the following drop-down lists: