Windows Hello for Business Deployment Models 

Windows Hello for Business deployment models are the three architectures Microsoft supports for rolling out passwordless authentication: cloud-only, hybrid, and on-premises.

Each deployment model determines which identity provider handles authentication and which trust model is available for verifying users against Active Directory. Most organizations already run most of the infrastructure a deployment needs. Cloud Kerberos trust is Microsoft’s recommended trust model for hybrid deployments unless an organization has a specific requirement for certificate-based authentication, since it removes the need to deploy a public key infrastructure (PKI) for Windows Hello for Business itself.

Key Takeaways

• Three deployment models exist: cloud-only, hybrid, and on-premises. Hybrid is the most common in enterprises that run both Active Directory and Microsoft Entra ID.
• Three trust models govern on-premises authentication: Cloud Kerberos trust, certificate trust, and key trust. Cloud Kerberos trust is hybrid-only and does not require a PKI.
• Microsoft recommends Cloud Kerberos trust as the default hybrid trust model unless certificate authentication is specifically required.
• Domain Admins and other privileged accounts cannot use Cloud Kerberos trust by default because of Password Replication Policy restrictions.
• On-premises deployment now serves a narrower set of cases, mainly organizations not yet ready to adopt Microsoft Entra ID.

The Three Deployment Models

Windows Hello for Business supports cloud-only, hybrid, and on-premises deployment models. The right choice depends on where an organization’s identities live: entirely in Microsoft Entra ID, split between Microsoft Entra ID and on-premises Active Directory, or entirely in Active Directory with no cloud presence.

Cloud-only Deployment Model

The cloud-only deployment model relies entirely on Microsoft Entra ID for identity and authentication, with no on-premises Active Directory involved. It fits organizations whose devices connect only to cloud resources such as Microsoft 365, SharePoint Online, and OneDrive. Because there is no on-premises Active Directory to authenticate against, the trust model concept does not apply in this deployment; devices authenticate to Microsoft Entra ID directly using the Windows Hello for Business key.

Pros

• Streamlined Management: Configuration, monitoring, and updates run through Microsoft Entra ID and Intune, reducing the workload on IT administrators.
• Scalability: Organizations can add users and devices without additional on-premises infrastructure investment.
• Flexibility: Users can authenticate from any location with an internet connection, which suits remote and distributed workforces.

Cons

• Dependency on Internet Connectivity: Authentication requires a connection to Microsoft Entra ID, so outages disrupt sign-in.
• Security Concerns: Some organizations are cautious about storing authentication data solely in the cloud, despite Microsoft’s security controls.
• Data Privacy and Compliance: Organizations handling regulated biometric data may need to weigh cloud data residency against their compliance obligations.

On-Premises Deployment Model

The on-premises deployment model uses only on-premises Active Directory, with no Microsoft Entra ID identities or cloud applications involved. Microsoft’s own Windows Hello for Business FAQ describes on-premises deployments as intended for organizations that need more time before moving to the cloud and that rely exclusively on Active Directory; organizations already using Microsoft cloud services are directed toward a hybrid deployment instead. One documented on-premises use case is Enhanced Security Administrative Environments, sometimes called Red Forests, where administrative credentials are isolated in a hardened forest.

Pros

• Local Control: Organizations keep direct control over the entire Windows Hello for Business infrastructure, which matters for specific security and compliance requirements.
• Data Residency: Authentication data stays inside the organization’s own data centers, which can simplify regulatory reporting.
• Reduced Dependency on Internet Connectivity: Authentication can continue during temporary internet outages, since it does not depend on Microsoft Entra ID.

Cons

• Scalability Challenges: Growing the user base means upfront hardware and licensing investment rather than incremental cloud consumption.
• Limited Remote Access: Users outside the corporate network face additional configuration requirements, since there is no cloud identity layer to fall back on.
• Maintenance Complexity: Running the infrastructure requires dedicated, skilled IT staff for updates and troubleshooting.

