Windows 11 Passkeys: OS Level Support with 1Password Bitwarden and Microsoft Plugin

Windows 11 has taken a decisive step toward making passkeys a first‑class, system‑level authentication option by adding a plugin model that lets third‑party credential managers — initially 1Password and Bitwarden — register as OS passkey providers, and by surfacing the Microsoft Password Manager as a native Windows plugin in the November 2025 cumulative security update (the Patch Tuesday servicing wave that delivered updated 24H2/25H2 builds).

Background / overview​

Passkeys replace passwords with public‑key credentials created and stored per‑site using the FIDO2/WebAuthn standards. The private key remains under user control and signing the cryptographic challenge is gated by a local authenticator — on Windows that gate is Windows Hello (PIN, fingerprint or face). Because the private key is never sent to the server, passkeys are inherently resistant to phishing and server‑side credential theft, and they remove the repeated‑password problem that powers credential stuffing attacks.
Until now, passkey storage and sync on desktop systems were largely handled inside browsers or vendor ecosystems (mobile apps, browser vaults, or proprietary pairing workflows). The change delivered in the November 2025 cumulative update moves that storage and discovery decision point into Windows itself by offering a plugin API. Packaged credential managers can now register as system passkey providers, appear in Settings > Accounts > Passkeys, and be selected as the target for creating, storing, and asserting passkeys across browsers and native apps.
This is not a mere UI tweak. It repositions passkeys from a browser‑centred convenience into a platform capability that apps, PWAs, and native clients can consistently leverage — with Windows Hello continuing to provide the local user verification step and platform protections such as the Trusted Platform Module (TPM) reinforcing key material protection on device.

---

What Microsoft shipped and what it means​

The platform pieces (high level)​

• Passkey provider plugin API: Packaged credential managers (those that can register with the OS) can now register themselves as system passkey providers and respond to WebAuthn create/assertion calls routed by Windows.
• Settings UI: A new Passkeys page under Settings > Accounts exposes an Advanced options pane that lists registered providers. Enabling a provider requires Windows Hello re‑authentication to prevent silent registrations.
• Windows Hello as gatekeeper: Windows continues to handle local user verification (PIN/biometrics). Providers are responsible for storage and optional cloud sync/recovery.
• Microsoft Password Manager as native plugin: Microsoft’s own synced passkey provider is now packaged as a native Windows plugin (no longer Edge‑bound), offering a cloud sync option that Microsoft says is protected by hardware‑backed and confidential cloud controls.
• Vendor integrations at launch: 1Password delivered a packaged desktop build that registers with Windows as a system provider; Bitwarden shipped desktop beta/preview builds enabling system registration for early adopters. Additional providers are expected to join over time.

Why this matters​

• Consistency across apps and browsers: Non‑browser apps that previously lacked good passkey flows can now call into the same OS surface that browsers use, reducing ad‑hoc QR pairing or mobile‑relay workarounds.
• User choice: Users can pick where their passkeys live — a Microsoft‑managed synced vault or a third‑party credential manager that already holds their passwords and vault data.
• Lower friction for cross‑device use: If a vendor’s sync is already cross‑device (phone + desktop), a passkey created on mobile can be used on the PC without QR scanning or manual recovery workarounds.
• Enterprise control: IT can manage deployment, packaging, and policy across fleets; this is particularly relevant for organizations that distribute MSIX apps via management tooling.

---

How third‑party support works in practice​

Packaging and registration​

• Only registered packaged apps can appear as system passkey providers. Practically, that means vendors must ship an MSIX (or comparable packaged) build capable of registering with the OS plugin registry; legacy EXE/MSI installers may not register automatically.
• After installing a supported vendor build, the user typically enables a passkey suggestion / passkey management toggle inside the vendor app. That action will direct the user to Settings > Accounts > Passkeys > Advanced options to complete registration, which requires Windows Hello verification.

Typical user flow (creating and using a passkey)​

• Install the November 2025 cumulative update so Settings > Accounts > Passkeys shows Advanced options.
• Install the vendor’s Windows desktop build that supports system registration (MSIX for some vendors).
• Enable passkey suggestions in the vendor app (varies by product).
• Open Settings > Accounts > Passkeys > Advanced options and authenticate with Windows Hello; enable the vendor as a provider.
• Visit a passkey‑enabled website or app, choose the registered provider when prompted, and confirm the operation with Windows Hello. The passkey is stored in the chosen provider and becomes available for future sign‑ins.

