Windows Hello: Passwordless Authentication Explained

Quick Answer: Windows Hello is Microsoft’s built-in passwordless authentication framework for Windows 10 and 11, enabling users to sign in using biometrics (face, fingerprint, or iris) or a PIN backed by cryptographic keys stored in the device’s Trusted Platform Module (TPM). Unlike passwords, Windows Hello credentials never leave the device and are cryptographically bound to the local hardware, making them resistant to phishing, credential theft, and replay attacks. Windows Hello for Business extends this capability to enterprise environments, supporting Microsoft Entra ID, Active Directory, and FIDO2 passkey authentication via three deployment trust models.

Why Passwords Are No Longer Sufficient

According to Microsoft’s Digital Defence Report 2024, multi-factor authentication blocks over 99% of identity-based attacks, yet password spraying, credential stuffing, and phishing campaigns continue to account for the majority of initial access events across Microsoft’s global telemetry, which recorded more than 7,000 password attacks per second over the past year. The core problem is structural: passwords are shared secrets. They travel across networks, get stored in databases, and are routinely reused across services. Any single compromise can cascade into multiple account takeovers.

The five failure modes of password-based authentication are well-documented and persistent:

• Brute-force and dictionary attacks that exploit weak or reused credentials
• Phishing campaigns that trick users into submitting credentials to spoofed sites
• Credential stuffing that exploits passwords leaked from unrelated breaches
• Password database theft exposing hashed credentials to offline cracking
• Accessibility barriers that disadvantage users with visual impairments or motor limitations

Windows Hello addresses all five failure modes by replacing the shared-secret model with a device-bound, asymmetric cryptographic credential that cannot be phished, replicated, or transmitted.

What Is Windows Hello?

Windows Hello is Microsoft’s biometric and PIN-based authentication framework, introduced in Windows 10 and expanded significantly in Windows 11. It replaces password entry with one of three biometric gestures: facial recognition, fingerprint scanning, or iris scanning, depending on the device’s hardware capabilities. A PIN is also supported as a fallback or primary method; critically, this PIN differs from a password in that it is device-specific and backed by the TPM rather than transmitted to a server.

Windows Hello exists in two tiers:

Feature	Windows’s Hello (Consumer)	Windows Hello for Business (WHfB)
Target user	Personal / Microsoft Account	Enterprise / Entra ID or AD
Credential type	Device-bound key (software if no TPM)	TPM-backed asymmetric key pair (required by policy)
Identity provider	Microsoft Account (MSA)	Microsoft Entra ID, Active Directory, AD FS
FIDO2 support	Yes, FIDO Alliance certified since Windows 10 1903	Yes, extends to Entra passkey (FIDO2) from 2026
Enterprise policy (Intune / GPO)	Limited	Full MDM / Group Policy support
On-premises resource access	Not supported	Yes, via Cloud Kerberos Trust or Certificate Trust

How Windows Hello Works: The Cryptographic Foundation

Understanding Windows Hello requires understanding how it replaces the password model with public-key cryptography. During enrolment, the device generates an asymmetric key pair:

Key Generation and Storage

• The TPM generates a private/public key pair for the user on that device.
• The private key is sealed inside the TPM and never exported, it cannot be extracted even by the operating system.
• The public key is registered with the identity provider (Microsoft Entra ID, Active Directory, or AD FS) and associated with the user account.
• Biometric data (facial template, fingerprint template) is stored locally in an encrypted database at C:\Windows\System32\WinBioDatabase. It never leaves the device and is never transmitted to Microsoft’s servers.

Authentication Flow

When a user signs in, the sequence is:

1. User presents a biometric gesture or PIN to the Windows Hello container.
2. The gesture unlocks access to the private key stored in the TPM. The PIN or biometric acts as a local unlock factor, it never leaves the device.
3. The device uses the private key to sign a cryptographic challenge from the identity provider.
4. The identity provider verifies the signature using the registered public key and issues an authentication token.
5. The user gains access to Windows, Microsoft 365, Entra-protected apps, and (in WHfB) on-premises resources

Because the private key is bound to the TPM and the PIN/biometric never leaves the device, this authentication model eliminates the attack vectors that target passwords: there is no credential to phish, no database to breach, and no network-transmitted secret to intercept.

Enhanced Sign-in Security (ESS)