Hybrid Deployment Model

The hybrid deployment model synchronizes identities between on-premises Active Directory and Microsoft Entra ID, giving users single sign-on across both environments. It is the most common deployment model in enterprises, since most organizations still operate a mix of on-premises and cloud resources. Hybrid is also the only deployment model that supports all three trust models, including Cloud Kerberos trust.

Pros

• Flexibility: Hybrid balances on-premises control with cloud scalability, suiting organizations that are migrating gradually rather than all at once.
• Local Control Where It Matters: Device registration, certificate authorities, and key storage can remain on-premises for organizations with specific compliance requirements.
• Compliance Options: Organizations can choose where specific authentication data is processed and stored, on-premises or in the cloud, to meet data residency requirements.

Cons

• Configuration Complexity: Hybrid setup requires more planning than a single-environment deployment, to integrate on-premises and cloud components correctly.
• Dependency on Internet Connectivity: Cloud-dependent authentication steps, including Cloud Kerberos trust, are affected by internet outages.
• Management Overhead: IT teams need expertise in both on-premises Active Directory and Microsoft Entra ID to monitor and maintain the environment.

Trust Models

The trust model determines how a Windows Hello for Business client authenticates to on-premises Active Directory. It has no effect on authentication to Microsoft Entra ID, which always uses the Windows Hello for Business key. Hybrid deployments support all three trust models: Cloud Kerberos trust, certificate trust, and key trust. On-premises deployments support only certificate trust and key trust, since Cloud Kerberos trust depends on Microsoft Entra Kerberos.

Key Trust Model

Key trust authenticates users with a hardware-bound key generated during the built-in Windows Hello for Business provisioning experience. No authentication certificate is issued to the user, though domain controllers still require a certificate to serve as a root of trust for clients.

Certificate Trust Model

Certificate trust issues an authentication certificate to the user, requested using the hardware-bound key created during provisioning. It requires an enterprise PKI and a certificate registration authority, making it the most infrastructure-heavy of the three trust models.

Cloud Kerberos Trust Model

Cloud Kerberos trust uses Microsoft Entra Kerberos to issue a ticket-granting ticket directly from Microsoft Entra ID, removing the need to deploy a PKI for Windows Hello for Business. Microsoft recommends it as the default hybrid trust model when certificate authentication is not specifically required, since it is the only hybrid trust option that does not require deploying any certificates.

Comparison Between the Trust Models

The table below compares Cloud Kerberos trust, certificate trust, and key trust across authentication method, deployment model support, PKI requirements, and Microsoft’s current guidance.

Criteria	Cloud Kerberos Trust	Certificate Trust	Key Trust
User authentication	Requests a Kerberos ticket-granting ticket directly from Microsoft Entra ID using Microsoft Entra Kerberos.	Requires an authentication certificate, issued through a device-bound key created during provisioning.	Uses a device-bound key created during provisioning. No certificate is issued to the user.
Deployment model support	Hybrid only	Hybrid and on-premises	Hybrid and on-premises
PKI requirement	Not required	Required: enterprise PKI plus a certificate registration authority	Required for domain controller certificates only
Microsoft’s current guidance	Recommended default for hybrid deployments unless certificate authentication is specifically needed	Use when certificate-based authentication is a requirement	Legacy option, largely superseded by Cloud Kerberos trust in new hybrid deployments

A few operational details do not fit neatly into the table above but affect trust model selection. Domain Admins and other members of protected Active Directory groups cannot use Cloud Kerberos trust or FIDO2 security keys to sign in to on-premises resources by default, because the Password Replication Policy on the Microsoft Entra Kerberos computer object blocks them.

Cloud Kerberos trust also cannot be used as a supplied credential for RDP or VDI sessions unless a certificate is separately enrolled for that purpose, or Remote Credential Guard is used instead. Migration paths between trust models are not symmetric: moving from key trust to Cloud Kerberos trust can be done through Group Policy or Intune, but there is no direct migration path from certificate trust to Cloud Kerberos trust, since the existing Windows Hello for Business container must be deleted before redeployment.

