Why do passkeys fail on managed Windows devices?

1. Introduction#

At Corbado, we're often asked how many devices in a corporate fleet are ready for passkeys? There is no reliable public percentage. The answer depends on the devices an organization has deployed and the policies applied to them.

We've faced the problem ourselves. Companies have given us managed laptops or access to virtual desktops so we could test a passkey implementation in their environment. On some devices Windows Hello could not be provisioned. On others the network blocked cross-device authentication (CDA). Passkeys failed before the actual implementation could be tested.

This is common in large organizations. Security teams may have blocked Windows Hello years before a passkey project started. Employees sign in with authenticator apps, RSA tokens or OTPs. The team building a customer login then discovers that its standard development environment cannot create a passkey.

Treat device readiness as an organization-specific measurement task. Start with the device inventory, policy history, virtual desktop setup and network rules. Then test the real cohorts. Consumer benchmarks cannot answer the question for a corporate fleet.

2. Why Windows Hello can be unavailable on a managed device#

Many fleets use Windows Hello for Business. When passkeys fail across a company, the cause is usually a combination of device state, policy, virtual desktop architecture or network access. None of those is visible from the backend or admin panel of a login page.

2.1 Policy decides whether Windows Hello can be provisioned#

Windows Hello for Business is controlled centrally. In Microsoft Intune the relevant switch is the PassportForWork configuration service provider, where ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork set to false prevents Windows Hello for Business provisioning on the device. A second setting, DisablePostLogonProvisioning, stops Windows from starting provisioning after sign-in. Microsoft lists both together with their group policy equivalents for domain-joined machines.

A WHfB credential used for device sign-in and a website passkey saved through Windows Hello are different credentials. Windows can store both as separate keys in the same Windows Hello container. The PIN or biometric authorizes use of the keys in that container, as described in Microsoft's Windows Hello architecture.

Disabling WHfB doesn't automatically disable every passkey path. If no Windows Hello container exists and device policy prevents Windows Hello setup, Windows Hello cannot act as the local platform authenticator. A security key, a phone or a permitted third-party passkey manager may still work.

On the device the result looks like this. Face, fingerprint and PIN all report "This option is currently unavailable". Windows says why in one line at the top:

That is a Windows 11 Enterprise machine on 25H2, build 26200.9106, so a current one. The policy does not go away when the fleet updates.

The setting predates most passkey projects. Organizations may keep it disabled because:

• Biometrics on corporate hardware can require privacy and works council review (e.g. in Europe), although biometrics are optional and biometric data remains on the device.
• Shared and roaming workstations in branches, call centers and trading floors do not fit a simple one-user-per-device model.
• Hardware security requirements may exclude older devices or devices without the TPM configuration required by the organization.
• Smart cards or other workforce methods may already cover device sign-in.

The people who own that policy are not the people who own your login, so switching Windows Hello on is an endpoint management project with its own timeline. The rest of this article assumes you can't just switch it on easily.

2.2 A policy change can split one fleet into two states#

This split happens when Windows Hello for Business was allowed first and disabled later or when a blocking policy reached some devices only after they had provisioned Windows Hello. The clearest documented example is Intune's tenant-wide setting. Microsoft says it applies only at device enrollment and later changes do not apply to devices already enrolled. Microsoft staff also confirms that disabling this setting does not stop users from using an existing PIN. Targeted GPO or CSP policies can refresh after enrollment, so check which policy type the organization uses. Disabling provisioning alone does not delete an existing Windows Hello container.

As long as the container remains, a user can continue to unlock it with a PIN or biometric. The browser may therefore continue to offer Windows Hello as a platform authenticator, including for website passkeys already stored in the container. New website passkey creation may also remain available. Other passkey access policies and application settings can change that result, so test both registration and authentication on the affected cohort.

Removing the existing state is a separate action. Microsoft points to certutil.exe -deleteHelloContainer as the way to remove the container. On current Windows 11 builds that command also removes WebAuthn and FIDO credentials stored on the device. Organizations need a recovery path before running it.

The result looks random in aggregate. Devices with the same Windows version and browser can report different platform-authenticator availability because their provisioning history differs. Segment by Windows Hello state and policy history as well as operating system and browser.

2.3 Virtual desktops depend on the physical endpoint#