Windows 11 introduces Enhanced Sign-in Security (ESS), which isolates face-template matching inside a Virtualization-Based Security (VBS) enclave that establishes a secure channel to TPM 2.0 during boot. For fingerprint, ESS relies on match-on-sensor hardware that performs matching and template storage on the sensor module itself. Under ESS, even a compromised operating system kernel cannot access biometric template data or inject spoofed biometric signals. ESS requires purpose-built biometric sensors and is enforced via policy for high-assurance environments.

Windows Hello for Business: Enterprise Deployment Models

For organizations deploying Windows Hello for Business, Microsoft supports three trust models. Choosing the right model depends on directory topology, existing PKI infrastructure, and on-premises access requirements.

Trust Model	How It Works	Best For
Cloud Kerberos Trust	Uses Microsoft Entra Kerberos to issue partial TGTs; no PKI or key sync required. Simplest deployment path.	Hybrid Entra joined and pure Entra joined environments. Recommended for new deployments in 2025–2026.
Key Trust	Public key stored in Active Directory. DCs require Kerberos authentication certificates; Entra Connect syncs keys.	Hybrid environments with an existing enterprise PKI that can issue DC certificates.
Certificate Trust	AD FS issues sign-in certificates into the WHfB container. Full PKI infrastructure required on-premises.	Organizations requiring certificate-based smart card equivalence or RDP/VDI scenarios that need user certificates.

Cloud Kerberos Trust: The Recommended Path

Cloud Kerberos Trust, introduced in 2022 and now the recommended deployment model for 2025 and beyond, removes the two largest barriers to WHfB adoption: the need for a full on-premises PKI and the need to synchronize public keys into Active Directory. Instead, it leverages the same Entra Kerberos infrastructure that already enables FIDO2 passwordless sign-in for hybrid environments. Administrators configure it with a single PowerShell command to create the AzureADKerberos object, followed by two Intune policies (or GPOs).

The authentication flow under Cloud Kerberos Trust: when a user unlocks their device with a PIN or biometric, the TPM releases the WHfB private key, which signs an authentication request to Entra ID. Entra ID returns a Partial TGT (cloud-issued Kerberos ticket), which the domain controller exchanges for a full on-premises Kerberos TGT, granting seamless SSO to on-premises resources such as file shares and intranet applications. No password is involved at any stage.

Certificate Trust deployments require a functioning enterprise PKI to issue both domain controller certificates and optional user sign-in certificates. Encryption Consulting’s PKI Services provide end-to-end PKI design, implementation, and managed services for IT environments, including the CA hierarchy, certificate templates, and Intune integration required for a Certificate Trust WHfB deployment.

Windows Hello, FIDO2, and Passkeys in 2026

Windows Hello has been FIDO2-certified by the FIDO Alliance since Windows 10 version 1903. This means Windows Hello acts as a platform authenticator compliant with the WebAuthn and CTAP2 specifications, the same open standards underlying passkeys across browsers, operating systems, and identity providers.

Windows Hello as a FIDO2 Platform Authenticator

When a website or application requests FIDO2 authentication, Windows Hello serves as the local authenticator: it generates a FIDO2 key pair in the Windows Hello key container, protects the private key with the TPM, and releases it only after the user satisfies the local biometric or PIN check. The result is a device-bound passkey that cannot be phished because it is cryptographically bound to a specific origin (website URL), preventing it from functioning on any spoofed login page.

Entra Passkeys via Windows Hello (2026)

In March 2026, Microsoft began a staged public preview allowing Windows Hello to act as a FIDO2 passkey authenticator for Microsoft Entra ID accounts, extending passwordless authentication to Windows devices that are not Entra-joined or managed. Under this configuration, users register a device-bound passkey stored in the Windows Hello container, authenticated using face, fingerprint, or PIN. The passkey is cryptographically bound to the device and never transmitted over the network, making it immune to phishing and credential-stuffing attacks.

Key details of the Entra passkey integration:

• Each Entra account registers its own passkey per device; multiple accounts can coexist on a single machine.
• Passkeys are device-bound and cannot be synced across devices. Each device requires separate registration.
• Administrators enable Passkeys (FIDO2) as an authentication method in Entra ID and create a passkey profile that includes Windows Hello AAGUIDs (authenticator identifiers).
• Windows Hello for Business remains the recommended method for managed Entra-joined devices; Entra passkeys supplement unmanaged device scenarios.
• A WHfB credential and an Entra passkey cannot coexist in the same container for the same account. If WHfB exists, passkey registration is blocked until the WHfB credential is removed, so WHfB takes precedence on managed devices. This block may not apply once the user exceeds 50 total platform credentials.

