Web Passkey Readiness

Readiness is measured on completed web logins. We do not just rely on browser API answers (getClientCapabilities / isUVPAA). A device counts as ready when the browser API is positive and it actually has a usable platform authenticator set up (e.g. Windows Hello enrolled, iCloud Keychain or Google Password Manager active). Devices where the API says "yes" but no passkey provider is configured do not count.

Platform	Start 2025	End 2025
iOS1,2	100%	99%
Android	96%	97%
ChromeOS	94%	95%
macOS	88%	91%
Windows 113	85%	85%
Windows 103	56%	70%

1. iOS is browser-only in this table. App and webview contexts are excluded because they are not normal browser contexts for relying-party passkeys; the Google App is the most important example. Depending on market mix, those contexts can account for roughly 1-10% of iOS web usage. Since passkeys do not work there like they do in a browser, that traffic can drag measured iOS readiness down by roughly the same amount and create login friction.
2. The iOS 26.2 WKWebView isUVPAA() regression is already visible at the end of 2025, then draws down third-party iOS browser readiness more heavily in the following months before recovery starts. Corbado documents the bug and recovery path in this iOS 26.2 isUVPAA analysis.
3. Windows 10 and Windows 11 show Microsoft's continued passkey-readiness work paying off, especially around the December 2025 and February 2026 update waves, with further improvement in 2026 also visible for Windows 11. The browser split matters too: Google Password Manager passkey sync reached desktop Chrome on September 19, 2024, while Microsoft announced passkey saving and syncing in Edge 142 on Windows on November 3, 2025. Those provider changes help explain why Chrome improves through 2025 and Edge catches up more visibly in early 2026.