In a virtual session, the application runs on the session host while the authenticator is usually attached to the physical endpoint. Citrix supports FIDO2 and WebAuthn redirection so an application inside the session can send a WebAuthn request to Windows Hello or a security key on the endpoint. This is the virtual desktop point that matters: the endpoint must have a usable authenticator and Citrix must redirect the request.

There are two importnant boundaries:

1. Redirection covers WebAuthn in applications after the virtual session starts. It doesn't sign the user into the Citrix session itself.
2. Citrix supports FIDO2 redirection on a wider set of systems but documents passkey support only when both the endpoint and session host run Windows 11 (Citrix prerequisites).

Where FIDO2 redirection is unavailable, Citrix documents plain USB redirection for USB security keys as a fallback. In a Citrix session without Windows Hello, a registration that accepts any authenticator ends at the security key prompt:

The user needs a physical key in the endpoint's USB port and USB redirection must be enabled for the session to see it.

2.4 Network policy can block sync and CDA#

Even with Windows Hello available, two network paths have to be open. Either one can be closed on a corporate network without anybody connecting that to your login page.

• Sync to the credential manager: Apple lists the hosts its iCloud services need in the enterprise network guide, gateway.icloud.com on 443 among them. Google publishes no equivalent list for passkey sync, so that path has to be tested rather than looked up.
• Cross-device tunnel: The QR code doesn't open a direct link between laptop and phone. Both sides connect to a tunnel service. The service comes from an identifier in the QR code itself. The CTAP 2.2 specification assigns cable.ua5v.com and cable.auth.com and derives further domains by hash, so a blocklist built from those two names does not cover the transport. Where the tunnel in use cannot be reached, the QR code still appears and the ceremony never completes, see our guide on enterprise passkey deployment challenges.

Both can look like a browser bug. Test them from the same network and browser configuration that employees use.

2.5 BYOD must be measured separately#

Bring your own device (BYOD) users are outside most corporate Windows Hello for Business policy. Their Windows laptop may use Windows Hello, a synced credential manager or a phone. This often makes BYOD more passkey-ready than a locked-down corporate fleet.

BYOD is still not equivalent to unrestricted consumer traffic. A company can require a managed browser, apply app-protection rules, route traffic through a corporate network or block credential-manager extensions. The user's OS version and personal credential manager also remain unknown.

Keep at least three cohorts separate in a readiness assessment:

1. Managed physical devices
2. Virtual desktops
3. BYOD

A single percentage across all three hides the action each team needs to take.

3. What users see#

Nothing on screen says what went wrong, which is why the tickets are useless. The map below has the sentence the user writes in the middle and the six possible causes around it, each with the team that owns the fix. The four sections after it walk through the screens users actually get.

3.1 Platform-only flow has no local authenticator#

If Windows Hello is the only local provider and device policy prevents its setup, a capability check can report that no user-verifying platform authenticator is available. A registration that requires authenticatorAttachment: "platform" then has no Windows Hello path. Chrome may show a short notice that the device cannot be used and the ceremony can return a NotAllowedError.

Do not diagnose policy from that error alone. NotAllowedError also covers timeouts, user cancellation and other blocked operations. The earlier capability result and the device's Windows Hello state provide the useful context. See our WebAuthn error reference for the other cases behind the error.

The message names no policy, no admin and no alternative. The ticket then arrives as "the passkey button is broken".

3.2 Browser offers a QR code instead#

If the relying party accepts other authenticator types, the browser can offer a QR code for a phone. It works, but it looks nothing like your screenshots and help pages, so users report it as an error even when it succeeds. The cross-device flow also needs Bluetooth on both sides and internet access on both devices. Corporate policy often blocks at least one part of that path. Microsoft documents how to limit Bluetooth to the FIDO2 services instead of switching it off entirely.

3.3 Dialog asks for a security key#

The Windows security dialog appears, but it asks for the key rather than a face or a fingerprint. Users who were trained on "just look at your laptop" do not recognize this as the same feature.

The "Change" link in that dialog is where a user switches between the security key, a phone and a third-party manager. Most users never find it.

3.4 Third-party credential manager is missing#

Windows 11 lets third-party credential managers act as passkey providers since the November 2025 update, through the plugin passkey manager API. On a managed device the app is often not installed or not allowed, so the flow silently falls back to whatever remains.

4. Windows version changes the available passkey paths#

Windows version matters, but it does not determine readiness on its own. Policy and prior provisioning can still make two devices on the same build behave differently. StatCounter puts Windows 11 at 68.88% of Windows desktop pageviews in July 2026 against 29.88% for Windows 10, with the crossover in July 2025.