Windows Hello vs. FIDO2 Security Keys

Dimension	Windows Hello (Platform Authenticator)	FIDO2 Security Key (Roaming Authenticator)
Portability	Device-bound. User must re-enroll on each device	Portable across devices via USB, NFC, or Bluetooth
Ideal user	Assigned-device workers, knowledge workers	Frontline workers, shared-device environments
Infrastructure cost	No hardware purchase required (uses existing TPM)	Physical key purchase per user required
PKI requirement	Optional (Certificate Trust model only)	None
RDP/VDI sign-in	Supported with Remote Credential Guard or Certificate Trust	Supported via Web Sign-in on Windows 11 24H2 + Windows Server 2025

Security and Operational Benefits

Phishing Resistance

Windows Hello credentials are cryptographically bound to the relying party origin (the domain of the website or identity provider). A credential registered for login.microsoftonline.com will not respond to a challenge from a spoofed lookalike domain. This origin-binding property, defined in the WebAuthn specification, is the primary reason phishing attacks are ineffective against FIDO2 and Windows Hello authentication.

No Credential Database Risk

Because no shared secret is stored server-side, there is no password hash or credential to steal from the identity provider. The server stores only the user’s public key, which is worthless to an attacker without access to the corresponding private key sealed in the device TPM.

MFA by Design

Windows Hello is inherently multi-factor: it combines something you have (the registered device with the TPM-bound key) with something you are (biometric) or something you know (device-local PIN). This satisfies MFA requirements under NIST SP 800-63B Authenticator Assurance Level 2 (AAL2) for most enterprise use cases. High-assurance environments requiring AAL3 can enforce TPM attestation via policy, verifying that the key resides in certified hardware.

Accessibility and User Experience

Biometric sign-in removes barriers for users who struggle with password entry. Facial recognition in particular enables hands-free authentication, and the device-local nature of Windows Hello means there are no servers to be unavailable during an outage. Microsoft reports that organizations that have moved to Windows Hello see measurable reductions in help desk calls related to password resets, one of the highest-volume IT support categories.

FIDO2 SSO Across Applications

Windows Hello credentials work across any application or website supporting FIDO2/WebAuthn, including Microsoft 365, Azure-protected apps, GitHub, Dropbox, financial services platforms, and a growing ecosystem of enterprise SaaS applications. In enterprise deployments, WHfB provides single sign-on to both cloud and on-premises resources (via Kerberos) without requiring users to re-authenticate for each service.

Deploying Windows Hello for Business: What IT Needs to Know

Deploying Windows Hello for Business requires planning across four areas: hardware, directory, policy, and user onboarding.

Hardware Prerequisites

• TPM 2.0 is required for enterprise-grade key protection (TPM 1.2 is supported but not recommended due to policy variability).
• For facial recognition: an infrared camera with anti-spoofing capability is required. Standard webcams are not sufficient for Windows Hello Face.
• For Enhanced Sign-in Security (ESS): specialized ESS-compatible biometric sensors and a VBS-capable device with TPM 2.0.

Directory and Identity Prerequisites

• Cloud Kerberos Trust: Microsoft Entra ID tenant, Entra Connect sync, Windows Server 2016 or later DCs, Intune for policy delivery.
• Key Trust: Enterprise PKI to issue DC Kerberos authentication certificates (RSA 2048 / SHA-256 minimum, Key Storage Provider required).
• Certificate Trust: On-premises AD FS, enterprise PKI with user certificate templates, and Intune or GPO for policy.

Policy Configuration via Intune

For Cloud Kerberos Trust, the Intune Settings Catalog requires three key policy settings: Use Windows Hello for Business (Enabled), Use Cloud Trust for On-Premises Authentication (Enabled), and Require Security Device (Enabled, enforces TPM key storage). Certificate Trust policies must not be configured simultaneously, as certificate trust overrides cloud trust when both are present.

User Enrollment

