Windows Hello for Business, hardware keys, and SSO

If you manage identities in Microsoft environments, you've probably heard of Windows Hello, Windows Hello for Business, hardware keys , and SSO , but it's easy to get lost among all the acronyms, trust types, and requirements. Furthermore, in hybrid deployments with legacy Active Directory, understanding what WHfB actually offers compared to a simple PIN or biometric login can be the difference between a smooth project… or a constant headache.

In this article, we'll break down in detail how Windows Hello for Business (WHfB) works, the role of hardware keys, how single sign-on (SSO) is achieved , and how it differs from the standard Windows Hello for home users. We'll cover the internal phases (device registration, provisioning, key synchronization, certificates, and authentication), deployment models (cloud-only, hybrid, and on-premises), trust types, PKI requirements, licensing, real-world deployment challenges, and how all of this fits with modern approaches like FIDO2 and passwordless security.

Windows Hello vs Windows Hello for Business: What Really Changes

Windows Hello (plain and simple) is the user experience for logging in with a PIN or biometrics on a Windows device, designed for both home and business environments. Windows Hello for Business (WHfB), on the other hand, is the enterprise extension that adds strong identity capabilities integrated with Active Directory and Microsoft Entra ID.

With both methods, you can use PIN, fingerprint, or facial recognition supported by the TPM to log in to the device. You can even authenticate against a traditional local domain. The key difference is that WHfB creates and manages enterprise-grade cryptographic credentials : key pairs or certificates linked to the user and the device, managed by policies, and usable for SSO on local and cloud resources.

While "normal" Windows Hello essentially just replaces the password with a convenient gesture on that computer , WHfB generates a strong credential that the identity provider (AD, Microsoft Entra ID, or AD FS) recognizes, stores, and uses to issue access tokens and enforce conditional access, strict KDC validation, PRT, Kerberos in the cloud , and other advanced controls.

The logical question is: if I already have domain-joined devices managed with Intune, with TPM and biometrics, and SSO to the cloud via password hash synchronization, what exactly do I gain by adding WHfB? The answer lies in how the keys are constructed and validated, how the device is linked, and in the ability to extend that security to the entire ecosystem, not just local login.

Basic architecture: Windows Hello for Business phases

WHfB is a distributed system that relies on several components: device, TPM, identity provider, PKI, directory synchronization, and SSO mechanisms . To understand it clearly, it's helpful to divide its operation into five chronological implementation phases.

1. Device Registration

The first piece of the puzzle is registering the device with the identity provider (IdP) . This step associates the device with an identity in the directory and enables it to automatically authenticate when a user logs in.

In cloud-only or hybrid environments, the IdP is the Microsoft Entra ID , and the device is registered with its device registration service (joined to Microsoft Entra, hybrid-joined, or registered). In purely on-premises scenarios, the IdP is typically AD FS with its Enterprise Device Registration Service.

Upon completion of this registration, the IdP assigns the device a unique identity that will be used to establish device-directory trust in subsequent authentications. This registration is categorized by "device join type," which determines whether the device is joined to a local domain, an Entra ID, a hybrid domain, or simply registered as personal.

2. Provisioning: creating the Windows Hello container

Once the device is registered, the provisioning phase for the Windows Hello for Business credential begins . This is where the so-called Windows Hello container is created, which logically groups all the user's cryptographic data on that device.

The typical provisioning flow follows these main steps, always after initial authentication with weak credentials (username and password):

• The user authenticates with MFA at the IdP (Microsoft Enter MFA or another compatible method, or an MFA adapter in AD FS in local environments).
• After overcoming that second factor, you are asked to configure a PIN and, if compatible hardware is available, a biometric gesture (footprint, face, iris).
• Upon confirming the PIN, Windows generates the Windows Hello container for that account on that team.
• Within that container, a cryptographic key pair (public and private), linked to the TPM when it exists or, failing that, protected by software.
• La The private key remains on the device and cannot be exported, remaining protected by the TPM and by the PIN/biometric protectors.
• La public key is registered in the IdP and it is linked to the user object: in Microsoft Login ID it is written to the user, and in federated local scenarios, AD FS transfers it to Active Directory.

