Why passkeys exposed a CIAM blind spot
Authentication process mining is the idea of applying process-mining techniques to login journeys, using per-session event logs to reconstruct what users actually did instead of what the auth flow was supposed to do.
That matters now because passkeys moved critical parts of authentication to the client. Traditional IDP logs can tell you attempt, success, and failure. They usually cannot tell you whether Conditional UI fired, whether the browser showed a biometric prompt, which credential manager was selected, or whether the user silently abandoned before any assertion hit the backend.
This is why many teams think their rollout is healthy when it is not. A 92% aggregate success rate can still hide a 40% abandonment rate on the passkey path alone. Averaged metrics flatten the journey. Process mining rebuilds it.
Authentication observability is the prerequisite
A lot of teams want passkey analytics, but they still lack the event model required to make it real. Authentication process mining only works after you have client-side observability in place.
At minimum, the event model needs to capture:
- initiation type: text-field, one-tap, or Conditional UI
- client-side ceremony events: page load, prompt display, biometric interaction, assertion return
- richer outcomes than success/failure: explicit abort, implicit abort, no-start, not-loaded, suppressed flows
- environment data: OS, browser, device brand, app, authenticator, transport
- credential inventory context: Apple, Google Password Manager, iCloud Keychain, Windows Hello, security keys, and others
Without that, you do not have process-mining event logs. You have outcome counters.
The practical shift is important: authentication observability asks “what happened?” Authentication process mining asks “which path did this session take, where did it diverge, and what should we change next?”
The designed login journey is rarely the lived one
The most useful insight in the article is not theoretical. In observed deployments, only about 30% of eligible users follow the designed passkey happy path.
That means the majority of sessions drift somewhere else: password fallback, social login, magic links, dismissals, retries, or silent exits. Once you reconstruct the per-session graph, you can rank those variants instead of guessing.
A simple comparison looks like this:
| View | What it tells you | What it misses |
|---|---|---|
| IDP outcome logs | success/failure by method | pre-assertion friction, abandonment cause, UI behavior |
| Passkey analytics dashboard | adoption and conversion trends | exact deviation paths per session |
| Authentication process mining | lived journey variants and deviation frequency | requires front-end instrumentation first |
Another useful pattern: the top five deviation variants typically account for 85% of all deviations. That is why fixing two broken variants often moves passkey adoption more than another A/B test on the happy path.
Why this changes step-up authentication
This gets more interesting when you connect login journey analytics to risk.
A lot of step-up authentication still works like a blunt threshold rule: if transaction value is high, trigger OTP. The article frames the tradeoff clearly: teams often add friction to 95% of legitimate traffic to catch the 5% that looks suspicious.
With authentication process mining, the decision can become session-specific instead of rule-only. Signals can include:
- deviation from the user’s normal path
- cohort baseline success rate
- time-of-day anomalies
- device reputation
- IP reputation
- credential manager identity
That is the bridge from CIAM observability to step-up authentication risk scoring. You stop treating every high-value action the same and start using the session’s actual path as a risk input.
Why IDPs are unlikely to solve this natively
The article makes a useful distinction: IDPs own the control plane, while authentication process mining is a data-plane problem.
That sounds subtle, but it has real architectural consequences. Orchestration products in Okta, Ping, ForgeRock, and Auth0 are good at defining policy and journey logic. They are not built to normalize high-cardinality front-end telemetry across browsers, operating systems, authenticators, and credential managers.
That is why terms like cohort drift detection, credential manager selection, and variant analysis are becoming first-class concerns for CIAM teams. Browser updates and OS rollouts change behavior silently. Aggregate success rate often catches that too late.
The near-term takeaway is simple: if you care about passkey rollout KPIs, start by measuring happy-path share and the top deviation variants on the passkey path. That is usually where the real leverage is.
Read the full breakdown](https://www.corbado.com/blog/authentication-process-mining).
Top comments (0)