We're rolling out passkeys because of Microsoft's push to reduce reliance on SMS and voice authentication. Some employees use LastPass or Bitwarden browser extensions, while others use Google Password Manager or the password manager built into Edge. The recurring problem is that users save a passkey in their browser's password manager instead of Windows Hello. The passkey then works in the browser but is unavailable when they sign in through native applications such as Outlook or Teams, which use Windows' WebAuthn and security prompts.
Windows Hello works technically, but several users get confused during enrollment. Others have basic phones and won't carry a physical security key, leaving us with browser-based password managers or Windows Hello as the practical choices. What is the recommended way to configure this so users can reliably use passkeys across both browsers and Windows applications?
5 Answers
Bitwarden and LastPass provide options during passkey enrollment to use the operating system’s authenticator instead of saving the credential as a synced passkey. Train users to select that option when the organization wants device-bound Windows Hello credentials. Be careful about enabling synced passkeys broadly, since they may not meet the organization’s security requirements for enterprise authentication.
Native Windows applications generally call the Windows WebAuthn and Windows Hello platform APIs directly. They don’t automatically use a passkey that was registered only inside a browser extension. Check whether your password manager supports an operating-system-level FIDO2 provider; Bitwarden has been adding this capability in newer or preview releases. Otherwise, standardize on Windows Hello for managed Windows devices and treat browser-only passkeys as a separate workflow.
There are two separate issues here: the technical limitation and the user or policy decision. Users cannot use a browser-only passkey from a native Windows app unless the password manager provides OS-level integration. For employees who cannot use a phone, a physical security key may need to be an explicit company requirement. If they refuse both a compatible phone and a security key, management may need to decide whether they need individual accounts or whether a guest or alternative access model is appropriate.
Agreed—training can address confusion during Windows Hello enrollment, but refusing every supported authentication method is a policy and HR matter rather than something IT can work around indefinitely.
I’d simplify the rollout instead of supporting several passkey locations. For company-managed Windows computers, enroll users in Windows Hello for Business and document one consistent enrollment process. Only support third-party password-manager passkeys where the product officially integrates with the operating system and the security team has approved synced credentials. A single documented workflow will be much easier for users and the help desk.
For assigned Windows devices, the cleanest approach is usually to configure and enroll Windows Hello for Business, then make that the standard sign-in method through policy. Letting every employee choose among Edge, Google Password Manager, browser extensions, and Windows Hello creates a confusing support model. If users repeatedly receive MFA prompts in Outlook and Teams, also review endpoint configuration and Conditional Access, because properly managed devices generally shouldn’t prompt constantly.
This is why simply installing a browser extension usually doesn’t solve the Outlook or Teams case. The password manager has to integrate with Windows itself, not just the browser.