Passkey Troubleshooting: Solutions for Passkey Issues & Errors

1. Introduction#

Passkeys are now supported by 20% of the world's top 100 websites and 53% of consumers globally have enabled passkeys on at least one account, per the FIDO Alliance Authentication Barometer 2024. Amazon, WhatsApp, Coinbase, TikTok, Facebook, LinkedIn and X/Twitter have all shipped support since 2023.

The W3C WebAuthn Level 3 specification defines a range of DOM exceptions, but browsers deliberately collapse most failures (user cancellation, timeouts, ineligible authenticators) into the generic NotAllowedError to avoid privacy leaks, per the W3C Privacy Considerations. Many relying parties also define their own error messages, since there are not many best demonstrated practices apart from the FIDO Alliance's UX guidelines. This guide maps the most common consumer-facing wordings to a clear cause and a practical fix, with screenshots from both the original release and the latest iOS and Android builds.

If a "google passkey not working" on your device, the first check is whether the browser, the OS and Google Play services are all on a current build, since most regressions are fixed within one or two releases.

2. How Do Passkeys Work?#

Passkeys are passwordless credentials based on the WebAuthn API and the underlying CTAP 2.2 specification from the FIDO Alliance. The W3C standardized WebAuthn Level 1 in March 2019, Level 2 in April 2021 and Level 3 in 2024. Adoption hit roughly 1 billion enrolled credentials across major ecosystems by Q4 2024, per FIDO Alliance Authenticate 2024.

The device generates a unique key pair on registration. Only the public key is sent to the relying party, while the private key stays inside the secure enclave, TPM or TEE. On sign-in, the server sends a challenge, the device unlocks the private key with Face ID, Touch ID or Windows Hello, signs the challenge and returns the signature. The relying party verifies it with the public key.

Because the private key never leaves the device, phishing and password reuse stop working as attack vectors. From a user perspective, the entire flow is a single biometric prompt.

3. Passkey Requirements#

3.1 iOS or macOS#

iCloud Keychain Enabled:

iCloud Keychain is the storage location for credentials on Apple devices and ships on iOS 16, iPadOS 16 and macOS Ventura 13 or later. Apple reported around 2.2 billion active devices in early 2024, of which over 90% run iOS 16 or later, per Apple's developer dashboard. To enable iCloud Keychain, navigate to your device's settings, select your Apple ID, go to iCloud and then enable iCloud Keychain (read more here). Per Apple's developer documentation, iCloud accounts with Keychain enabled are enforced to use MFA.

iOS 16 or macOS Ventura Required:

iOS 16 launched on 12 September 2022 and macOS Ventura 13 on 24 October 2022. On iOS 18 the storage moved into a dedicated Passwords app, which is why some prompts now read "Passwords" instead of "iCloud Keychain". Per Apple support, users on older OS builds cannot create or use passkeys at all.

3.2 Windows#

Windows Hello Setup:

Windows Hello is required to create or use passkeys on Windows 10 and Windows 11 devices. Per Microsoft's Windows passkey documentation, Windows 11 build 22631 (November 2024) shipped the native passkey UI and Windows 11 25H2 (November 2025) added support for third-party passkey managers like 1Password and Bitwarden. Windows Hello accepts a fingerprint, a face scan or a 6-digit PIN. Configure it under Settings > Accounts > Sign-in options (read more here).

3.3 Android#

Android Version 9 or Later:

Android 9 (Pie) shipped on 6 August 2018 and is the minimum for the Credential Manager API. Per the Android distribution dashboard, Android 9 and later run on roughly 95% of active Android devices in 2026. Older builds cannot use passkeys at all because they miss the StrongBox Keymaster and the Credential Manager.

Google Play Services Updated:

Google Play services version 23.40 or later is required for the Credential Manager. Google Play services updates roughly every 4 to 6 weeks and most issues with "google passkey not working" trace back to a stale version. Update Google Play services and the system WebView under Settings > Apps and retry.

On all platforms, keep the browser on a current build. Safari, Chrome and Edge ship roughly weekly stable updates and most regressions are fixed within one or two releases.

4. Common Passkey Errors, Their Causes and Troubleshooting#

We track around 15 recurring error patterns across iOS, Android and Windows clients, which together account for the bulk of consumer support tickets observed across major relying parties. The next 6 sections group those errors by root cause: iCloud Keychain and the Apple Passwords app, no available credential, QR code and cross-device flows, Windows-specific issues, Android-specific issues and the generic WebAuthn or browser bucket.

