Windows 11 Passkeys Move to OS Level: A Practical Guide to the New Provider Model

Paul Thurrott’s candid Editor’s Desk column is as much about a writer’s struggle with ADHD as it is about a small, messy revolution in Windows 11 authentication — a practical, cross‑vendor push toward passkeys that has forced authors, admins, and everyday users to rethink how they explain, teach, and adopt passwordless sign‑in.

Overview​

Windows 11 is no longer treating passkeys as a browser-only convenience. With the November 11, 2025 cumulative update (KB5068861) Microsoft shipped an OS-level passkey provider model that lets packaged credential managers register as system passkey providers. That change moved passkeys from fragmented browser silos into a platform surface that apps, PWAs and browsers can call — while keeping Windows Hello (PIN, fingerprint, face) as the local user-verification gate.
At the same time, major vault vendors began shipping support for the new API: 1Password released documentation and builds to register as a Windows passkey provider, and Bitwarden has preview/beta support available for early adopters. Microsoft has also surfaced its own Microsoft Password Manager as an optional native provider, giving users a built‑in sync path. These vendor moves materially change how passkeys are created, stored, and used on Windows.
This feature is powerful — and it is complicated. Paul Thurrott’s piece describes the exact friction many technical writers and users feel: the ecosystem is evolving during a fast cadence of updates, the UX paths multiply (device‑bound, mobile pairing/QR, browser extension, system provider), and authors have to balance brevity with completeness when teaching readers how to be safe and practical with passkeys.

---

Background: what changed and why it matters​

The technical shift in plain language​

• Historically: passkey creation and discovery on desktops were largely handled by browsers (Edge, Chrome, Firefox) or by mobile pairing flows (scan a QR code and use your phone).
• Now: Windows 11 exposes a Passkey Provider Plugin API and a Passkeys management surface (Settings > Accounts > Passkeys > Advanced) so packaged vaults can register as the system passkey provider. When a website or app invokes WebAuthn create/assertion, Windows can forward the request to the registered provider, and Windows Hello performs the final unlock/sign step.

Who’s in the early wave​

• 1Password: published support pages and released an MSIX-packaged client that can register as a Windows passkey provider. That packaging is important for reliable system registration.
• Bitwarden: shipping desktop preview builds with similar integration in beta channels.
• Microsoft Password Manager: surfaced as the built-in provider option for users who prefer Microsoft’s sync and cloud protections.

Why this matters to users and IT​

• Usability: Passkeys are phishing‑resistant and far easier for users (biometric tap or PIN) than passwords plus OTPs.
• Portability: Third‑party vaults provide cross‑device sync (phone, other PCs, Mac), solving the QR/pairing friction that slowed passkey adoption.
• Enterprise implications: IT needs to validate packaging (MSIX), distribution channels, browser behavior, and recovery paths before a broad rollout.

---

Summary of Thurrott’s main points​

• The Windows 11 Field Guide has ballooned in length over time and Paul wants the 25H2 edition to be shorter and more how‑to oriented. He set out to rewrite a chapter on passkeys but hit the perennial problem of scope creep — the passkey topic branched into multiple UX models, each requiring explanation.
• He distinguishes between device‑bound passkeys (private key stuck to a single PC) and passkeys saved in a third‑party manager (portable across devices). He is skeptical of device‑bound passkeys as a primary strategy for most users because portability is essential.
• He is also skeptical of built‑in, browser/OS password managers for primary use and prefers third‑party password managers, yet acknowledges Microsoft has a first‑party option (Microsoft Password Manager) that complicates his terminology and guidance.
• The practical reality he discovered: most users will use multiple passkey methods (phone + browser extension + device provider) depending on the flow the website triggers (QR vs. system provider dialog), which demands a different, non‑repetitive organization for documentation.

---

What the platform promises — and the real technical details to verify​

The most load‑bearing claims about platform behavior and the rollout deserve verification from primary sources:

