Windows as a Passkey Provider: Where WHfB Ends and…

For years, Windows Hello for Business (WHfB) was the passwordless credential for signing in to Windows and Microsoft services. But the world moved to passkeys - the same FIDO2 cryptography, now the mainstream way to log in to any website. The good news for endpoint teams: Windows Hello is already a passkey provider. Windows can create, store, and use passkeys with the device's PIN or biometric, and in Windows 11 24H2 it gained the controls enterprises need to govern them. This closing post in the series maps where WHfB ends and the Windows passkey story begins.

The problem: WHfB and "passkeys" sound like the same thing (they mostly are)

Admins get confused because WHfB, FIDO2 security keys, and passkeys all use the same underlying FIDO2 public/private key cryptography. The useful mental model: a passkey is a FIDO2 credential for signing in to a website or app, and Windows Hello is one of the providers that can hold and unlock those passkeys - using the exact same PIN or biometric gesture your users already have for WHfB. WHfB signs you in to Windows and Entra; Windows-Hello-provided passkeys sign you in to the wider web. Same unlock, different relying parties.

Note: Windows has provided a native passkey management experience since Windows 11 version 22H2 with KB5030310 - but passkeys can be used on all supported Windows client versions. When a user creates a passkey "with Windows Hello," the private key is stored on the device and unlocked by their Hello gesture; the relying party only ever stores the public key.

Why it happens: the same gesture now covers the whole web

The private keys behind passkeys can only be used after the user unlocks them with their Windows Hello factor - biometric or PIN. That means every investment you made in WHfB (TPM-backed keys, the PIN complexity policy, biometric enrolment) now also protects the user's passkey sign-ins to third-party sites. You are not deploying a second thing; you are extending the first. And because passkeys are phishing-resistant and unique per site, they eliminate the reused-password risk WHfB never touched (WHfB only covered your own sign-in).

How to verify: check a device's passkey capability

Passkey capability tracks the Windows build. Confirm the version and that Hello is set up (Hello is the unlock factor for Windows-provided passkeys):

Windows PowerShell

# Build 22621+ = 22H2 (native passkey management); 26100+ = 24H2 (privacy consent) [System.Environment]::OSVersion.Version Major Minor Build Revision ----- ----- ----- -------- 10 0 26100 0 # 24H2 - passkey access controls available # Confirm Hello is provisioned (the unlock factor for Windows passkeys) dsregcmd /status | findstr /i "NgcSet"

Users create and manage their passkeys from the Windows account/passkey settings and can sign in to a site either with the local Hello gesture or, for a site opened on another device, by using their phone as a companion authenticator over Bluetooth.

Watch out: Cross-device passkey sign-in (using a phone to authenticate on the PC) needs Bluetooth on both devices. Many organizations restrict Bluetooth - which silently breaks that flow. If you restrict Bluetooth, allow it specifically for the FIDO2 client-to-authenticator services rather than blocking it outright, or cross-device passkeys will not work and users will not know why.

Note: Windows supports both device-bound passkeys (the private key never leaves this device - what Windows Hello creates) and synced passkeys from providers like iCloud Keychain or Google Password Manager. Device-bound is the higher-assurance option and the only one that supports attestation - align this with the FIDO2/AAGUID attestation decisions from earlier in this series.

The fix: govern passkeys with the 24H2 controls

The big shift for IT is that Windows 11 24H2 added passkey privacy consent. Before an application can access passkeys, the user is prompted to allow or block it, and that access is managed per-application:

Settings›Privacy & security›Passkey access

From that page a user (or, increasingly, policy) can allow or block individual applications from touching passkeys. If a user declines consent for an app, passkey registration and authentication simply do not work for that app until access is restored from the same page. This is the control that lets enterprises reason about which software can act as, or call, a passkey provider on a managed device.

Settings — Privacy & security › Passkey access

Contoso Line-of-Business appAllowed

Unknown consumer appBlocked

Gotcha: Enterprise policy-based management of the passkey consent prompt was rolling out through Windows Insider builds and targeted for general availability around mid-2026 - so depending on your build, you may only have the per-user Settings toggle, not a fully policy-driven control yet. Check your fleet's build before you promise security a locked-down passkey-access posture; the Settings page visibility can be managed today via the Settings Policy CSP even where full consent policy is not yet GA.

Proof it worked: where this leaves WHfB and passkeys

WHfB is not going away - it remains the strong, TPM-backed way to sign in to Windows and Entra, and it is one of the three methods that satisfy phishing-resistant Conditional Access. What is changing is the scope: the same Hello gesture your users already trust now also unlocks passkeys for the entire web. The strategic posture for 2026 is not "WHfB or passkeys" - it is WHfB for platform sign-in, Windows Hello passkeys for web/app sign-in, and FIDO2 keys as the portable, high-assurance companion. One unlock, everywhere.

Tip: Treat this as the capstone of your passwordless rollout, not a separate project. If you have already deployed WHfB with TPM-backed keys and a sane PIN policy, enabling and governing Windows passkeys is mostly turning on controls you are ready for. Audit your fleet's Windows build first (22H2 for management, 24H2 for the privacy-consent controls), confirm your Bluetooth policy does not silently block cross-device sign-in, and decide device-bound-versus-synced deliberately - then let the credential your users already know carry them across the whole web.

References

    
    PowerShell Scripts — Windows Passkey Capability
  
Script for this post is in Daily-Tasks.

      ●
      Get-WindowsPasskeyCapability.ps1
      — read-only: reports the Windows build/feature-update, whether native passkey management (22H2) and privacy-consent controls (24H2) are available, and whether Hello is provisioned
    
      View all scripts on GitHub

Windows as a Passkey Provider: Where WHfB Ends and Passkeys Begin (24H2)