Every entry includes screenshots from the original release as well as the latest iOS builds and Android Credential Manager builds, the most likely cause and a solution that has worked for others. Where useful, the entry references the W3C WebAuthn Level 3 specification, the FIDO Alliance specifications or the relevant platform documentation from Apple, Microsoft and the Android Credential Manager.

5. iCloud Keychain and Apple Passwords App Errors#

This group covers the two errors that Apple devices show when iCloud Keychain is not set up correctly. Both are surfaced by the system, not by the relying party. iCloud Keychain is a hard requirement for passkeys on iOS 16, iPadOS 16 or macOS Ventura 13 and later, per Apple's developer documentation. On iOS 18 the storage moved into the new Passwords app, which is why the wording changed.

Error Message: To save a passkey, you need to enable iCloud Keychain. You can enable Keychain in the Apple ID pane of System Settings#

On the latest iOS the wording reads "To use passkeys, you need to enable iCloud Keychain" and the path was renamed to Settings > Apple Account > iCloud > Passwords and Keychain:

• Cause: iCloud Keychain, the storage location for credentials on Apple devices, is not enabled.
• Solution: Enable iCloud Keychain in the Apple ID pane of System Settings (or Settings > Apple Account > iCloud > Passwords and Keychain on iOS 18). Make sure it syncs across your devices, otherwise the credential will only exist locally.

Error Message: There are no matching passkeys / There are no matching passkeys saved in your iCloud Keychain#

On the latest iOS the prompt is now branded with the new Passwords app and reads "There are no matching passkeys saved in Passwords for ...":

• Cause: The user tries to sign in with a credential that is not stored in iCloud Keychain on the current device, or sync between devices is broken.
• Solution: Confirm that iCloud Keychain is enabled on every Apple device used by the same Apple ID. If the credential exists on another iPhone or Mac but not on the current one, force a Keychain sync by toggling iCloud Keychain off and on, then retry the sign-in. If no credential exists at all, register a new one from the relying party's account settings.

6. No Available Passkey and Already Exists Errors#

These errors appear when the credential the user expects either is not on the current device, was already registered or has been deleted on one side and not the other. The WebAuthn properties AllowCredentials and excludeCredentials drive most of this behavior on the server side.

Error Message: No passkeys available. There aren't any passkeys for Relying Party on this device#

On Android the same error is surfaced by Google Play services with "No passkeys available. There aren't any passkeys for <relying party> on this device" and a "Use a different device" fallback:

• Cause: No matching credential is on the current device and the WebAuthn server does not allow any cross-platform authenticator. The same error message also appears when the user has deleted the local credential but the server still expects it.
• Solution: Verify whether a credential exists on the device. If it was deleted in iCloud Keychain or Google Password Manager settings, also remove it server-side in the account settings of the relying party. Otherwise the server keeps requesting the missing credential and the error keeps showing up.