The container also includes an administrative key , useful for scenarios such as PIN reset; on devices with a TPM, a data block containing TPM certificates is also stored. All the material is unlocked only when the user performs the gesture (PIN or biometrics), and this initial MFA combination establishes trust between the user, device, and IdP.

3. Keys within the container: authentication and user identifier

Within the Windows Hello container we find several types of keys, with different roles, all encrypted with PIN-based or biometric protections :

• Authentication keyA pair of asymmetric keys generated during registration that must always be unlocked with a PIN or biometric gesture. It is the basis upon which other materials are recycled when the PIN is changed.
• User identifier keysIdentity keys can be symmetric or asymmetric depending on the Identity Provider (IdP) and the model (key or certificate). They are used to sign or encrypt requests and tokens directed to the identity provider. In enterprise environments, they are typically generated as asymmetric key pairs, with the public key registered with the IdP.

These user identifier keys can be obtained in two main ways: associated with the corporate PKI to issue certificates (e.g., for VPN , RDP or certificate-based Kerberos authentication) or generated directly by the IdP in scenarios without PKI (pure key model).

The same infrastructure allows Windows Hello to be used as a FIDO2/WebAuthn authenticator in compatible applications and websites. Sites can create a FIDO credential within the Windows Hello container; on subsequent visits, the user authenticates with their PIN or biometrics without exposing passwords.

4. Key synchronization in hybrid environments

In hybrid architectures where Microsoft Entra ID and Active Directory coexist , simply registering the key in the cloud is not enough. After provisioning, the WHfB public key must be synchronized to the local directory to enable authentication and SSO against on-premises resources.

In these scenarios, Microsoft Entra Connect Sync copies the public key to the msDS-KeyCredentialLink attribute of the user object in Active Directory. This synchronization is crucial for the domain controller to validate the signatures generated by the device against the private key stored in the TPM.

5. Registration of certificates (only when necessary)

In some models (such as certificate trust ), in addition to keys, the organization needs to issue authentication certificates to users. In that case, an additional certificate enrollment phase is triggered.

After registering the public key, the client generates a certificate request and sends it to the certificate authority, typically integrated into AD FS in federated deployments. This CRA validates the request using the corporate PKI and issues a certificate that is stored within the Hello container , reusable for authentication on local resources that still rely on certificates.

Authentication, private key, and SSO: how it all fits together

Once the registration and provisioning phases are complete, the user's day-to-day experience is reduced to something very simple: a gesture (PIN or biometrics) that "releases" the private key on the device . What's interesting is what happens behind the scenes.

When the user unlocks the device, Windows uses the private part of the WHfB credential to cryptographically sign data that is sent to the IdP . The IdP verifies the signature using the public key stored in the user object. Because the PIN never leaves the device and neither does the private key, the process is resistant to phishing and traditional credential theft.

In Microsoft Entra ID scenarios, completing authentication results in a Primary Refresh Token (PRT) , a JSON web token containing user and device information. This is the foundation of Single Sign-On (SSO) to cloud applications and, in combination with Microsoft Entra Kerberos or key synchronization, also to local resources.

Without a PRT, even if the user has a valid WHfB credential, they would lose single sign-on and be forced to authenticate continuously in each app. Therefore, conditional access policies, whether device-based or risk-based, typically consider the presence and validity of this PRT.

For Active Directory, when using key or certificate trust, WHfB acts as a virtual smart card : the user signs a nonce or challenge from the KDC, the domain controller validates the certificate or key, and issues a Kerberos TGT ticket, thus enabling SSO to local services integrated with Kerberos.

Internal security: biometrics, TPM and protection against attacks

One of the cornerstones of WHfB is that biometric data never leaves the device . The templates generated by the sensors are stored locally in encrypted databases (for example, in the path C:\WINDOWS\System32\WinBioDatabase) using unique keys per database, protected with AES in CBC mode and SHA-256 as the hash function.

This means that even if an attacker were to gain access to these files, they would not be able to reconstruct the user's facial image or fingerprint , nor use them on another device. Furthermore, each sensor maintains its own storage, reducing the possibility of a single central point of biometric template theft.