• The November 11, 2025 cumulative update (KB5068861) is the servicing package that included these passkey plumbing changes for Windows 11 versions 24H2 and 25H2. The Microsoft release note confirms the date and lists the cumulative update details and build numbers. This is the baseline OS patch that most users require to see the Passkeys > Advanced UI.
• 1Password’s official support documentation explains how to save and use passkeys on Windows and warns about packaging differences — notably that the MSIX packaged version is required for the system‑provider integration to appear correctly. That is vendor‑confirmed behavior and should be treated as guidance when deploying.
• Independent coverage (Windows Central, TechRadar and other outlets) corroborates that Windows is moving passkeys into the OS and that major vaults like 1Password and Bitwarden are early partners in the system provider model. These outlets also report the practical caveats: packaging requirements, browser fragmentation, and recovery concerns.

If a claim cannot be directly verified in vendor docs or the Microsoft KB — such as subtle edge behavior for Entra/Azure AD managed tenants or exact behavior for Work/School accounts on Home vs. Pro SKUs — treat that claim as provisional and test in a controlled environment before relying on it in documentation or policy. Thurrott’s own exploratory testing (signing in with Work/School and Home/Pro variants) shows how easily platform subtleties can derail a chapter draft.

---

Strengths: why the passkey evolution is a real win​

• Phishing resistance: Passkeys use FIDO/WebAuthn public‑key cryptography; private keys never leave the authenticator, making credential‑harvesting attacks far less effective. This is the single largest security advantage over passwords and OTPs.
• User experience: For many users, a biometric tap (Windows Hello) or a single approval on a phone is easier than remembering or rotating complex passwords. That means fewer resets, fewer help‑desk tickets for password problems, and a smoother daily life for users.
• Platform choice: The system provider model gives users vendor choice — you can pick the vault that fits your recovery and sync preferences, rather than being locked into whatever browser or platform store happens to be active.
• Enterprise hooks: When packaged and managed properly, system providers can be enforced or constrained by MDM/Group Policy, enabling a path to enterprise adoption rather than a consumer-only feature. Early guidance suggests admins will need to review Windows Hello for Business and MDM policies carefully.

---

Risks, unknowns, and operational realities​

No platform shift is risk‑free. The passkey transition adds new operational surfaces and questions that organizations and advanced users must consider.

Recovery and portability risks​

• Vendor recovery dependence: If you centralize passkeys in a third‑party vault, your recovery posture depends on that vendor’s account recovery design. That’s often fine for consumers but can be an unacceptable single point of failure in high‑assurance enterprise contexts.
• Device‑bound credentials: Device‑bound passkeys (local, non‑synced) are safer from centralized compromise but lack portability; users who lose their device can be locked out unless the service provides a backup path. Paul Thurrott argues most people should avoid relying solely on device‑bound keys.

Packaging and distribution complexities​

• MSIX requirement: Vendors must ship MSIX packages (or otherwise register correctly) to appear as system providers. That creates enterprise packaging and distribution work: some organizations block Store/MSIX installs and require MSI/EXE workflows, which could delay or complicate adoption.

Browser and app fragmentation​

• Different browsers may prioritize their own manager or have divergent UX for the passkey chooser. That can create inconsistent end‑user prompts and confusing flows. Until browser vendors converge on a consistent UX that defaults to the OS provider when available, expect friction.

Enterprise and Entra/Azure AD edge cases​

• Microsoft’s consumer MSA sync and the enterprise Entra/Azure AD story may not be parity at launch. Admin controls, attestation policy, and conditional access interactions for synced passkeys require explicit documentation and vendor guidance before enterprises can fully trust the model for AAL2/AAL3 mandates. Treat current enterprise timelines as provisional until Microsoft publishes full admin tooling.

Usability paradox that Thurrott documents​

• The more thoroughly you explain passkey use-cases, the longer and more repetitive your documentation becomes — the very problem Thurrott is trying to avoid. Short, task-focused guidance must now consider multiple flows (phone, extension, device provider, hardware key) without duplicating steps. That’s a real content and pedagogy challenge.

---

Practical guidance: what users and IT should do now​

For everyday users (consumer-focused checklist)​

