Microsoft's recent servicing updates for Windows 11 have changed how the operating system handles FIDO2 security-key sign‑ins: devices updated with the September 29, 2025 preview (KB5065789) or the November 11, 2025 security rollup (KB5068861) may now prompt users to create or enter a
PIN for their security key during authentication when a Relying Party (RP) or Identity Provider (IdP) requests
userVerification = "preferred".
Background
WebAuthn and FIDO2 are the standards that underpin modern passwordless and hardware-authenticator sign‑ins. A core WebAuthn parameter is
userVerification — a hint or requirement that tells the authenticator whether to perform local, user-level verification (for example: a PIN or biometric check). The parameter accepts three values:
- required — user verification must occur; if not available, the operation fails.
- preferred — the RP prefers user verification if possible, but will accept the credential without it.
- discouraged — the RP does not want user verification and signals that the platform should avoid it when possible.
The WebAuthn specification treats
preferred as a hint to the client/platform: when an authenticator is capable of user verification but no UV method is provisioned, a platform may attempt to obtain one. Microsoft’s recent changes align Windows’ behavior more strictly with this interpretation, allowing the platform to prompt for PIN setup during the authentication flow when a key supports UV but lacks a configured PIN and the RP asked for
preferred UV.
What changed (the technical shift)
Prior to these updates, Windows primarily handled PIN setup as part of the
registration (credential creation) process for FIDO2 authenticators. Authentication flows were generally expected to be non‑interactive with respect to provisioning a PIN; a roaming security key without a PIN would often accept a simple touch to complete sign‑in if the RP allowed it.
With the September 29, 2025 preview (KB5065789) and the broader November 11, 2025 security rollout (KB5068861), Windows added the capability to offer
PIN setup during an authentication ceremony when the following conditions are true:
- The RP/IdP sends a WebAuthn authentication request with userVerification: "preferred".
- The FIDO2 authenticator is capable of user verification (i.e., supports a PIN or local biometric), but no PIN or UV credential is currently configured on the key.
- The OS build includes the updated support shipped in the preview or subsequent cumulative updates (see affected KBs/builds below).
This behavior is intentional and documented by Microsoft as an alignment with WebAuthn semantics — the platform will attempt to satisfy an RP’s preference for user verification where possible. Microsoft and multiple independent reporting sources confirm the rollout and the builds affected.
Affected updates and builds (confirmed)
The updates that introduced or completed this client-side change are:
- KB5065789 — September 29, 2025 preview (OS Builds 26200.6725 and 26100.6725).
- KB5068861 — November 11, 2025 security update (OS Builds 26200.7171 and 26100.7171) that completed the staged rollout to Windows 11 clients.
Administrators and power users should check device build numbers in Settings > System > About to determine whether these updates are installed on a given endpoint. The Microsoft release notes and independent reporting both reference these KBs as the key distribution artifacts for the changed behavior.
How this affects end users: practical UX scenarios
Short version: if you plug in (or use) a FIDO2 security key that previously authenticated with only a touch, you may now see a prompt to
create a PIN during sign‑in — but only when the website or service has asked for
userVerification = "preferred" and the key is capable of UV but lacks a PIN.
More detail:
- If an RP sets userVerification = "preferred" and the authenticator can perform UV, Windows may offer to create a PIN during the authentication flow so the request’s UV preference can be fulfilled. This can appear suddenly after updating Windows even for keys that previously worked without PINs.
- If an RP sets userVerification = "discouraged", Windows will not prompt to create a PIN as part of the authentication ceremony (unless the authenticator’s own firmware or configuration mandates a PIN). This is the appropriate configuration for services that want a tap‑only experience.
- If an RP requires userVerification = "required", authentication will fail unless the authenticator has an available UV method (PIN or biometric). Administrators and developers should explicitly use required when they need a hard guarantee.
User impact examples:
- A consumer who uses a USB security key for personal accounts may be prompted to set a PIN during a login after a Windows update. The on‑screen flow walks the user through PIN creation and binds the PIN to the key’s use on that platform.
- An employee in an enterprise may call the helpdesk when an in‑office service that historically accepted touch‑only keys now asks the user to create or enter a key PIN — this is normally not an indicator of compromise, but of changed platform semantics.
Why Microsoft made the change (standards and interoperability)
The core rationale is
standards compliance and consistent platform behavior. WebAuthn’s semantics treat
preferred as a hint that should be attempted when feasible; platforms that never try to provision UV during authentication create asymmetric behavior between registration and later sign‑ins. Microsoft’s change closes that gap so RPs can rely on the platform to attempt to satisfy the
preferred hint and developers can have more predictable outcomes across devices and browsers. This alignment reduces fragmentation between how different operating systems and browsers handle UV hints.
Security rationale:
- Upside: Prompting for a PIN when UV is requested improves local assurance that the person using the key is present and consents to authentication — raising the bar against unauthorized physical use. It also reduces silent credential usage in cases where RPs genuinely wanted UV.
- Downside: The UX can feel regressive for users and organizations that intentionally deploy tap‑only keys without PINs. That friction creates operational costs and potential confusion.
Risks, side effects, and operational impact
This change is small in code but significant in support and policy terms. Key risks and operational concerns include:
- Helpdesk volume: Enterprises should expect increased support tickets as users encounter PIN‑creation prompts they did not see before. Prepare knowledge‑base articles and scripted recovery steps.
- Unintended UX friction: Consumer services and internal apps that leave userVerification at the default preferred may unintentionally force users to create PINs. Developers must be explicit in their WebAuthn options to avoid surprise behavior.
- Compatibility variance: Not all authenticators and browsers behave identically. Some keys or third‑party platforms may ignore or override PIN prompts; others may require vendor‑specific tools for PIN management. Expect cross‑platform differences and test broadly.
- Policy mismatch: Organizations that require tap‑only or kiosk scenarios will need to audit their relying‑party configurations and may have to change WebAuthn settings to maintain low-friction flows.
Where the concern is that this behavior equates to a vulnerability: it does not. The prompt to create a PIN is an OS/UX decision to satisfy the RP’s preference for UV. It does not reflect an attack or exfiltration. That said, it does increase the administrative surface (PIN resets, PIN recovery, lost-key workflows), and those operational processes must be managed carefully.
Practical guidance — what IT teams should do now
- Inventory and verify build status.
- Confirm which devices have KB5065789, KB5068861, or later cumulative updates installed and note affected OS builds (26200.6725 / 26100.6725; 26200.7171 / 26100.7171). Use centralized patch telemetry or endpoint management tools.
- Audit your WebAuthn usage across services.
- Locate all RPs/IdPs and determine how they set userVerification during authentication and registration. If a tap‑only experience is required, change the setting to discouraged where acceptable; if your security model demands a local verification factor, set required. Testing is essential.
- Update helpdesk documentation and user communications.
- Add a clear explanation for users who see a PIN prompt: why it appears, how to create a secure PIN, and how to recover if forgotten. Document vendor‑specific PIN reset paths (for Yubico, Google Titan, other brands).
- Pilot and validate.
- Test authentication flows across representative devices, browsers, and security keys in a staging environment to reproduce the new prompt behavior and confirm acceptable UX for business‑critical services.
- Consider policy or technical mitigations where necessary.
- If certain internal apps cannot tolerate PIN prompts, evaluate whether setting userVerification to discouraged is an acceptable tradeoff, or whether you must provision hardware keys with preconfigured UV to avoid on‑the‑fly PIN setup. Treat any allow‑listing or workaround as temporary and document risks.
- Communicate with application owners.
- Ensure app owners understand the effect of leaving userVerification as preferred and the tradeoffs between friction (PIN prompts) and assurance (UV). Promote an explicit decision for each app.
Guidance for developers and Relying Parties
Developers shaping authentication flows must be explicit and intentional:
- Use userVerification: "required" when you need a guaranteed local verification factor; this prevents fallback-only credentials.
- Use userVerification: "discouraged" when you require tap‑only or low‑friction flows (understand the security tradeoffs).
- Avoid relying on defaults or implicit semantics — preferred is a hint and will yield different UX across platforms; if consistent behavior matters, be explicit.
Testing checklist:
- Test registration and authentication flows against updated Windows 11 clients (post‑KB5065789 and KB5068861).
- Validate behavior with all supported browsers and with roaming vs platform authenticators.
- Add help text to your login UX that explains a possible PIN prompt so users are not surprised.
End‑user steps and PIN management
If prompted to create a PIN during a security‑key sign‑in:
- Follow the on‑screen setup guidance; a PIN is bound to the security key and improves local verification.
- Choose a unique, non-trivial PIN; avoid simple sequences or repeating digits.
- Store recovery information for accounts that rely on that key (backup passkeys, recovery codes, secondary keys).
If a user cannot complete PIN setup:
- Try another browser or device to confirm whether the prompt is platform‑specific.
- Consult the key vendor’s management tool or documentation for firmware or vendor‑specific PIN procedures.
- Contact your organization’s helpdesk if the device or account is managed.
Security analysis — benefits and tradeoffs
Strengths
- Increased assurance: When RPs request UV, the platform’s attempt to provision a PIN ensures local user verification is available and used where the RP expects it. This reduces gaps between registration expectations and later authentication behavior.
- Standards alignment: Converging platform behavior with WebAuthn semantics favors long‑term interoperability and makes multi‑platform authentication decisions more predictable.
Tradeoffs and risks
- User friction: Unexpected PIN prompts reduce the seamlessness of tap‑only flows and may increase abandoned sign‑ins or support calls.
- Operational complexity: PIN management, resets, and recovery workflows introduce support overhead and new failure modes, especially in large fleets.
- Cross‑vendor fragmentation: Not all security key vendors implement identical PIN workflows; behavior can differ across device firmware and platform implementations. Thorough testing is required.
Caveat on unverifiable claims
- Any broad estimate of the percentage of users affected, or predictions about the number of helpdesk calls you should expect, are situational and depend heavily on the organization’s authentication topology. Treat such estimates cautiously and rely on telemetry from your fleet for planning.
Quick checklist — immediate actions (summary)
- Verify which endpoints have KB5065789 / KB5068861 installed.
- Inventory services that use WebAuthn and document their userVerification settings.
- Update helpdesk scripts and user communications to explain PIN prompts and recovery paths.
- Pilot changes and test on representative hardware/browsers before broad rollout.
Conclusion
The recent Windows servicing updates deliberately tighten Windows’ WebAuthn behavior: the platform will now attempt to provision user verification (for example by prompting to create a PIN) during authentication when a service requests
userVerification: "preferred" and the key is capable but unprovisioned. That change brings Windows into closer alignment with the WebAuthn specification and improves security assurance when RPs ask for UV — but it also introduces real user‑experience and operational implications that organizations and developers need to manage.
The practical path forward is straightforward: inventory updated devices, audit and explicitly set WebAuthn flags for each RP, update user and support documentation, and run measured pilots to observe the real‑world impact. Planning and clear communication will turn what looks like an unexpected change into a manageable standards‑driven upgrade to your authentication posture.
Source: Cyber Press
https://cyberpress.org/microsoft-security-keys/