Windows Hello: Passwordless Authentication Explained

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.

Key Takeaways

• There is no direct migration path from a Certificate Trust deployment to Cloud Kerberos Trust. The existing Windows Hello container must be deleted before a device can move to Cloud Kerberos Trust.
• Windows Hello replaces passwords with a TPM-backed asymmetric key pair. The private key never leaves the device, so there is no shared secret to phish, steal, or replay.
• Windows Hello for Business (WHfB) supports three enterprise trust models: Cloud Kerberos Trust, Key Trust, and Certificate Trust. Cloud Kerberos Trust is Microsoft’s recommended default for hybrid deployments.
• Accounts in privileged Active Directory groups, including Domain Admins, cannot authenticate through Cloud Kerberos Trust by design, since the Password Replication Policy on the AzureADKerberos object blocks them.
• Microsoft Entra passkeys on Windows reached general availability in 2026, letting Windows Hello act as a FIDO2 passkey authenticator on devices that are not Entra-joined.

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.e-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 enrollment, the device generates an asymmetric key pair.

Key Generation and Storage

• The TPM generates a private and 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. The 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 and 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, under WHfB, on-premises resources.

Because the private key is bound to the TPM and the PIN or 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.omised 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.	Hybrid and pure Entra-joined environments. Microsoft’s recommended default for new deployments.
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, 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, a cloud-issued Kerberos ticket, which the domain controller exchanges for a full on-premises Kerberos TGT, granting SSO to on-premises resources such as file shares and intranet applications without a second sign-in prompt. No password is involved at any stage.

Two operational limits apply. First, accounts that are direct or indirect members of privileged built-in security groups, including Domain Admins, cannot authenticate through Cloud Kerberos Trust. The AzureADKerberos object behaves like a read-only domain controller, and its default Password Replication Policy blocks privileged accounts from using it, the same restriction that applies to standard RODCs.

Microsoft advises against relaxing this policy because of the attack path it would open between Entra ID and Active Directory. Second, Cloud Kerberos Trust does not support RDP or VDI sign-in with supplied credentials; organizations that need certificate-based smart card equivalence for those scenarios should use Certificate Trust or Remote Credential Guard instead.

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 Entra Passkeys

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, the website’s domain, preventing it from functioning on any spoofed login page.

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.

Entra Passkeys via Windows Hello (2026)

Microsoft began a staged rollout of Microsoft Entra passkeys on Windows in public preview in March 2026, extending passwordless authentication to Windows devices that are not Entra-joined or managed. The capability has since moved to general availability, rolling out worldwide through the first half of 2026 and to U.S. government cloud environments (GCC, GCC High, and DoD) in the following months. At general availability, Microsoft removed the public preview requirement that administrators explicitly allow-list Windows Hello AAGUIDs in a passkey profile; organizations whose passkey profiles already permit device-bound, non-attested passkeys now have Entra passkeys on Windows enabled by default.

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 sync across devices. Each device requires separate registration.
• Windows Hello for Business remains the recommended method for managed, Entra-joined devices. Entra passkeys on Windows supplement unmanaged device scenarios and do not support device sign-in.
• A WHfB credential and an Entra passkey cannot coexist in the same container for the same account. If a WHfB credential exists, passkey registration is blocked until it is removed, so WHfB takes precedence on managed devices. Microsoft notes this block may lift once a user’s combined total of passkeys, WHfB credentials, and Mac Platform Credentials on the device exceeds 50, a high-volume edge case unlikely to affect typical single-account or few-account devices.

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 required per user
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 and 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, a biometric, or something you know, a 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.

Phishing Resistance

Accessibility and user experience

Biometric sign-in removes barriers for users who struggle with password entry. Facial recognition 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.

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 are required.

Directory and Identity Prerequisites

• Cloud Kerberos Trust: a Microsoft Entra ID tenant, Entra Connect sync, Windows Server 2016 or later DCs, and Intune for policy delivery.
• Key Trust: an enterprise PKI to issue DC Kerberos authentication certificates (RSA 2048 / SHA-256 minimum, Key Storage Provider required).
• Certificate Trust: on-premises AD FS, an 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, which enforces TPM key storage). Certificate Trust policies must not be configured simultaneously, since 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

WWhile 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.
• Trust models are not freely interchangeable once deployed. Migrating from Key Trust to Cloud Kerberos Trust is supported directly through Group Policy or Intune. There is no equivalent direct path from Certificate Trust to Cloud Kerberos Trust: the existing Windows Hello container must be deleted before the device can be redeployed under Cloud Kerberos Trust. Organizations planning a move away from Certificate Trust should account for this re-enrollment step rather than treating it as a policy-only change.

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 biometrics 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 on 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 on 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, since this will become an active planning consideration within the five-to-ten-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 now-generally-available Entra passkey integration is a step toward this convergence, allowing organizations to standardize on FIDO2 across their heterogeneous device fleets without managing separate authentication mechanisms per platform.

How Encryption Consulting Helps

Deploying Windows Hello for Business, whether on Cloud Kerberos Trust, Key Trust, or Certificate Trust, depends on the health of the identity and PKI infrastructure behind it. Encryption Consulting’s PKI Services provide end-to-end consultation for enterprises planning or troubleshooting a WHfB rollout: designing the CA hierarchy and certificate templates a Certificate Trust deployment needs, modernizing legacy domain controller templates to support Key Trust, and validating Entra Connect and Entra Kerberos configuration for Cloud Kerberos Trust.

For organizations that want to remove PKI operational overhead entirely, PKI-as-a-Service delivers a managed, cloud-hosted CA so IT teams can support Key Trust or Certificate Trust deployments without operating on-premises PKI infrastructure directly. Once WHfB is deployed, CertSecure Manager gives IT and security teams visibility and lifecycle automation across the certificates that Key Trust and Certificate Trust models depend on, including domain controller certificates and user sign-in certificates, reducing the risk of an expired or misconfigured certificate breaking authentication for an entire site.

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, a 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), 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, including finance, healthcare, and government, have 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.

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

Not necessarily. Cloud Kerberos Trust, Microsoft’s recommended default deployment model, 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.

Can Every Account Use Cloud Kerberos Trust?

No. Accounts that are direct or indirect members of privileged built-in security groups, including Domain Admins, cannot authenticate through Cloud Kerberos Trust. The AzureADKerberos object is subject to the same Password Replication Policy restrictions as a standard read-only domain controller, which blocks privileged accounts by design. Microsoft does not recommend relaxing this policy, since doing so introduces an attack path between Entra ID and Active Directory. Organizations that need WHfB for privileged accounts should use Key Trust or Certificate Trust for those accounts instead.

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 container must 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.

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. Windows Hello also supports Entra ID passkey registration, now generally available, 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 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.

Choose the Right Authentication Model With Confidence

Ready to plan a Windows Hello for Business rollout or resolve a hybrid trust model issue? See PKI Services in action, or read about Windows Hello best practices.