Important packaging caveat​

• The MSIX requirement is material. Organizations that block store/MSIX installs will need to plan distribution (intune/MSIX enterprise distribution, code‑signed packages) or coordinate with vendors for a suitable enterprise channel.

---

Verified technical specifics and claims (what’s confirmed)​

• Windows now exposes a plugin model that lets third‑party passkey managers register with the OS and participate in WebAuthn flows routed by Windows.
• The Passkeys page is available under Settings > Accounts > Passkeys, with an Advanced options area listing registered providers and forcing Windows Hello re‑auth to enable a provider.
• 1Password has shipped a Windows build that can register as a system provider when the packaged installer is used.
• Bitwarden provided desktop beta/preview builds enabling the system integration for early testers.
• The capability became broadly available during the November 2025 cumulative update cycle, and devices that receive that servicing wave should see the new Settings controls after installing the update and rebooting.
• Windows Hello and platform hardware protections (TPM / secure enclave) remain the local unlock mechanism for signing operations; passkey storage and sync responsibilities are delegated to the chosen provider.
• Microsoft’s synced passkey option is now packaged at the OS level and Microsoft describes several cloud protections for its sync/backups (a PIN unlock combined with hardware‑backed and confidential cloud services for sensitive operations).

Note: vendor promotional claims (for example, “the first password manager to offer native Windows passkey support”) should be treated as marketing and may depend on precise product versions and distribution channels; those are not security‑critical technical claims and are marked as vendor messaging.

---

Security analysis — what’s improved, and what to scrutinize​

Immediate security benefits​

• Phishing resistance: Passkeys are domain‑bound and cannot be phished in the classic sense because there’s no shared secret to exfiltrate.
• Breach resistance: Servers store only public keys, not reusable secrets; server breaches no longer yield credentials that can be replayed.
• Hardware protections: When Windows leverages TPM and platform attestation, the private keys benefit from hardware protection, reducing the risk of key extraction from the device.
• Reduced reliance on mobile pairing workarounds: The OS routing eliminates some fragile QR/phone relay flows, making the user path simpler and less error‑prone.

New attack surface and risks to watch​

• Packaging and distribution risks: Because integration depends on a packaged desktop build (MSIX), attackers could attempt to spoof installers or social‑engineer users into installing malicious “passkey manager” apps. Enterprises must verify app signatures and distribution channels.
• Recovery and lockout: Passkeys are device‑linked by design. Effective recovery mechanisms are crucial. If a user loses both device and vault access and recovery isn’t robust, the user risks account lockout. Vendors and IT must ensure secure and user‑friendly recovery options.
• Cloud trust and auditability: Choosing a cloud‑synced passkey provider involves trusting that provider’s encryption, key‑management, and recovery primitives. Microsoft’s synced provider uses hardware‑backed and confidential cloud services as additional protections, but that model centralizes trust in Microsoft’s infrastructure; organizations with strict compliance rules should evaluate the architecture carefully.
• Interoperability hiccups: Early rollouts have revealed site‑specific incompatibilities where a passkey stored with one provider isn’t surfaced by a specific browser/provider combination. The ecosystem is maturing; expect intermittent gaps that require testing for critical corporate services.
• Policy and manageability friction: Enterprises that forbid MSIX or Store installs will need an alternate distribution strategy; otherwise, deployment will be inconsistent. Group Policy, Intune, and AppLocker rules will determine how smoothly an org can adopt this model.
• Supply‑chain and update trust: Tight OS integration raises supply‑chain concerns. Vet vendor update channels and watch for signed publisher changes.

---

Practical guidance — what users and IT should do now​

For individual users (straightforward checklist)​

• Update Windows 11 to the latest cumulative release (install the November 2025 security update and reboot).
• Set up Windows Hello (PIN and at least one biometric factor where available) and enable TPM/Secure Boot if your device supports them.
• Choose a passkey storage model:
• If you trust your password manager vendor and use its sync across devices, install the vendor’s supported Windows build (MSIX when required) and enable passkey integration in the app.
• If you prefer Microsoft’s integrated experience, use the Microsoft Password Manager plugin and a Microsoft account with the PIN unlock option enabled.
• Retain at least one recovery fallback (recovery codes, linked devices) for critical accounts while you test passkey recovery flows.
• Test passkey sign‑in and recovery on a non‑critical account first to learn the flow before migrating important services.

For IT and enterprise teams​

