Passkeys tend to look "done" when you can complete a WebAuthn ceremony and your IdP logs show green checkmarks. In CIAM, that's a trap. The FIDO Alliance Passkey Index (2025) reports passkey sign-ins achieve a 93% success rate vs. 63% for passwords and SMS OTP, yet many real-world rollouts still see a passkey adoption rate stuck around 5% to 15%. The gap is usually not your backend. It's the user's device, browser, OS UI, and credential manager.
What "Authentication Observability for CIAM" actually means
Authentication Observability for CIAM is about seeing the full consumer login journey, including everything that happens on the client before your server receives a request. That matters because over 80% of passkey failures can happen on the consumer's device before any request reaches the backend, so IdP logs literally cannot explain them.
Client-side WebAuthn telemetry should capture more than "success" or "error." You want to know:
- How the ceremony started (Conditional UI autofill, a passkey button, or manual identifier entry)
- Whether the device was even capable
- Which credential manager took over (iCloud Keychain, Google Password Manager, Windows Hello, Samsung Pass, browser extension)
- What happened at biometrics (success, timeout, cancel)
- Which specific WebAuthn error code ended the attempt
The CIAM-specific blind spot: pre-identifier abandonment
Workforce IAM assumes the user exists before login. CIAM does not. If a consumer lands on your login page, gets confused by a native prompt, or an extension overlays the UI, then bounces before typing an email, your backend has nothing. That "pre-identifier blindness" is where funnel leakage hides.
This is why passkey analytics cannot start at /token or /authorize. It has to start at page load or app screen render, with a silent capability probe that determines whether passkeys and Conditional UI are available before you show any UI. Without that, you can't tell the difference between "users don't want passkeys" and "eligible users never saw a usable passkey entry point."
The KPIs that matter: activation and usage (not just success)
A passkey dashboard that only tracks Login Success Rate (LSR) misses the point. You need two adoption KPIs that map to behavior change.
Passkey activation rate is the share of eligible users (devices that support passkeys) who actually create one when prompted. In practice, you can't compute this reliably from backend logs or generic product analytics because those tools don't know eligibility. Client-side probes make eligibility measurable, so activation becomes a real denominator, not a guess.
Passkey usage rate is the share of daily logins that happen with passkeys, not just "has a passkey." Lots of users enroll once and still type passwords out of habit, or because autofill is buried, or because Conditional UI doesn't render due to CSS or custom inputs.
Why GA4 and generic analytics break on passkey debugging
You can push custom events into GA4 or Mixpanel, but passkey performance depends on high-cardinality combinations: OS version, browser version, credential manager, device model, authenticator type, and cross-device login method. GA4 high-cardinality passkey data quickly collapses into (other) once you exceed the platform's practical limits, which is exactly where the long tail of passkey bugs lives.
Also, the most important states are native WebAuthn and credential-manager states that generic analytics does not model:
- Whether Conditional UI tracking fired but wasn't selected
- Whether a user attempted Cross-Device Authentication (QR + Bluetooth)
- Whether the platform authenticator was detected
- Whether the request got intercepted by an extension
WebAuthn error code diagnostics that lead to actions
If you only store "NotAllowedError happened," you still need interpretation. In production, WebAuthn error code diagnostics should map to a concrete response:
-
NotAllowedError— Often user cancel or timeout. Treat spikes as a UX messaging and retry problem, not a server outage. -
NotSupportedError— A capability or environment issue. Suppress passkey UI and route to a fallback. -
SecurityError— Often points to HTTPS, RP ID, or domain configuration issues that require immediate investigation. -
UnknownError— Can indicate credential-manager crashes or extension interference. Segmenting by browser + extension presence becomes critical.
The key developer takeaway: error codes become valuable only when they are enriched with client context and segmented into cohorts. Otherwise you'll waste weeks debating whether you have a "passkey problem" or a "Samsung Pass on a specific Galaxy + One UI version" problem.
Conditional UI is a silent failure point (and you need telemetry for it)
Conditional UI often runs invisibly in the background. If the user doesn't select the passkey from the autofill dropdown, your backend never learns that Conditional UI was invoked. That means you can have "passkeys are supported" and "Conditional UI is firing" while usage stays low because the dropdown is suppressed by styling, rendered below the fold, or visually crowded by password manager overlays.
Instrumentation should record invocation and selection separately. If invocation is high and selection is low, the fix is almost always UI, layout, or input styling — not cryptography.
Rollout safety: a CIAM passkey kill switch is not optional
CIAM environments include unmanaged devices, old OS builds, regional Android OEM skins, and multiple password managers. So you need a CIAM passkey rollout kill switch that can suppress passkey prompts for known-bad device and OS cohorts and route users to a stable fallback before they hit a broken native modal.
This is not about giving up on passkeys. It's about protecting conversion and support costs while you isolate systemic breakage. The same telemetry that identifies broken cohorts also identifies high-confidence cohorts (for example, a specific macOS + Safari segment) where you can be more aggressive with prompting.
Nudging based on cohorts, not gut feeling
Once you can segment by device capability and actual funnel behavior, you can nudge the right people at the right time. A recurring high-conversion moment is "after pain" — immediately after a password reset, when user motivation is high. Observability lets you prove whether this increases passkey activation rate in your own traffic, and whether the effect holds by cohort.
Likewise, usage rate improvements often come from initiation UX. If users with an existing passkey still type into fields, you likely need a more prominent passkey entry point, better autofill positioning, or better cross-device instructions when QR + Bluetooth completion is dropping.
Build vs. buy: the hidden maintenance cost is taxonomy drift
A lot of teams start by wrapping WebAuthn calls and sending events to an internal pipeline. The hard part is keeping the taxonomy correct across browser releases, OS updates, new WebAuthn error behaviors, and a growing list of credential managers and extensions. You also need to fix issues quickly, ideally via config, not a full frontend deployment cycle.
Corbado is a passkey observability and adoption platform for large B2C enterprises.
What to take away
If your passkey adoption rate is stuck in single digits, don't assume "users hate passkeys." Measure passkey activation rate and passkey usage rate with client-side WebAuthn telemetry, add Conditional UI tracking, make GA4 high-cardinality limitations explicit in your strategy, and implement a kill switch so broken cohorts don't poison your rollout.
Find out more on corbado.com/blog/authentication-observability
Top comments (0)