Microsoft has moved passkeys out of the browser and into the operating system: with the November 2025 Windows 11 security update the platform now supports third‑party passkey managers as native, system‑level providers, beginning with integrations from 1Password and Bitwarden and with Microsoft’s own Password Manager available as a built‑in plugin.
Background / Overview
Passkeys — the FIDO2/WebAuthn public/private key credentials designed to replace passwords — rely on asymmetric cryptography and a local authenticator. That architecture eliminates reusable secrets and makes credential phishing and server‑side credential theft much harder, because the private key never leaves the authenticator. Windows 11 already used Windows Hello as the local authenticator; the latest change makes the OS the orchestrator and adds a
plugin API so packaged credential managers can register themselves as
system passkey providers. In practice, this means a site or native app that initiates a WebAuthn flow can be routed by Windows to a registered vault (Microsoft Password Manager, 1Password, Bitwarden, etc., and the chosen provider handles discovery, creation, storage and optional cross‑device sync while
Windows Hello remains the local gatekeeper that authorizes signing operations. Microsoft marked this capability generally available with the November 2025 cumulative/security update (KB5068861).
What Microsoft shipped and why it matters
The platform pieces — at a glance
- A passkey provider plugin API in Windows 11 that lets packaged credential managers register as system passkey providers and receive WebAuthn requests forwarded by the OS.
- A redesigned Settings > Accounts > Passkeys area that shows registered providers and requires Windows Hello to enable them.
- Microsoft’s own Microsoft Password Manager (from Edge) integrated as a native plugin, offering synced passkeys protected by Windows Hello and hardware/cloud protections including Azure Managed HSM and Confidential Compute/Confidential Ledger.
Why this change matters: before this, passkeys were often fragmented — created in a browser or mobile app, then used on other devices via QR flows or mobile pairing. The
OS‑level plugin model unifies discovery and storage, lets password managers reuse their sync and recovery systems, and preserves platform security primitives (TPM, Windows Hello) while giving users genuine choice about where their passkeys live.
Who’s in at launch
- Microsoft Password Manager: Now packaged and surfaced as a Windows plugin so passkeys saved in Edge can be used by other browsers and native apps on Windows. Microsoft describes end‑to‑end encryption of passkeys and PIN‑protected access backed by Azure confidential services.
- 1Password: Announced native integration that uses an MSIX packaged desktop app which registers as the system passkey provider. Vendor messaging emphasizes the collaboration with Microsoft and the ability to manage passkeys natively on Windows. Vendor claims note that 1Password’s MSIX build is required for system registration.
- Bitwarden: Integrated via an early beta/preview desktop build at rollout time; Bitwarden’s desktop previews allow the app to register as a system provider for testing, with stable packaging planned afterward.
Multiple independent outlets and Microsoft’s developer/Edge blogs describe the same architecture and vendor collaborations, and Microsoft’s official servicing notes list the November cumulative update that carries these platform refinements.
How the integration works — technical breakdown
Responsibilities and flow
Microsoft intentionally splits responsibilities:
- Windows Hello: continues to be the local authenticator. It verifies the user (PIN, fingerprint, face) and authorizes the cryptographic sign operation. Biometric templates and local verification data do not leave the device.
- Passkey provider plugin: handles discovery, creation, storage and optional sync. The provider can use its existing vault infrastructure and recovery mechanisms to offer portability across devices.
When an app or website requests WebAuthn create/assertion, Windows can now route that request to the registered provider plugin. The plugin performs the requested operation and returns the assertion or credential to the client app. This preserves platform security guarantees (TPM backing, Windows Hello verification) while enabling vaults to provide cross‑device recovery and sync.
Packaging and registration: why MSIX matters
Microsoft’s API requires a packaged, registered app to act as a system provider.
1Password’s integration uses an MSIX build, and Microsoft’s documentation and vendor notes highlight that packaging and installer semantics (MSIX or other signed installer flows) are material to system registration. Enterprises that restrict app types or have controlled deployment pipelines will need to plan for MSIX distribution or vendor enterprise installers.
Security protections and cloud backstops
Microsoft’s native provider uses end‑to‑end encryption, TPM protections for device‑bound keys, and additional cloud protections (Azure Managed HSM, Azure Confidential Compute, and an
immutable Azure confidential ledger for critical recovery actions). These protections are presented as optional backstops for users who choose Microsoft’s sync instead of a third‑party vault. The vendor‑managed vaults (1Password, Bitwarden) will use their own encryption and sync stacks; Windows delegates the local unlock to Windows Hello, but storage and recovery remain with the provider.
How to enable and test a third‑party passkey provider (practical steps)
- Update Windows 11 to the November 2025 cumulative/security update (look for the KB5068861‑era build or later).
- Install the vendor desktop app that implements the Windows passkey plugin API:
- 1Password: install the MSIX packaged desktop build and enable passkey suggestions inside the app.
- Bitwarden: install the beta/preview desktop build from the vendor’s preview channel if testing, then enable the passkey integration.
- Open Settings > Accounts > Passkeys > Advanced options and authenticate with Windows Hello. The registered providers should appear; toggle the provider you want to enable.
- Visit a passkey‑enabled website or app and follow the WebAuthn prompts. When asked where to save the passkey, choose the registered provider and confirm with Windows Hello.
These steps represent the common user path, but enterprise rollouts should be tested in pilot groups and deployment packaging validated (MSIX, centralized installers, or signed enterprise MSI packages).
Immediate benefits for users and organizations
- Stronger phishing resistance: passkeys are domain‑bound and cannot be phished in the same way passwords can. The private key never leaves the authenticator.
- Choice and portability: users can choose their preferred vault (Microsoft, 1Password, Bitwarden) and reuse the same passkeys across apps and browsers on Windows.
- Better non‑browser support: native apps that use WebAuthn can now invoke system providers directly, removing awkward browser‑centric workarounds like QR pairing.
- Enterprise management paths: the platform retains MDM/Group Policy controls and Windows Hello for Business constructs to manage passwordless transitions at scale.
Risks, operational caveats, and what IT must plan for
No deployment is risk‑free. The architecture is promising, but there are operational and security caveats that organizations and cautious users must address.
1) Recovery and account continuity
Third‑party vaults bring
their own recovery models. If a user’s vault relies on multi‑device sync, recovery codes, or a vendor account tied to the cloud, losing access to that vendor account could impact passkey recovery. Enterprises must map recovery flows into their helpdesk procedures and ensure fallback sign‑in paths are available for critical services. Microsoft’s own synced provider offers an optional cloud‑backed recovery mechanism, but vendor differences mean careful evaluation is needed.
2) Packaging, deployment and policy friction
Because
MSIX packaging is part of the reliable registration path for system providers, organizations that restrict Store/MSIX app installation must adapt their deployment controls or use trusted enterprise packaging channels. Administrators should validate how the vendor’s installer registers with the OS and whether policies need exceptions.
3) Compatibility and early‑rollout bugs
Early adopter reporting shows mixed experiences — some users report smooth operation, others report browser/extension edge cases and issues when vendors ship preview builds. Bitwarden’s desktop path landed initially as a preview, and community threads describe intermittent glitches when using passkeys through third‑party extensions or beta clients. Treat early builds as previews: pilot before a broad enterprise roll‑out.
4) Vendor claims vs. verifiable facts
Vendors naturally promote their role in the integration — for example, 1Password has described itself as an early integrator and has provided product guidance (MSIX required, onboarding steps). Those vendor claims should be treated as
vendor assertions until independently validated in your environment. Where a vendor states it is “first” or “the only” integrator, confirm that claim against independent records and competing vendors’ announcements.
5) Regulatory and compliance considerations
Passkeys that are synced in the cloud may involve cross‑region storage or vendor‑hosted recovery backstops. Organizations with strict data locality or compliance obligations must review vendor architectures (where keys, backup metadata, and audit logs are stored) before enabling cross‑device sync. Microsoft’s Edge blog explicitly describes Azure confidential services for its managed path; third‑party vendors will use their own cloud providers and encryption models. Evaluate encryption-at-rest, key material custody, and auditability.
Vendor implementations: what to expect from 1Password and Bitwarden
1Password
- Delivered integration packaged as an MSIX desktop build that registers as a system provider and surfaces passkey suggestions inside the app.
- Emphasizes passkey adoption metrics and prior work on passkey portability, and publicly states close collaboration with Microsoft on the plugin API. Note: some of 1Password’s messaging frames their integration as an early win; that is a vendor claim and should be validated in your environment.
Bitwarden
- Released system provider support in beta/preview desktop builds and GitHub previews for power users at rollout time. Stable packaging for enterprise distribution is expected to follow.
- Community threads indicate some users have encountered rough edges during early testing; this is typical for preview channels and underscores the need for piloting.
Both vendors bring proven vault and sync systems to the table; the Windows plugin model simply gives those vaults an OS‑level seat at the passkey flow so they can manage discovery, storage and sync while Windows Hello performs local verification.
Cross‑checking the facts (sources and verification)
Key load‑bearing facts were verified across Microsoft’s official developer and Edge blogs, Microsoft support KB release notes, vendor posts from 1Password and reporting by independent press:
- Microsoft’s Windows Developer blog announced the third‑party passkey provider API and the redesigned Windows Hello UX months earlier during developer previews.
- Microsoft Edge’s blog documented passkey saving and syncing in Edge and explained Azure confidential protections for Microsoft’s synced provider.
- The November cumulative update (KB5068861, published November 11, 2025) is Microsoft’s servicing vehicle that includes the broader platform updates; KB documentation confirms the November 2025 servicing wave.
- Vendor messaging and product blogs (1Password) and independent reporting (Windows Central, gHacks and other outlets) corroborate the vendor integrations and the MSIX/beta packaging details.
Where public statements are phrased as vendor claims (for example, “the first password manager to offer native passkey support in Windows 11”), treat those as marketing language; the
technical facts about the plugin API, the Settings UI changes, Windows Hello’s role, and the availability in the November 2025 servicing cadence are verifiable across Microsoft’s own documentation and independent reporting.
Practical advice for readers and IT teams
- End users: update Windows (apply the November cumulative/security update), install the vendor app (MSIX for 1Password or the vendor’s recommended build), go to Settings > Accounts > Passkeys > Advanced, authenticate with Windows Hello, and enable your preferred provider. Test passkey creation and sign‑in flows with a few low‑risk accounts first.
- IT administrators:
- Pilot with a controlled group to validate critical internal and public web apps.
- Confirm packaging strategy (MSIX or signed enterprise installers) and adjust deployment tooling and AppLocker/Intune policies accordingly.
- Update helpdesk processes and self‑service recovery guidance to include vendor‑specific recovery steps and fallback sign‑in options.
- Review compliance and data residency implications of any vendor’s cloud sync model.
- Security teams:
- Require vendors to document how private key material, metadata, and recovery credentials are stored and how attestation is handled.
- Monitor vendor advisories and early community reports for edge‑case failures or integration issues.
The outlook: faster passwordless adoption — but keep expectations realistic
This OS‑level plugin model is a decisive step: by allowing passkey managers to register as system providers, Microsoft has removed a major UX barrier that previously forced many flows to rely on mobile pairing and QR codes. Early vendor integrations (1Password’s MSIX path, Bitwarden’s preview builds, and Microsoft’s own plugin) prove the model works in the wild and should materially accelerate passkey adoption on Windows. However, mainstream adoption depends on several non‑technical and technical pieces aligning: broad browser behavior consistency across Chromium and other engines, robust and well‑documented vendor recovery models, enterprise packaging and distribution policies, and iterative hardening as vendors move from preview to stable builds. Expect an iterative rollout — the functionality exists today, but maturation and ecosystem polishing will continue over quarters, not days.
Conclusion
Windows 11’s native support for third‑party passkey managers represents a practical, standards‑based step toward an operating system that orchestrates passwordless sign‑ins instead of leaving them to individual browsers or siloed vendor apps. The November 2025 servicing wave formalized the platform plumbing — a plugin API, a Settings UI, and Microsoft’s own native Password Manager plugin — while vendors such as 1Password and Bitwarden have already implemented system‑provider integrations (MSIX or preview builds) to make passkeys manageable and portable on Windows.
The benefits are immediate: better phishing resistance, more convenient multi‑device use, and an end to many cross‑device pairing workarounds. The operational risks are manageable but real: packaging and deployment, recovery plans, and early‑build compatibility remain the primary friction points. Organizations and users should pilot carefully, validate their highest‑value apps, and insist on clear vendor documentation for recovery, encryption and auditability.
If you care about moving away from reusable passwords and toward a more secure, passwordless future, the pieces are now in place on Windows 11 — but turning potential into secure, enterprise‑grade reality requires planning, testing, and sensible rollout policies.
Source: Windows Report
Windows 11 Now Natively Supports Third-Party Passkey Managers Like 1Password & Bitwarden