• Pilot: Run a pilot with a representative group and validate the entire lifecycle — creation, sign‑in, cross‑device use, and recovery — for all critical services.
• Packaging policy: Decide which packaging model you’ll allow (MSIX/Store vs. enterprise installers) and confirm vendors can provide suitable enterprise channels.
• Distribution: Use Intune, WSUS, or your existing software distribution mechanism to ensure signed, approved vendor packages are deployed.
• Policy controls: Evaluate Group Policy / MDM settings that may block provider registration or MSIX installs; document the changes and update SOPs.
• Recovery and support: Train helpdesk staff on passkey recovery procedures and account recovery escalation paths; ensure helpdesk has a documented, secure process to assist locked‑out users.
• Test critical web apps: Verify that the organization’s web apps and business‑critical services interoperate with Windows’ system provider model and vendor clients.
• Compliance review: For regulated environments, map vendor sync and cloud protections against your compliance controls and audit requirements.

---

Troubleshooting and common issues (practical tips)​

• If the Passkeys > Advanced options panel is missing:
• Recheck Windows Update; ensure the November 2025 cumulative update is installed and reboot.
• Confirm you installed a vendor build packaged the way the OS requires (MSIX if specified).
• Wait up to 24–48 hours in some staged rollouts; server‑side flags sometimes propagate after binaries are installed.
• If a site won’t surface a provider’s passkey:
• Try a different browser (Chromium vs. Firefox) and confirm the browser and vendor extension (if present) are up to date.
• Recreate the passkey: some vendors reported better success creating a new passkey instead of attaching it to an existing login entry.
• If passkey creation fails with “device cannot be registered” or similar:
• Make sure Windows Hello is set up and that TPM/secure platform protections are enabled.
• Try creating a new vault entry for the passkey rather than attaching to an existing entry, then migrate metadata as needed.
• If you lose access to your vault and device:
• Use vendor‑documented recovery methods (recovery codes, device links). If you used Microsoft’s synced provider, follow the Microsoft account recovery flow; for third‑party vaults, follow vendor recovery guidance.

---

Vendor considerations and migration notes​

• Vendors will compete on usability: onboarding, cross‑platform parity, and recovery UX will be differentiators.
• The modular OS approach encourages vendor diversity, which helps reduce lock‑in risk as long as passkey interchange standards and tooling continue to improve.
• Exporting and importing passkeys between providers remains an evolving area. Organizations planning a migration at scale should test export/import flows early and validate that critical relying parties accept migrated keys.
• For privacy‑minded organizations, self‑hostable or open‑source providers offer options, but ensure those deployments meet the same hardware and backup protections you expect from hosted services.

---

Final assessment — strengths, tradeoffs, and where this heads next​

Microsoft’s addition of a passkey provider plugin model and the arrival of first‑wave vendor integrations is a pivotal move in the passwordless transition: it reduces friction, brings choice to users, and converts passkeys into a practical, cross‑app authentication surface on Windows.
Strengths:

• Stronger security guarantees through FIDO/WebAuthn and hardware gating.
• Better UX for cross‑device and non‑browser scenarios.
• Choice and competition across vendors, improving the ecosystem.

Tradeoffs and open questions:

• Deployment friction around packaging (MSIX) and staged rollouts complicates enterprise adoption.
• Recovery complexity remains the most consequential operational concern; account recovery flows will determine broad user acceptance.
• Trust centralization for users who pick Microsoft’s synced provider needs to be weighed against the benefits of software convenience and hardware‑backed cloud protections.
• Interoperability across browsers, sites, and vendor implementations will improve but will require continued testing for mission‑critical services.

Where this heads next:

• Expect more password manager vendors to add system provider support, and for packaging/distribution pathways to broaden.
• Standards and tooling for passkey portability and export/import will improve, reducing migration friction.
• Enterprises will develop policy patterns for MSIX distribution and will integrate passkeys into identity strategies (including conditional access, passwordless Entra/AD integration, and device posture checks).

The practical takeaway: passkeys are no longer an experimental convenience — they’re now an OS‑level capability on Windows. Users and IT teams should plan gradual adoption: update Windows, pilot vendor integrations for critical apps, and verify recovery and interoperability before deprecating passwords wholesale. When implemented carefully, this platform shift delivers a meaningful improvement in both security posture and day‑to‑day usability — but it also requires deliberate operational and policy work to avoid the very lockouts and deployment headaches it aims to eliminate.

---

Source: TechSpot Windows 11 now works with 1Password and Bitwarden passkeys, with more to come