Take that number for what it measures. StatCounter counts pageviews on the sites in its tracking network, worldwide, with consumer and corporate devices in one pool. It is a traffic sample rather than a device inventory and it has no enterprise breakout. It shows the public web, not your fleet. Some corporate fleets upgrade later. Windows 10 reached end of support on 14 October 2025. An enterprise device inventory can therefore differ materially from the public traffic split.

What changes with the version:

• Windows 10 can create and use passkeys through Windows Hello, a phone or a security key. It has no native passkey management UI or Windows plugin passkey manager support. The built-in Windows Hello authenticator also lacks the newer PRF capability.
• Windows 11 22H2 with KB5030310 brought the native passkey management experience and the platform authenticator behavior most teams tested against.
• Windows 11 24H2 added the privacy consent prompt. A declined prompt breaks registration and authentication for that application until the user re-enables it under Settings, Privacy & security, Passkeys.
• Windows 11 with the November 2025 security update opened the ceremony to 1Password and Bitwarden.
• Windows 11 25H2 with the February 2026 cumulative update (build 26200.7840 and higher) added hmac-secret, the authenticator side of PRF, which is what makes PRF work on Windows Hello.

The 22H2 line is the one users notice. It is the screen under Settings, Accounts, Passkeys. Support uses it to check whether a passkey exists at all:

On Windows 10 there is no equivalent screen, so neither the user nor support can see what is stored.

The consent from the 24H2 line lives one page away, under Settings, Privacy & security, Passkeys. Access and autofill are separate switches, each with a per-application list:

Worth knowing for support: the "Recent activity" rows count how often applications asked to create, use or enumerate passkeys in the last seven days. On a ticket that is a quick way to see whether the browser reached the platform at all.

Check the Windows 10 share in your own traffic and device inventory. If that cohort is in scope, test it explicitly and keep a fallback path.

5. How to test passkeys when Windows Hello is disabled#

5.1 Virtual authenticators for development and CI#

Chrome DevTools carries a WebAuthn tab that creates a virtual authenticator on any machine, with no hardware and no policy change. You pick the protocol and the transport, switch on user verification and the browser behaves as if a platform authenticator were present. Playwright exposes the same CDP capability for automated tests. Our guide on E2E passkey testing with the virtual authenticator walks through the setup.

It leaves out the platform dialog, the user verification prompt and the provider selection, which is where a managed fleet breaks. Treat it as a development tool rather than a release gate.

5.2 Real hardware without changing fleet policy#

Once the code works, you need a real ceremony. Three paths do that without enabling Windows Hello. Each one covers a different part of the flow and still depends on the organization's security and network policy.

If an earlier project left security keys in a drawer, that path costs nothing. The third row means devices your MDM does not manage: three to five laptops for the test team, signed in with test accounts and connected through a network that reaches the endpoints from section 2.4. Start the network work early because it can take longer than obtaining the hardware.

5.3 What to check in production#

Everything above tests your code. The rollout depends on your fleet, so measure platform authenticator availability, provider distribution and ceremony outcomes on real traffic, split by Windows version.

Published readiness numbers answer a different question. Our consumer readiness benchmark sits in the high nineties, but it describes people visiting a consumer site on their own devices. It says nothing about a fleet whose policy and device mix are set per organization. Corporate readiness has to be measured directly and can differ widely between organizations.

6. Signals that separate the cases#

To debug this in production, collect browser-side data alongside backend events.

• Exact Windows version. "Windows" is too broad. Windows 10, Windows 11 24H2 and 25H2 behave differently, see section 4.
• Device context. Record whether the device is managed, BYOD or a virtual desktop. Add the applied Windows Hello policy and provisioning state where endpoint data is available.
• Platform authenticator availability. Record isUserVerifyingPlatformAuthenticatorAvailable() before enrollment. It shows whether the browser currently sees a user-verifying platform authenticator. It does not reveal the reason or prove that a later ceremony will succeed.
• Authenticator category and transport. Record what the WebAuthn response and stored credential tell you, without assuming that the browser exposes the exact provider. Platform authenticator, synced passkey, security key or hybrid QR. Without it, "Windows Hello did not work" and "the phone handoff failed" look the same.
• Ceremony step and result. Whether the prompt appeared, whether user verification started, which WebAuthn error came back and how long the request ran. A NotAllowedError alone does not separate user cancellation, timeout or policy.
• Journey context. Whether the user fell back to a password, switched browser or gave up. Without it you cannot prioritize the fix.