The Windows Hello for Business PIN is also better protected than a traditional password. It doesn't travel over the network; it's validated locally, and the TPM (Total Power Module) locks the system after too many incorrect attempts , rendering brute-force or dictionary attacks useless. And if someone steals the PIN, it would only work on that specific device, since the credential is tied to the hardware.

In the face of modern threats ( such as identifying phishing emails , password reuse, and mass credential theft), WHfB relies on device-bound public-key cryptography , preventing the exposure of shared secrets by design. This aligns perfectly with standards and recommendations from regulations like NIST 800-63B and with zero-trust security models.

Deployment models: cloud, hybrid, and on-premises

WHfB is flexible in terms of topology, but that flexibility brings with it some complexity. Broadly speaking, we can talk about three deployment models that combine Microsoft Entra ID, Active Directory, PKI, and federation in different ways.

Cloud-only model

In organizations that rely almost entirely on Microsoft 365 and other SaaS services, with no significant on-premises infrastructure, the simplest model is a cloud-only approach with devices connected to Microsoft Entra . In this scenario:

• All users and devices reside in Microsoft Entra ID.
• Device and key registration is done directly in the cloud.
• No enterprise PKI is needed nor domain controller certificates.
• SSO is based on PRT and Microsoft Entra tokens for applications.

It is the most direct option for cloud-first companies, with low infrastructure costs and relatively simple deployment , ideal when on-premises resources are not available or are minimal.

Hybrid model: the most common case

The vast majority of companies fall somewhere in between: legacy Active Directory combined with synchronized Microsoft Entra ID . WHfB shines here, but it's also where configuration problems are most common if not properly planned.

In a hybrid environment, identities are synchronized using Microsoft Entra Connect Sync, and there are several possible combinations of deployment model (hybrid) and trust type (cloud Kerberos, key, or certificate) . The goal is typically to offer:

• SSO to cloud services (SharePoint Online, Teams, OIDC/SAML applications).
• Transparent access to local resources (shares, apps Kerberos, VPN, RDP).
• A phased exit route for passwords, while maintaining legacy applications.

The main types of trust in hybrid scenarios are:

• Kerberos in the cloudMicrosoft Entra Kerberos issues TGTs for Active Directory without requiring additional Public Key Infrastructure (PKI). This is the most modern and simplest hybrid model, as it leverages existing FIDO2 infrastructure and does not require synchronizing public keys with Active Directory.
• Key TrustUsers authenticate to Active Directory using a device-bound key; domain controllers require specific certificates. PKI is required for domain controllers, but not for user certificates.
• Certificate confidenceUser authentication certificates are issued and used to obtain Kerberos TGTs. This requires full PKI, AD FS as a CRA, and more intensive configuration.

Choosing the right type of trust is crucial: none is inherently "more secure ," but they do vary in cost, complexity, and infrastructure requirements. Cloud-based Kerberos trust is often the best option for new deployments, provided the client and server Windows versions meet the minimum requirements.

Pure local model

Organizations with strong regulatory restrictions, or with little or no cloud adoption, can opt for a 100% on-premises WHfB deployment, supported by Active Directory and AD FS . In this model:

• Device registration is managed AD FS.
• Authentication can be key-based or certificate-based, but it is always backed by an enterprise PKI.
• MFA options include adapters for AD FS or solutions like Azure MFA Server (already legacy) integrated on-premises.

This approach provides complete control over authentication data , but requires considerable maintenance effort (PKI, AD FS, publication of CRLs accessible by non-domain-joined computers, etc.), something that not all organizations are willing to undertake in the long term.

Accessible PKI, domain controller certificates, and CRLs

In models that rely on certificates (whether for users, domain controllers, or both), the PKI becomes the core of trust. WHfB requires strict validation of KDCs when a Microsoft Entra-joined device authenticates against a local domain.

In practice, this means that the domain controller certificate must meet a number of technical conditions: issued by a trusted root CA for the device, based on the Kerberos authentication template, with a “KDC authentication” EKU, correct DNS name, RSA 2048 and SHA-256 as the signature algorithm , among other requirements.