After policy is deployed and the device satisfies prerequisites, Windows Hello for Business provisioning launches automatically after the user’s first sign-in. The user sets a PIN (enforced for complexity and length by policy), then optionally enrolls biometrics. The PIN is device-specific, never transmitted over the network, and enforced by the TPM lockout policy, making brute-force attempts against it impractical without physical device access.

Windows Hello and PKI: The Connection

While Cloud Kerberos Trust reduces the PKI dependency for most deployments, PKI remains relevant to Windows Hello in several scenarios:

• Certificate Trust deployments issue user sign-in certificates into the Windows Hello container via an enterprise CA, providing smart card equivalence for scenarios requiring certificate-based authentication.
• Domain Controller certificates are required under both Key Trust and Certificate Trust models. These templates must use modern cryptography (RSA 2048+, SHA-256, Key Storage Provider category), not legacy v1 templates.
• TPM key attestation, when enforced via policy, requires the CA to verify that the WHfB key was generated inside a certified TPM, providing a hardware assurance chain.
• Certificate Trust supports RDP/VDI scenarios and S/MIME email signing, use cases not covered by key-based or cloud Kerberos trust models.

For organizations with a legacy PKI that predates Windows Hello, template modernization is a prerequisite. Legacy Domain Controller templates (v1) lack the Kerberos Authentication EKU and do not use CNG Key Storage Providers, both of which are required for WHfB Certificate Trust to function.

Regulatory Alignment and Compliance Considerations

Windows Hello for Business aligns with multiple current regulatory and standards frameworks:

Framework / Regulation	Windows Hello Relevance
NIST SP 800-63B	WHfB with TPM-backed keys and biometric satisfies AAL2. TPM attestation and ESS can support AAL3 requirements.
CISA Phishing-Resistant MFA Guidance	FIDO2-based authentication (which WHfB implements) is explicitly listed as a phishing-resistant MFA method in CISA’s guidance for federal agencies.
Microsoft Secure Future Initiative	Microsoft’s SFI (launched November 2023) mandates MFA for all Microsoft cloud accounts. Windows Hello is the primary consumer and enterprise delivery mechanism.
Zero Trust Architecture	WHfB satisfies the ‘verified identity’ pillar of NIST SP 800-207 Zero Trust by binding authentication to a specific device and user biometric, not a shared credential.
NIS2 Directive (EU)	NIS2 Article 21 requires ‘multi-factor authentication’ for entities in scope. WHfB satisfies this requirement for Windows-based environments.

Looking Ahead: Post-Quantum Considerations and the Passwordless Future

Microsoft’s direction is unambiguous: in May 2025, the company announced that all new Microsoft accounts are ‘passwordless by default,’ removing the password as a sign-in option at account creation. This accelerates a transition that Windows Hello has been enabling since 2015. For enterprise IT teams, the question is no longer whether to deploy Windows Hello for Business, but which trust model, at what scale, and in what timeline.

Post-Quantum Cryptography and Windows Hello

The asymmetric key pairs generated by Windows Hello currently rely on elliptic curve or RSA algorithms, both of which are theoretically vulnerable to cryptographically-relevant quantum computers. NIST finalized its post-quantum cryptography standards in August 13, 2024 (FIPS 203, FIPS 204, and FIPS 205), and Microsoft has stated its commitment to PQC migration across its authentication infrastructure. Organizations deploying Windows Hello for Business today should monitor NIST PQC migration guidance and Microsoft’s roadmap for algorithm agility in the WHfB key container, as this will become an active planning consideration within the 5–10 year horizon.

Encryption Consulting’s cryptographic inventory and agility programs, built around CBOM Secure, help organizations map existing cryptographic dependencies (including authentication infrastructure) before a migration is required, rather than after.

Passkeys as the Convergence Point

The FIDO2/passkey ecosystem is converging on a unified model where platform authenticators like Windows Hello, Apple’s Passkeys, and Android’s FIDO2 implementation offer a consistent, phishing-resistant sign-in experience across operating systems. Windows Hello’s Entra passkey integration (public preview from March 2026) is a step toward this convergence, allowing organizations to standardize on FIDO2 across their heterogeneous device fleets without managing separate authentication mechanisms per platform.

Frequently Asked Questions

What is Windows Hello and how does it differ from a password?