• Update Windows 11 to the latest cumulative updates (install KB5068861 or later) and reboot until Settings > Accounts > Passkeys appears.
• Choose a primary passkey storage strategy:
• If you already use a trusted third‑party password manager (1Password, Bitwarden), prefer the vendor’s MSIX build and enable the passkey provider.
• If you prefer Microsoft’s ecosystem, you can opt into Microsoft Password Manager as the system provider.
• Keep at least one high‑assurance fallback (hardware FIDO2 key) for critical accounts and admins.
• Test recovery flows: remove a device from your vault and simulate a device loss to confirm you can recover access. Don’t skip this.
• Avoid using device‑bound passkeys as the only storage method for accounts you rely on regularly; use synced vaults or hardware keys as part of a recovery plan.

For IT teams and security leaders​

• Pilot with a small group and document:
• Which browsers and versions you support.
• Packaging channels (MSIX vs other installers) and distribution policies.
• Help‑desk scripts for PIN/Windows Hello resets and vault recovery.
• Validate vendor claims: request threat models and recovery documentation from third‑party vault vendors. Don’t assume parity between consumer sync and enterprise workflows.
• Update MDM/Group Policy:
• Decide which providers are allowed and how to authorize registration.
• Confirm Windows Hello for Business settings and attestation requirements.
• Keep hardware FIDO2 tokens available for privileged accounts and break‑glass scenarios.
• Communicate to end users: short, safe, and repeated messaging beats long single manuals. Focus on “how to sign in” and “how to recover” rather than the full cryptographic details.

---

How writers should document passkeys (a short template)​

Writers like Paul Thurrott face the same problem admins do: complexity breeds repetition. Here’s a short, action‑oriented documentation template that minimizes duplication while covering the essential flows:

• Quick summary (one paragraph): What a passkey is and the recommended default (vault + Windows Hello).
• Which button to click (step by step) for common flows:
• Creating a passkey on a website: click “Create passkey” → choose your provider → authenticate with Windows Hello or phone.
• Signing in: click “Sign in with passkey” → pick provider or device → Windows Hello verifies.
• Recovery (two bullets): vendor recovery steps + hardware key fallback.
• Troubleshooting (three bullets): missing provider toggle (install updates & MSIX), QR pairing issues (try phone app & extension), lost device (use recovery codes/hardware key).

This structure echoes Thurrott’s final refactor idea: organize by method (phone, extension, device provider) and then by action (save, use, manage) to avoid repeating the same prose across multiple sections.

---

A balanced verdict​

The platform‑level passkey provider model is the missing UX piece that passkeys needed on desktop: it improves portability, makes passwordless sign‑in more practical, and reduces phishing exposure. It changes the authentication landscape in a way that benefits both consumers and, eventually, enterprises — provided the ecosystem finishes a few unfinished chores (recovery tooling, MSIX distribution options, browser convergence, and enterprise admin tooling).
Paul Thurrott’s frustration — the drafting, re‑drafting, and the ADHD‑driven derailment — is instructive. Writing about security at the speed of platform change is hard. The documentation must be simple in the face of a system that is deliberately pluralistic: multiple providers, multiple discovery methods, and multiple recovery models. That plurality is good for choice, but it demands better, shorter explainers, clearer vendor documentation, and deliberate testing before broad rollout.

---

Final recommendations for readers and writers​

• Update, test, and then adopt: install the November 2025 cumulative update, test passkey flows across browsers and devices, then enable for non‑critical accounts first.
• Prefer MSIX vendor builds when using third‑party vaults on Windows — they are the supported path to become a system provider.
• Keep a hardware token and documented recovery plan for essential accounts.
• When documenting, organize materials by user action (create, sign, recover) and method (phone, extension, device provider) to avoid repetitive content while still covering the scenarios users will encounter.

Passkeys are a technical and UX win; the OS-level provider model removes a lot of friction. The post-rollout work — vendor validation, recovery testing, and clear, concise user guidance — is where real success will be measured. Paul Thurrott’s personal account of being stuck in the weeds while trying to simplify a chapter is a useful reminder: major platform changes are not just engineering problems; they are human problems that require empathy, testing, and careful explanation.

---

Source: Thurrott.com From the Editor's Desk: A Mind is a Terrible Thing