Windows 11’s passkey story just moved from promising to practical: Microsoft has shipped an OS-level plugin API that lets third‑party password managers register as
system passkey providers, and the November 11, 2025 cumulative/security update made the feature broadly available to many Windows 11 users. This change lets vaults such as 1Password and Bitwarden act as the default passkey manager for the device — surfacing in Settings, integrating with WebAuthn flows, and relying on Windows Hello (PIN/biometrics) to gate cryptographic operations — effectively bringing passwordless sign‑in out of browser silos and into the operating system itself.
Background
Passkeys are the modern, FIDO2/WebAuthn‑based replacement for passwords: asymmetric public/private key credentials where the private key remains under user control and signing requires a local authenticator like Windows Hello. They remove reusable secrets from servers, drastically reduce phishing risk, and enable an authentication UX based on biometrics or short PINs instead of memorized passwords. Microsoft has been accelerating toward a passwordless platform — adding passkey support and pushing passkeys as the default for new Microsoft Accounts — and the new plugin model completes a critical missing piece: giving users and enterprises choice over where passkeys are stored and synced.
Why this matters now
Until this update, desktop passkey workflows tended to be browser‑centric (passkeys stored in Edge, Chrome, Safari) or required cross‑device pairing (QR scanning from phone to PC). That fragmentation created friction: passkeys worked, but the UX for creating, storing and using them across apps and non‑browser clients was uneven. By exposing a
Passkey Provider Plugin API and a user‑facing Settings surface, Microsoft makes passkeys a consistent, OS‑level authentication surface that native apps, PWAs, and browsers can use uniformly. That consistency is what will drive practical, mainstream passwordless adoption.
What Microsoft shipped (overview)
- A formal Passkey Provider Plugin API that lets packaged credential manager apps register with Windows and receive WebAuthn create/assertion requests routed by the OS.
- A redesigned Settings > Accounts > Passkeys area with an Advanced options panel that lists registered providers; enabling a provider requires re‑authentication with Windows Hello to prevent silent activation.
- Microsoft’s own Microsoft Password Manager surfaced as a native provider (not only Edge‑bound), offering a built‑in option for users who prefer first‑party sync backed by Azure protections.
- Vendor integrations from the first wave of third‑party password managers — notably 1Password (via an MSIX packaged build) and Bitwarden (initially via preview/beta desktop builds) — that implement the plugin path so their vaults can present passkeys at the OS level.
These pieces together convert passkeys from a per‑browser convenience into a platform capability: when a website or native app asks for a passkey, Windows can forward the request to the registered provider and then use Windows Hello to authorize the private key operation locally.
The technical architecture (concise)
Role separation — key design principle
Microsoft intentionally splits responsibilities:
- Windows Hello / OS platform: Responsible for local user verification (PIN, fingerprint, face) and performing the cryptographic gating (sign operations). Biometric templates and local authentication data remain on the device and are not shared.
- Passkey provider (third‑party or Microsoft): Responsible for discovery, storage, and optional cloud sync/recovery of passkeys. The provider can reuse its existing vault sync and recovery mechanisms, bringing passkeys into the same trusted envelope as passwords and other secrets.
How a typical WebAuthn flow changes on Windows 11
- An app or website triggers a WebAuthn create/assertion request.
- Windows checks registered passkey providers and offers the user a choice (the OS can route the request to the chosen plugin).
- The selected passkey provider performs discovery or creation and returns the cryptographic response to Windows.
- Windows Hello is invoked to confirm the user (PIN/biometric) and authorize the signing operation locally.
- The signed assertion is returned to the requesting site or app for verification.
By routing WebAuthn calls through the OS, native apps and non‑browser clients gain the same passkey UX previously available mainly to browsers.
Who’s in at launch: 1Password, Bitwarden, Microsoft
- 1Password shipped a Windows build that supports the plugin path, but system registration is tied to MSIX packaging; the MSIX build registers reliably as a system provider and exposes settings (for example, “Show passkey suggestions”) in the 1Password client once enabled. Early adopters should install the MSIX version and follow vendor onboarding steps.
- Bitwarden published early preview/beta desktop builds that implement the same system provider interface for testing; stable distribution (MSIX or equivalent enterprise packaging) is expected to follow. Bitwarden’s guidance shows the feature requires recent Windows OS builds and the Passkeys > Advanced options toggle.
- Microsoft Password Manager (the passkey store previously bound to Edge) is now available as a native OS plugin, enabling first‑party passkey sync protected by end‑to‑end encryption and cloud HSM/confidential compute options for recovery/backups. This gives users a built‑in option without forcing third‑party adoption.
Multiple independent outlets and community reports corroborate these vendor details and early rollout behaviors.
How to enable and use a third‑party passkey provider (practical steps)
- Update Windows 11 to the latest cumulative/security patch that includes the November 11, 2025 release (KB5068861) and reboot if required. Microsoft’s support documentation lists the KB and release builds.
- Install the vendor’s Windows client that supports the system provider API (for 1Password, install the MSIX packaged build; for Bitwarden, install the preview/beta build if you want early access).
- Open Settings > Accounts > Passkeys, then open Advanced options. You should see registered providers listed; toggle the provider you want to enable. A Windows Hello confirmation will be required to complete activation.
- After enabling, test with a couple of websites that support passkeys: create a new passkey and confirm the provider presents itself as the save target; then sign out and sign in again to validate the flow.
Tip: If you don’t see the Advanced options panel immediately after updating, ensure the Windows build is at the published release level and give Windows Update a complete cycle (install + reboot). Some early adopters reported short delays in UI availability during rollout.
Strengths: What this change buys users and organizations
- Better usability and discoverability: Passkey creation and selection become consistent across apps and browsers, removing the confusing “which device/vault” question for many users. This change reduces friction for onboarding passkeys.
- Choice and vendor continuity: Users can keep using the vault they already trust (and pay for) — bringing passkeys under the same sync and recovery umbrella as other saved credentials. Enterprises can select and validate a provider that fits their policies.
- Preserved platform security guarantees: Windows Hello and TPM protections remain the local gatekeeper for unlocking key operations; biometric data stays local to the device. The architecture retains platform security primitives while enabling vendor flexibility.
- Practical cross‑device workflows: Third‑party vaults can reuse their existing sync model to make passkeys portable across devices without relying on QR pairing or mobile relays, improving cross‑device sign‑in ergonomics.
Risks, limitations and operational caveats
- Reliance on vendor recovery and sync models: Centralizing passkeys in a single third‑party vault simplifies UX but increases dependence on that vendor’s account recovery, key escrow (if any), and anti‑abuse controls. Poorly designed recovery flows can create new account‑takeover paths; conversely, overly strict recovery can lead to account loss. Organizations must validate vendor recovery mechanisms before broad adoption.
- Packaging & deployment constraints (MSIX matters): System registration for providers is tied to app packaging semantics. For instance, 1Password’s system registration path relies on MSIX packaging; enterprise environments that restrict MSIX or control app deployment through specific channels will need to plan distribution and Group Policy/MDM exceptions.
- Compatibility and rollout wrinkles: Early rollouts showed UI toggles that could be greyed out, short delays in the Settings UI appearing, and vendor beta teething issues. Expect similar behavior during phased rollouts — test widely before wide deployment.
- Windows update side effects: Major cumulative updates like KB5068861 bring many changes; some admins have reported unrelated regression issues after installing the November 2025 update (installation errors, app regressions, or behavioral changes). Rollouts should be tested in controlled pilots.
- Browser vendor behavior: For seamless UX, browsers must respect the OS‑level provider and surface it reliably; while the plugin model centralizes discovery, disparate browser implementations can still create inconsistent experiences until vendors harmonize behavior.
Enterprise checklist — how IT should approach deployment
- Pilot with a small, representative user group to validate vendor packaging (MSIX support), browser compatibility, and helpdesk workflows.
- Validate passkey recovery — test vendor recovery flows, account transfer, and emergency access procedures (legal/HR-approved).
- Update MDM/Group Policy to allow MSIX distribution where required and to control which providers can be registered in managed devices.
- Prepare helpdesk playbooks for device loss, lost vault access, and cross‑vendor migration scenarios (keeping at least one emergency account with password+2FA as fallback during transition).
- Monitor Windows Update rollout issues — coordinate patching windows and rollback plans in case of systemic problems after large cumulative updates.
Recovery and portability — practical concerns
Passkeys are device‑centric cryptographic keys. The practical value of the new plugin model is that it lets password managers bring passkey keys into their existing, familiar sync and recovery ecosystems — but that also means passkey portability and recovery are now gated by each vendor’s design choices.
- Strong password managers offer robust, audited account recovery flows (multi‑device linking, emergency kits, account recovery keys). Those same mechanisms must be validated for passkeys because losing vault access can mean losing passkey access.
- Organizations should insist on documented, auditable recovery SLAs and controls before switching critical accounts to a single vault provider.
- Until the ecosystem matures, maintain fallback sign‑in controls for critical services during migration windows.
What to watch next
- More vendors: Expect additional password managers to implement the Passkey Provider Plugin API over the coming months. Broad vendor participation will make the OS surface more valuable and reduce vendor lock‑in risk.
- Browser harmonization: Chrome, Firefox, Edge and others must converge on UX details for presenting OS providers. Cross‑browser consistency will be key to a frictionless user experience.
- Standards & features: Improvements in WebAuthn/FIDO specifications and vendor guidance will refine how providers handle discovery, cross‑device delegation, and enterprise policy. Microsoft’s developer docs and samples (such as the Contoso Passkey Manager demo) will continue to evolve.
Final analysis — realistic expectations
This OS‑level passkey provider model is the missing infrastructure piece that passkeys needed on Windows: it brings choice, better UX, and real cross‑app capabilities to passwordless sign‑in. For consumers, it simplifies the path to ditching passwords while letting people keep their chosen vault. For enterprises, it opens a path to centralized, managed passkey deployment — provided IT teams treat the rollout like a project: validate vendors, plan packaging, and harden recovery processes.
The move substantially lowers the bar to mainstream passwordless adoption on Windows. However, it is not a flip‑the‑switch moment; it is a staged migration. The
security benefits are immediate and real — phishing resistance, removal of server‑side reusable secrets, and tighter multi‑factor gating via Windows Hello — but the
operational work (packaging, policy, recovery) is where organizations must invest to avoid creating new availability or recovery risks.
Practical recommendations (for advanced users and IT)
- Update Windows 11 to the November 11, 2025 cumulative release (KB5068861) on test machines and validate the Settings > Accounts > Passkeys UI before rolling out.
- If you rely on a third‑party vault, prefer vendor builds that explicitly list Windows passkey provider support and MSIX packaging for stable registration.
- Pilot with low‑risk accounts first and keep emergency fallback access methods during migration. Document and practice vault recovery steps before decommissioning legacy password recovery options.
- For enterprises: include passkey testing in application compatibility matrices, update helpdesk runbooks, and plan a phased rollout accompanied by user education materials explaining passkeys and recovery behaviors.
Windows 11’s plugin passkey provider integration is a decisive step toward an operating system that natively supports passwordless authentication with real user choice. The November 2025 update moves passkeys out of browser silos, gives trusted vaults a native voice in OS WebAuthn flows, and keeps Windows Hello as the secure local gatekeeper — a combination that can finally make passwordless sign‑in usable at scale, if vendors and IT teams handle packaging, recovery, and rollout responsibly.
Source: Pocket-lint
Windows 11 is about to work way better with passkeys