Windows Hello is Microsoft’s passwordless authentication system for Windows 10 and 11. Instead of transmitting a shared secret (password) to a server, it uses a TPM-backed asymmetric key pair where the private key never leaves the device. The user unlocks the private key locally with a biometric or PIN, and the device signs a cryptographic challenge from the identity provider. The server verifies the signature using the user’s public key, no password is ever transmitted or stored server-side.

Is Windows Hello secure enough for enterprise environments?

Yes. Windows Hello for Business with TPM-backed keys meets NIST SP 800-63B Authenticator Assurance Level 2 (AAL2), which is the standard required for most enterprise applications. It is explicitly listed as a phishing-resistant MFA method in CISA guidance for federal agencies. For higher-assurance scenarios, TPM attestation enforcement and Enhanced Sign-in Security (ESS) can raise the assurance level further. Organizations in regulated industries (finance, healthcare, government) have successfully deployed WHfB as their primary authentication mechanism.

What is the difference between Windows Hello for Business and consumer Windows Hello?

Consumer Windows Hello is configured for personal Microsoft accounts and does not support enterprise identity providers, Group Policy, Intune management, or on-premises resource access. Windows Hello for Business (WHfB) is the enterprise variant, integrated with Microsoft Entra ID and/or Active Directory, managed via Intune or GPO, and capable of providing SSO to both cloud and on-premises resources via Cloud Kerberos Trust or Certificate Trust deployment models.

Do I need a PKI to deploy Windows Hello for Business?

Not necessarily. Cloud Kerberos Trust, Microsoft’s recommended deployment model for 2025 and beyond, does not require an enterprise PKI or certificate infrastructure for end-user devices. It requires only a Microsoft Entra Kerberos object (created with a single PowerShell command) and Intune or GPO policy delivery. Certificate Trust, which does require PKI, is reserved for environments needing certificate-based authentication equivalence, RDP/VDI scenarios, or S/MIME signing.

What happens if a user’s device is lost or stolen?

Because Windows Hello credentials are device-bound, a credential cannot be used on a different device. If a device is lost, an administrator can immediately remove the registered public key from the user’s Entra ID or Active Directory account, invalidating all authentication attempts from that device. The biometric data stored on the device is encrypted and cannot be reconstructed into a usable biometric sample, it has no value to a thief without the device’s own biometric sensor.

How does Windows Hello relate to FIDO2 passkeys?

Windows Hello is a FIDO2-certified platform authenticator, meaning it implements the WebAuthn and CTAP2 specifications. Any credential created via Windows Hello for a FIDO2-enabled website or application is technically a passkey, a device-bound FIDO2 credential. From March 2026, Windows Hello also supports Entra ID passkey registration, allowing organizations to use Windows Hello as a FIDO2 passkey authenticator for Microsoft Entra accounts, including on devices that are not Entra-joined.

Can Windows Hello be used for RDP or VDI sessions?

This depends on the deployment model. Cloud Kerberos Trust does not support RDP with supplied credentials. Certificate Trust supports RDP/VDI by enrolling a user certificate into the WHfB container. Alternatively, Remote Credential Guard can be used to protect RDP sessions without requiring Certificate Trust. From Windows 11 24H2 and Windows Server 2025, FIDO2 authentication (including Windows Hello) can be used for RDP via Web Sign-in, when enabled on both client and host.

Conclusion

Windows Hello represents a fundamental shift in how authentication works on Windows, replacing a shared-secret model that has failed for decades with a cryptographic, device-bound, phishing-resistant alternative. For IT teams, the maturity of the deployment ecosystem in 2025–2026, particularly the Cloud Kerberos Trust model, Entra passkey integration, and FIDO2 convergence, means that deploying Windows Hello for Business is now straightforward for most organizations, regardless of whether they operate in a pure cloud, hybrid, or on-premises environment.

The security case is clear: phishing-resistant MFA is explicitly required by CISA guidance for high-value accounts, referenced in NIS2 compliance requirements, and central to Microsoft’s Secure Future Initiative. Windows Hello for Business is the delivery mechanism for that requirement across Windows device fleets.

PKI Services from Encryption Consulting

Deploying Windows Hello for Business with Certificate Trust, or migrating from Key Trust to Cloud Kerberos Trust, requires a well-designed PKI foundation and careful integration with Microsoft Entra ID and Intune.

Encryption Consulting provides end-to-end PKI design, implementation, and managed services for enterprise identity infrastructure, including Windows Hello for Business deployment support.

Get complete PKI consultation support →