Error Message: Passkey already exists (or similar error message as it's defined by the relying party)#

• Cause: A new registration is attempted on a device that already has a credential for the same account. Many relying parties only allow one credential per device or per ecosystem (e.g. synced iCloud Keychain or 1Password) by setting excludeCredentials on the WebAuthn server.
• Solution: Use the existing credential, or register a new one from a different device. Alternatively, delete the old credential in the relying party's account settings, then register a new one.

Error Message: We couldn't find a matching passkey (or similar message from the relying party)#

• Cause: A credential was deleted manually, either on the client side or on the server side. Even if the local private key still exists, the absence of the matching public key on the server triggers this error.
• Solution: Sign in from another device or use a fallback authentication method. Then create a fresh credential from the account settings, which re-establishes the client-server pair.

7. QR Code and Cross-Device Sign-in Errors#

The QR code flow uses the FIDO hybrid transport (also called CTAP 2.2 hybrid). Per the FIDO CTAP specifications, the two devices exchange a one-time secret over the QR code and then communicate over Bluetooth Low Energy at a maximum range of about 3 meters. Both Bluetooth and proximity are required, otherwise the flow fails silently.

Error Message: I'm seeing a QR code#

On the latest iOS the cross-device QR sheet now reads "Scan QR Code. Scan this QR code with a compatible device to sign in to ...":

On Android the Credential Manager surfaces the same flow as "No available sign-in" with a Show QR code option and a fallback to Open Google Password Manager:

• Cause: The credential is bound to a specific account and platform (the device or a cloud-synced platform account like iCloud Keychain). Seeing a QR code means no credential exists on the current device, even if the user previously enrolled one on iOS or Android. The other common cause is that the server restricts the credentials it accepts via the WebAuthn property AllowCredentials and the available local credentials do not match.
• Solution: If the original device has a camera, scan the QR code to sign in via the hybrid transport. Otherwise use a fallback method, sign in and then enroll a fresh credential for the current device in the relying party's account settings.

Error Message: Bluetooth required for cross-device passkey sign-in#

• Cause: The hybrid transport requires Bluetooth Low Energy between the two devices. If Bluetooth is off on the PC or on the phone, the flow fails silently with generic "Something went wrong" or "We couldn't sign you in" messages.
• Solution: Enable Bluetooth on both devices and keep them within roughly 3 meters of each other, then retry the QR flow. If Bluetooth cannot be turned on (e.g. enterprise policy or older hardware), use a fallback sign-in and then enroll a device-local credential so future sign-ins no longer depend on the hybrid transport.

8. Windows-specific Errors#

Windows builds have shipped several passkey-related regressions over the past 18 months. Per the Microsoft Windows passkey documentation, build 22631 (November 2024) added the native passkey UI and Windows 11 25H2 (November 2025) added third-party passkey manager support. Both shifts reset some Windows Hello state.

Error Message: Insert your security key into the USB port#

• Cause: A hardware security key (e.g. YubiKey) is required because the device has no TPM or Windows Hello is disabled. The same prompt also appears on machines without Bluetooth that cannot use the hybrid transport and have no local credential.
• Solution: Insert the security key (e.g. YubiKey) into the USB port. To skip the hardware key, enable Windows Hello first and then create a Windows Hello credential before the next sign-in.

Error Message: Microsoft account passkey keeps failing after recent Windows update#

• Cause: Several Windows 11 Insider and release builds have broken Microsoft account sign-in flows, surfacing as "Something went wrong", "We couldn't sign you in" or silent failure during creation. The root cause is usually a corrupted Windows Hello state or a Microsoft account that was originally configured with an older setup.
• Solution: Sign in with password plus MFA, remove the broken credential in the Microsoft account security settings and create a new one. On a local account, back up and clear the Windows Hello NGC folder (C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc), then re-enrol Windows Hello. Treat Microsoft account sign-in on Windows as best-effort and always keep at least one non-passkey MFA option active.

9. Android-specific Errors#

The Android Credential Manager API requires Google Play services 23.40 or later and relies on the secure lockscreen for user verification, per the Android Credential Manager documentation. Devices without a screen lock cannot enroll or use credentials at all.

Error Message: Passkeys not offered#

• Cause: The Android device does not have screen lock activated. Android requires a PIN, pattern, password or biometric lock to gate access to the credential, so without a lock the option is hidden.
• Solution: Enable screen lock under Settings > Security on the device, then retry. On older Android builds, also confirm Google Play services is up to date.

10. Generic WebAuthn and Browser Errors#

These errors come straight from the browser or the WebAuthn layer. They are intentionally generic to protect user privacy. Browsers expose between 10 and 14 distinct DOM exceptions during a ceremony per the W3C spec, and the most common one (NotAllowedError) covers cancel, timeout and silent platform refusal in a single bucket.

Error Message: Couldn't create your passkey / Error while creating Passkey / Error while generating passkey#

• Cause: A glitch in the relying party's app, a temporary server issue or incompatible device settings (e.g. an old OS without WebAuthn support).
• Solution: Restart the app or device and retry. If the problem persists, update the operating system and the browser. If only one relying party is affected, the issue is server-side and a retry after a few minutes usually resolves it.

Error Message: Passkeys not available on this device or browser#

• Cause: The browser or operating system does not support WebAuthn or the relying party (e.g. PayPal) blocks the current combination. Common examples are old browser builds, niche browsers without WebAuthn support or enterprise-managed devices with restrictive policies.
• Solution: Update the browser and the OS. If the device is fundamentally incompatible, switch to a supported one (Safari on iOS 16+, Chrome on Android 9+, Edge or Chrome on Windows 10+).

Error Message: Something went wrong. There was a problem signing in with your passkey.#

• Cause: Wrong credential selected, a temporary network glitch between the device and the server or a malfunction in the WebAuthn layer of the browser.
• Solution: Confirm that the right credential was picked from the prompt. Retry after a short wait. If the problem persists, check the network and reset the credential by re-enrolling from the account settings.

Error Message: Something went wrong. The request timed out.#

• Cause: The server took too long to respond, usually due to network instability or high load. The default WebAuthn timeout in Chrome is 60 seconds, with a maximum of 600 seconds defined by the W3C spec.
• Solution: Retry on a stable connection. If the connection is fine, the issue is server-side and a retry after a few minutes usually clears it. Relying parties can raise the timeout up to the W3C limit if their backend regularly overshoots the default.

Error Message: NotAllowedError. The operation either timed out or was not allowed#

• Cause: The generic WebAuthn error returned by browsers when a ceremony does not complete. It can mean user cancellation, a timeout, a blocked origin, a missing user gesture or a platform authenticator that refused the request. The browser hides the precise cause for privacy reasons.
• Solution: Increase the WebAuthn timeout on the relying party side and make sure the call is triggered by a direct user action like a button click. Verify that the relying party ID matches the origin, that the user has a usable authenticator and that no browser extension is intercepting the call. End users can usually fix it by unlocking the device, confirming the biometric or PIN prompt and retrying.

11. Conclusion#

Passkeys remove the password class of vulnerabilities by replacing shared secrets with public key cryptography. Real-world deployments report a 4x to 6x faster sign-in versus password plus OTP, with Verizon's 2024 Data Breach Investigations Report attributing 68% of breaches to a non-malicious human element including credential abuse. Cutting that surface area is the entire point.

In practice, the 15 errors above account for the bulk of consumer support tickets we see in the passkeys community, and getting troubleshooting right is essential for wider passkey adoption. Following creation best practices and login best practices reduces error rates significantly. To stay current on error handling and rollout details, subscribe to the passkeys Substack or join the community on Slack.

About Corbado

Corbado is the Passkey Intelligence Platform for CIAM teams running consumer authentication at scale. We help you see what IDP logs and generic analytics tools can't: which devices, OS versions, browsers and credential managers support passkeys, why enrollments don't turn into logins, where the WebAuthn flow fails and when an OS / browser update silently breaks login, all without replacing Okta, Auth0, Ping, Cognito or your in-house IDP. Two products: Corbado Observe layers observability for passkeys and any other login method. Corbado Connect adds managed passkeys with analytics built in (alongside your IDP). VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

Why am I being asked to insert a security key instead of using my passkey?#

This prompt appears when Windows Hello is disabled or no TPM is available, causing the system to fall back to hardware security key authentication. Enabling Windows Hello in your device's sign-in settings resolves this, but you must first create a Windows Hello passkey before using it for login.

How do I fix a 'couldn't create your passkey' error?#

This error typically results from an application glitch, a temporary server issue or incompatible device settings. Restarting the application or device and checking for OS and app updates usually resolves it. If the problem appears server-side, waiting and retrying later is recommended.

Why does passkey authentication keep timing out?#

Timeout errors occur when the server takes too long to respond, usually due to network instability or high server load. Verifying your internet connection is the first step. If connectivity is stable, the issue is likely server-side and retrying after a short wait should resolve it.

What happens if I delete my passkey on my device but not in the account settings?#

Deleting a passkey client-side, such as from iCloud Keychain or Google Password Manager, without also removing it in the relying party's account settings causes 'no matching passkey' errors. The server still holds the public key and expects the credential, so both client-side and server-side deletion are required before registering a new passkey.

What does NotAllowedError mean when using a passkey?#

NotAllowedError is the generic WebAuthn error browsers return when a passkey ceremony did not complete. It can mean user cancellation, timeout, a missing user gesture, a blocked origin or a platform authenticator that refused the request. Browsers hide the exact cause for privacy reasons. Retrying the flow after a direct user action and confirming biometrics or PIN usually resolves it.

Why does iOS show 'There are no matching passkeys saved in Passwords'?#

On iOS 18 and later the storage location moved into the new Passwords app, so the wording changed from "iCloud Keychain" to "Passwords". The error means the credential is missing on this device or iCloud sync is not active. Confirm iCloud Keychain is enabled on every Apple device used by the same Apple ID, force a sync by toggling iCloud Keychain off and on, then retry the sign-in. If no credential exists at all, register a new one from the relying party's account settings.

Why does Android show 'No available sign-in for relying party'?#

The Android Credential Manager surfaces this prompt when no matching credential is stored for the requested relying party on the current device. It typically offers a "Show QR code" option to use a passkey from another device via the FIDO hybrid transport, plus a fallback to open Google Password Manager. Either scan the QR code with a phone that already holds the credential, sign in with a fallback method, or register a new credential on the current device from the relying party's account settings.

How does the cross-device passkey QR code flow work?#

The cross-device flow is the FIDO hybrid transport defined in CTAP 2.2. The desktop browser shows a QR code containing a one-time secret. A phone scans it with the camera and then connects back over Bluetooth Low Energy at a maximum range of about 3 meters. After the user verifies on the phone, the WebAuthn ceremony completes on the desktop. Both Bluetooth and proximity are required, otherwise the flow fails silently with generic "Something went wrong" or "We couldn't sign you in" messages.