Comparison Between the Deployment Models

This table compares the on-premises, cloud-only, and hybrid deployment models across control, data residency, integration, and scalability.

Feature	On-Premises	Cloud-Only	Hybrid
Control and management	Full local control over infrastructure and data	Managed entirely through Microsoft Entra ID and Intune	Balance of on-premises control and cloud-based management
Data residency	Authentication data stays on-premises	Authentication data stored in Microsoft Entra ID	Registration and policy data can live on-premises, in the cloud, or both, depending on trust model
Integration	Integrates with on-premises Active Directory only	Relies entirely on Microsoft Entra ID	Synchronizes Active Directory identities with Microsoft Entra ID
Scalability	Scaling requires additional on-premises infrastructure investment	Scales with minimal added infrastructure	Scales similarly to cloud-only for Entra ID-registered components, but on-premises components still require infrastructure planning

How Encryption Consulting Helps

Choosing the right Windows Hello for Business deployment model and trust model requires an accurate picture of an organization’s existing PKI, Active Directory topology, and Microsoft Entra ID configuration. Encryption Consulting’s PKI Services team assesses that environment first, then designs the certificate templates, registration authorities, and domain controller certificates that certificate trust and key trust deployments depend on.

For organizations planning a rollout from scratch, Encryption Consulting’s Windows Hello for Business implementation service covers deployment model selection, trust model configuration, and Intune or Group Policy rollout end to end. Organizations that want to avoid standing up or maintaining an internal PKI can run their certificate infrastructure through PKI-as-a-Service, and once certificates are issued, CertSecure Manager provides lifecycle visibility and automated renewal across the domain controller and user certificates a hybrid or on-premises deployment depends on.

Frequently Asked Questions

Which Windows Hello for Business Deployment Model Should My Organization Choose?

Cloud-only fits organizations with no on-premises Active Directory that rely entirely on Microsoft Entra ID. Hybrid fits organizations that synchronize identities between Active Directory and Microsoft Entra ID and need single sign-on to both, which is the most common enterprise scenario. On-premises fits organizations with no Microsoft Entra ID presence at all; Microsoft’s own guidance directs organizations already using Microsoft cloud services toward a hybrid model instead.

Is Cloud Kerberos Trust Available for On-Premises Deployments?

No. Cloud Kerberos trust depends on Microsoft Entra Kerberos and is supported only in hybrid deployments. On-premises deployments, which have no Microsoft Entra ID connection, support only the key trust and certificate trust models.

Do I Need a PKI to Deploy Windows Hello for Business?

Only for certificate trust, which requires an enterprise PKI and a certificate registration authority, or key trust, which requires certificates on domain controllers. Cloud Kerberos trust removes the requirement to deploy a PKI for Windows Hello for Business itself, which is why Microsoft recommends it as the default hybrid trust model when certificate authentication is not specifically required.

Can Domain Admins Use Cloud Kerberos Trust?

Not by default. The Password Replication Policy on the Microsoft Entra Kerberos computer object blocks high-privilege accounts, including Domain Admins and other protected group members, from signing in to on-premises resources with Cloud Kerberos trust or FIDO2 security keys. Microsoft does not recommend relaxing this policy, given the attack-vector risk it introduces between Microsoft Entra ID and Active Directory.

Can I Migrate Directly From Certificate Trust to Cloud Kerberos Trust?

No. There is no direct migration path from certificate trust to Cloud Kerberos trust. The existing Windows Hello for Business container has to be deleted before a device can be redeployed under Cloud Kerberos trust. Migrating from key trust to Cloud Kerberos trust is more straightforward and can be done through Group Policy or Intune without deleting the container.

Choose the Right Deployment Model With Confidence

Ready to plan a Windows Hello for Business rollout or fix a hybrid trust model issue? See PKI Services in action, or read about Public Key Infrastructure (PKI) fundamentals.