> ## Documentation Index > Fetch the complete documentation index at: https://docs.corbado.com/llms.txt > Use this file to discover all available pages before exploring further. # Passkey Intelligence for Support > How Corbado Observe looks back at one user's devices, passkeys and attempts and turns a failed passkey creation or login into a cause and a next step for the support agent. When a user calls with "I cannot log in", the support agent gets two plain sentences: **what happened** and **what the user can do now**. Observe finds them by looking back at everything it recorded for that user and comparing the failed attempt with the user's devices, passkeys and other attempts. The support diagnosis is in early access. Contact your Corbado team to enable it for your project.

Timeline of one user on an iPhone: passkey created in Safari, passkey login in Safari succeeded, passkey login in the Google app rejected instantly, password login in the Google app succeeded. Observe compares device and browser, the passkeys and where they live, and earlier attempts. The answer for the support agent says: The passkey prompt was blocked inside the Google app. The same passkey works in Safari on this phone. Next step: Open the page in Safari or sign in with the password. The answer type is Explain and redirect.

## 1. One knowledge base, two directions Passkey Intelligence in Observe answers two questions with the same knowledge about how passkeys behave on real devices: | | Support diagnosis | [Prevent failed logins](/corbado-observe/passkey-intelligence/prevent-failed-logins) | | - | - | - | | **Direction** | Looks back at attempts that already happened | Looks ahead before the passkey prompt opens | | **Question** | Why did the passkey creation or login fail for this user? | Will a passkey login work on this device? | | **Reader** | Support agent, identity team | Your identity provider, during the login | | **Output** | Cause, next step and answer type | Route: passkey on this device, phone, try once or fallback | Both directions explain the same failures. A passkey that lives on another device, a credential manager that this browser cannot reach or an in-app browser that blocks the prompt is a cause after the fact and a prediction before the next attempt. Every case the diagnosis explains makes the prediction better, and the other way round. ## 2. Why passkey failures are hard to explain A passkey login touches far more than your server. Whether it works depends on the combination of: * **Device and OS:** iPhone, Android, Windows or Mac, each with its own version history and passkey support. * **Browser:** Safari, Chrome, Edge, Firefox, Samsung Internet and in-app browsers inside apps such as Google, Instagram or Facebook. * **Credential manager:** iCloud Keychain, Google Password Manager, Samsung Pass, Windows Hello, Microsoft Password Manager or third-party managers such as 1Password or Bitwarden. * **Where the passkey lives:** created on this device, synced from another device of the same account or only reachable through a phone via QR code. * **Cross-device capability:** whether this device can show a QR code and reach a phone at all. * **User behaviour:** a closed prompt, an ignored automatic offer, a second account on a shared device. These dimensions multiply into thousands of combinations. The browser reports most of the resulting failures with the same generic error, and many of them never reach your server. In illustrative analyses, **51% to 76%** of classified login errors happened in the browser or on the device. Server logs, the identity provider and web analytics do not see them. _{Source: Corbado Aggregate Intelligence, informed by deployments of Corbado Observe and Connect. Figures illustrate the share of classified login error occurrences on the device or in the frontend; results vary by login method mix.} ## 3. How the diagnosis works The diagnosis runs on the data Observe already records. Your integration sends no additional events. Observe gathers everything it knows about the user: devices and browsers, passkeys with where they were created and used, every passkey creation and login attempt with its errors and the other methods the user tried. Failed attempts before the user typed an identifier are included once the user signs in on that device. [Users and identifiers](/corbado-observe/overview/users-and-identifiers) explains how these attempts link to the user. The diagnosis picks the user's last passkey action that the user experienced as a failure. Silent background checks that the user never saw are skipped. It compares the failed attempt with the user's other attempts, devices and passkeys, for example the same passkey working in another browser on the same phone, or a device-bound passkey created with Windows Hello on a Windows PC and now tried on an iPhone. The comparison runs against the Corbado Aggregate Intelligence model, built from over 100 million observed and managed passkey authentications, which ranks the cause groups for every combination of device, browser and credential manager. Exactly one cause wins, so the agent never gets a list of guesses. If no cause fits, the diagnosis says so instead of guessing. Observe checks whether the user still got through, with a later passkey attempt or another method. The answer then reassures and says what to do next time. The result is two plain sentences without error codes or technical terms, plus the answer type. The signals behind the answer stay available for level 2 and 3 support. ### Cause groups The diagnosis covers passkey creation and passkey login. The groups below are examples. Corbado extends the set for each Observe deployment based on the failure patterns in its own data. | Cause group | Example | Typical next step | | - | - | - | | **Passkey on another device** | The passkey is device-bound, created with Windows Hello on a Windows PC, and the user is on an iPhone | Use the PC that holds the passkey or the fallback | | **Credential manager not reachable here** | A Google Password Manager passkey in Safari on an iPhone | Use Chrome on this phone or sign in with the password | | **In-app browser** | The login page was opened inside the Google app | Open the page in Safari or Chrome | | **Cross-device sign-in not possible** | The QR code route is unavailable on this computer | Sign in on the phone or use the fallback | | **Prompt closed or offer ignored** | The user closed the passkey prompt or skipped an automatic offer | Nothing is broken, sign in as usual | | **Account switch on a shared device** | A second account on the same device offered the wrong passkey | Choose the right account in the prompt | | **Passkey already exists** | The user tried to create a passkey this device already holds | Sign in with the existing passkey | | **Device without passkey support** | The OS or browser version is too old | Update the device or use the fallback | | **Server-side step failed** | The passkey worked, a later step of the login failed | Escalate with the evidence | ### Answer types Each cause maps to one of four answer types, so the agent knows how to handle the call: | Answer type | What the agent does | Example sentence | | - | - | - | | **Fix now** | Solves it during the call | "Please sign in with the passkey you already have on this phone." | | **Explain and redirect** | Explains the cause and sends the user to a working path | "Your passkey is saved in Google Password Manager. Please use Chrome on this phone or your password." | | **Escalate with evidence** | Hands over to the identity team with the attempt attached | "This is a known issue on our side. Please use your password for now." | | **Reassure** | Confirms that nothing is broken | "You closed the passkey prompt, so please sign in as usual." | You can adapt the sentences to your own support wording and your fallback methods. ## 4. Where agents get the answer Search by user ID or by the identifier the user typed. Devices, passkeys and every attempt in one view. A link from your service desk tool opens the user view with the user ID filled in. In development. User ID in, plain-language cause and next step out, inside the tool agents already use. In development. The same data feeds the error ranking in [Findings](https://app.corbado.com/observe/analytics/findings). Users who give up without calling still count there, so a fix reaches them too. ## Next steps Use the same knowledge before the prompt opens and route users to the path that works. How Observe links attempts to a user and how agents find a user by a typed identifier. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.