7. Debugging workflow#

1. Start with the ticket. Replay the user's last attempts and read device, browser, provider and the step where it broke.
2. Expand to the cohort. One ticket is usually the visible part of a policy change, so check whether the same version, browser and transport combination fails for others.
3. Compare to the baseline. A drop right after an OS, browser or policy rollout is evidence of a cohort-level change.
4. Decide the remediation. Suppress the prompt for cohorts without a platform authenticator, offer the QR path explicitly, ship a security key flow or pause the rollout for that segment.

If a group of users cannot create a passkey at all, stop prompting them for one.

8. Measure readiness before rollout#

An internal test tenant can answer the corporate-readiness question without changing the authentication path. Add read-only browser measurement to a page that employees open from their normal work environment. Include managed physical devices, virtual desktops and BYOD if BYOD is in scope.

Corbado Observe is one way to collect this data next to the existing authentication stack:

See how Corbado Connect ships this →

• Capability and provider data: which devices report a platform authenticator and which providers your users bring, split by Windows version, management context and virtual desktop use.
• Ceremony outcomes: where the passkey flow breaks, including the cases that never reach your backend.
• Cohort comparison: the same funnel per Windows version, so a policy rollout shows up as a step in the curve.
• Per-user replay: reconstruct one user's attempts when support escalates a ticket.

A useful readiness assessment ends with four outputs: a device cohort map, the policies that affect each cohort, a test matrix for the available authenticator paths and a baseline for success, fallback and abandonment. That is enough to decide where passkeys can launch now and where endpoint or network work comes first.

9. Conclusion#

On managed Windows devices, a failed passkey flow can come from application code, endpoint policy, provisioning history, virtual desktop redirection or network controls. Device readiness cannot be answered with a public benchmark.

Inventory the real cohorts and measure them in the environment where they work. Offer a phone or security-key path where a local authenticator is unavailable. Keep users out of enrollment flows that their device cannot complete. This gives product, identity, endpoint and network teams a concrete plan instead of one fleet-wide readiness guess.

10. Frequently asked questions#

10.1 Why does the passkey prompt never appear on a managed Windows laptop?#

If a registration requires a platform authenticator and Windows Hello is the only local provider, device policy can leave that registration without a Windows Hello path when it prevents the container from being created. A security key, a phone or a permitted third-party passkey manager may still work when the relying party allows them. A later NotAllowedError does not prove a policy problem because it covers several WebAuthn outcomes.

10.2 Why do passkeys work for some users in the same fleet but not others?#

Disabling Windows Hello for Business provisioning does not, by itself, remove an existing Windows Hello container. Users who provisioned it earlier can keep using their PIN or biometric and Windows Hello-backed website passkeys while the container remains and no other policy blocks their use.

10.3 How do I test a passkey login if the corporate fleet has no Windows Hello?#

Use Chrome DevTools or Playwright for protocol tests, a FIDO2 security key for a real ceremony, a phone over QR for the cross-device path and a small ring of unmanaged devices for the consumer credential-manager experience. The last two need the network access described in section 2.4.

10.4 Do passkeys work in a Citrix or virtual desktop session?#

Citrix can redirect WebAuthn requests from applications inside a virtual session to an authenticator on the physical endpoint. That does not authenticate the user into the Citrix session itself. Citrix documents passkey support only when both the endpoint and session host run Windows 11. A security key over plain USB redirection can be a fallback.

10.5 Does BYOD improve passkey readiness?#

Often, because a personal device is usually outside the organization's Windows Hello for Business policy. It can still be affected by managed-browser rules, corporate network controls and the user's OS or credential-manager setup. Measure BYOD separately from managed devices and virtual desktops.

10.6 What data should I collect to debug passkey failures on managed Windows devices?#

Collect the Windows build, browser, device-management state, Windows Hello provisioning state, platform authenticator capability, available authenticator category, transport, ceremony result and fallback outcome. The capability result shows whether a local authenticator is available in that browser context. It does not explain why.

10.7 What percentage of a corporate fleet is ready for passkeys?#

There is no percentage that transfers reliably between organizations. Readiness depends on the device inventory, Windows versions, Windows Hello provisioning, virtual desktop setup, browser controls, credential managers and network policy. Measure the cohorts in your own environment before setting a rollout target.