Furthermore, it is essential that the device can verify certificate revocation . This is where the classic problem with CRLs arises: a device joined only to Microsoft Entra cannot read LDAP paths in Active Directory if it has not yet authenticated, so it is necessary to publish the CRL distribution point on an HTTP URL accessible without authentication.

This involves preparing a web server (IIS, for example), creating a virtual directory (cdp), adjusting NTFS and share permissions, disabling offline caching , configuring the CA to publish the CRL on that share and expose it via HTTP. Once this is done, the domain controller certificates must be renewed to include the new CDP, and the enterprise root certificate must be deployed to devices joined to Microsoft Entra (e.g., using Intune and a "trusted certificate" profile).

Directory synchronization, MFA, and device configuration

The end-user experience with Windows Hello for business depends largely on how directory synchronization, MFA, and policy configuration are integrated.

In hybrid deployments, Microsoft Entra Connect Sync not only synchronizes accounts; it can also synchronize critical attributes such as msDS-KeyCredentialLink , which contains the WHfB public key required for Active Directory authentication. In on-premises environments with Azure MFA Server, synchronization is used to import users to the MFA server, which then queries the cloud service for verification.

Regarding multi-factor authentication, organizations have several options: Microsoft Entra MFA for cloud or hybrid scenarios , external methods integrated through external authentication in Entra ID or via federation, and third-party MFA adapters for AD FS in on-premises environments. The FederatedIdpMfaBehavior flag in federated domains determines whether Entra ID accepts, requires, or ignores MFA performed by the federated IdP, which can be critical for WHfB provisioning to function correctly.

WHfB configuration on computers can be done using Group Policy (GPO) or CSP via MDM (e.g., Intune). In modern organizations, it's common practice to enable automatic WHfB registration, enforce MFA on the first login, define PIN complexity policies, and control which biometric methods are accepted (only certified sensors, IR cameras, etc.).

In parallel, it is essential to consider the recovery experience: self-service PIN reset, alternative methods such as FIDO2 keys, and BitLocker encryption to protect data at rest if the device is lost or stolen.

Licenses, system requirements, and practical limitations

One common myth is that using WHfB always requires Microsoft Entra ID P1 or P2 . In reality, WHfB's core functionality is available with the free Entra ID tier, and the multi-factor authentication required for passwordless provisioning can also be enabled without premium licenses, although features such as automatic MDM enrollment, advanced conditional access, and deferred device writes do require higher tiers.

In terms of operating system, virtually all modern client versions of Windows support WHfB, but Kerberos cloud reliance requires specific minimums (for example, Windows 10 21H2 with certain patches or specific versions of Windows 11 ). On the server side, any supported version of Windows Server can generally act as a domain controller, although the Kerberos cloud component requires specific versions and updates on the domain controllers.

Beyond the technical aspects, there are very practical challenges: shared equipment where WHfB, being device and user-specific, doesn't fit in well ; hardware without TPM 2.0 or biometric sensors; or environments where the cost of renewing old systems, deploying PKI, and upgrading 2012 data centers makes full adoption of WHfB unattractive in the short term.

In many cases, the reasonable path is to combine WHfB with other passwordless factors (FIDO2 keys, smart cards, telephone authentication) to cover shared workstations, non-Windows platforms, or highly mobile users, leaving WHfB as the primary authenticator on corporate laptops paired with Entra or hybrid systems.

Looking at the big picture, Windows Hello for Business offers much more than just a "nice PIN": it introduces hardware-bound asymmetric credentials, strict KDC verification, deep integration with Microsoft Entra ID and Active Directory, and a robust framework for secure SSO both in the cloud and on-premises. However, its true value compared to basic Windows Hello depends on your starting point: in modern cloud-first or hybrid environments with up-to-date PKI and DCs, the leap in security and management clearly justifies the effort; in very old domains with little infrastructure prepared and no modernization plans, it might make more sense to first upgrade hardware, PKI, and access control before embracing the full potential of WHfB.

Related articles:

How to know which apps have access to your camera, microphone, or location in Windows 11

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.