Authentication Process Mining: Next CIAM Discipline

1. Introduction#

Passkeys are pushing CIAM forward. Best-in-class teams are starting to instrument the login journey end-to-end, classify errors they had never logged before and look at client-side telemetry for the first time. The vast majority of identity teams is not there yet: there is no real authentication observability layer, no per-session event graph, no client-side ceremony data. Server-side attempt, success and failure are still the whole picture.

Authentication process mining is the next logical step but only once that underlying event data exists. Without the observability layer, there is nothing to mine. With it, a new discipline becomes available. It borrows directly from business process mining, which turned raw ERP event logs into optimized workflows in the 2010s. Applied to identity, it compares the designed login journey against the lived journey, surfaces deviation paths and then closes the gap with fine-grained step-up authentication, suppression rules or UX changes that are measured end-to-end.

This article reframes what CIAM teams should be building on top of the authentication observability layer.

1.1 Questions this Article answers#

In this article, we deal with the following questions:

1. What did process mining do for BPM, and what is the direct parallel for authentication?
2. Why did passkey rollouts surface this gap, and why were authentication logs never enough on their own?
3. What does an authentication process-mining event model actually look like end-to-end?
4. How does process mining connect to fine-grained step-up authentication and authorization?
5. What does this mean for the CIAM vendor landscape and for identity teams that already own an IDP?

2. What Process Mining did for BPM#

2.1 From Event Logs to optimized Processes#

Business process mining emerged from the realization that every ERP, CRM or ticketing system writes event logs which, when reconstructed, reveal the actual workflow, not the one on the wiki. A purchase order that was supposed to pass through three approvers turned out to be routed around two of them 40% of the time. A claims flow that was documented as a straight line looped back on itself five times for 18% of claims. Process-mining tools like the ones popularized by Celonis rebuilt those graphs from timestamped events and let operators ask a new question: where does the lived process diverge from the designed process, and what does that divergence cost?

2.2 Parallel in Authentication#

Authentication has the same structure. Every login is a timestamped sequence of events: page loaded, identifier entered, challenge selected, biometric prompted, assertion returned. The structural parallel is exact. The practical difference is that, unlike ERP or CRM, this event data does not yet live in your IDP logs - at least not in the granular form process mining needs. IDPs record sign-in outcomes and the method used. They do not record the client-side ceremony underneath: Conditional UI invocation, biometric prompts, credential manager selection, silent abandonment before a request ever reaches the server. That pre-assertion layer has to be instrumented at the front-end SDK layer and reassembled into a per-session graph before process mining can operate on it.

Once the data is there, the same techniques apply: designed passkey journey vs. lived passkey journey, designed recovery flow vs. lived recovery flow, designed step-up vs. lived step-up. The academic discipline around this work is maturing. A useful entry point is the Process Mining Manifesto from the IEEE Task Force on Process Mining, which lays out conformance checking, variant analysis and enhancement as the three core techniques. Each maps one-to-one onto authentication.

3. Why Passkey Rollouts surfaced the Gap#

3.1 Passkeys force Teams to rethink Frontend Logging#

Classical password auth logged three things server-side: attempt, success, failure. That is enough to run a password system, because the failure mode is simple: the user mistyped a string, and the next attempt either worked or did not. With passkeys, the critical moments move to the frontend: Conditional UI firing, the browser deciding whether to surface a prompt, the credential manager offering a choice, the biometric challenge succeeding or being dismissed. All of this happens on the consumer's device, before the assertion ever reaches the backend.

That shift is why many teams are now rethinking how they log client-side behavior. Without frontend instrumentation, they cannot see why users are churning, what steps users take before login, or what actually happened when a login attempt did not complete. Server logs only show absence, not cause. See our deep dive on authentication observability for the full event taxonomy.

3.2 Gap between designed Journey and lived Journey#

Once teams had client-side events, they could see something new: the designed passkey journey (land on login, see passkey button, tap, authenticate, done) was used by perhaps 30% of eligible users. The other 70% drifted sideways through password fields, social login, magic links or abandoned entirely. That is a process-mining problem, not a logging problem. No amount of additional WebAuthn error codes would have closed the gap on its own.

3.3 Why Authentication Logs were never enough#

Authentication logs on their own tell you outcomes. They do not tell you paths. A 92% login success rate across all methods can hide a 40% abandonment rate on the passkey path and a 15% abandonment rate on the password path, netting out as "fine." Process mining refuses that averaging. It insists on looking at each variant separately and then ranking variants by frequency, cost and failure rate.

4. What Authentication Process Mining actually looks like#

4.1 Event Model: Processes, Events and Outcome Classification#

The unit of analysis is not a single event, it is a process: one full login or credential-append attempt on the consumer's device, from the moment the auth surface loads to the moment the session either completes or abandons. Each process contains a stream of fine-grained events, carries identifying metadata and ends in an outcome classification that is richer than the binary "success or failure."

Process metadata. Every process has a process ID and a timestamp. It is tied to an application, an OS, a browser and a device brand. It is tagged with a visitor category (real user, manual tester, automated tester, not yet classified) so that automation and bot traffic can be segmented out before any metric is computed. It also carries a process score and an event count, which are the two simplest signals for "how complex was this particular session."

Login initiation. Every process records how the flow was started. The main initiation types are text-field (the user typed their identifier), one-tap (a stored identifier was reused) and cui (Conditional UI surfaced a credential without an explicit button click). Initiation is a dimension, not a metric: the same deployment can look very different on the cui cohort than on the text-field cohort, and averaging across them hides exactly the behavior process mining is meant to reveal.

Outcome classification. Instead of "success" or "failure," the outcome is one of several classes that map to a distinct behavior. An example for passkeys is the following:

• completed - the ceremony finished and the user is authenticated.
• filtered-explicit-abort - the user saw a prompt and explicitly canceled.
• filtered-implicit-abort - the user walked away or timed out without deciding.
• filtered-passkey-intel - the client-side intelligence layer suppressed the passkey path on purpose, typically because the device/OS combination is known to be broken.
• filtered-no-start - the flow never progressed past the entry step.
• not-loaded - the auth surface never finished loading.

The append ceremony (credential creation) has a parallel classification, including an completed-exclude-credentials case for when a user already has a credential.

Funnel and inventory layers. On top of processes, two aggregate layers matter. A funnel layer buckets processes over time by outcome, initiation, completion status, OS and application, for both login and append. A credential inventory layer groups the existing passkeys by sync status (synced vs. not synced), transport (internal, hybrid, usb, nfc, ble, smart-card), authenticator (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), OS and browser. Without the inventory layer it is impossible to ask whether a given deviation variant is concentrated on a specific credential manager or sync state.

This is the minimum shape that makes process mining tractable. Each event carries enough metadata to be grouped, filtered and ranked. Each process can be traced individually, which is what enables the worked examples below.

4.2 Happy Path vs. Deviation Analysis#

Once events are stored as a directed graph per session, you can ask the process-mining question: what percentage of sessions follow the happy path, and for the ones that do not, what are the top five deviation variants ranked by frequency? In our analytics data, the top five variants typically account for 85% of all deviations. Fixing two of them usually moves the numbers more than any A/B test on the happy path.

4.3 Cohort Drift Detection#

Variants drift. A browser update, an OS rollout, a credential manager change can make a previously minor variant suddenly dominant. Cohort drift detection is the discipline of watching variant distribution per device/OS/browser cohort over time, instead of looking only at aggregate success rate. This is how teams catch silent regressions in hours rather than quarters.

5. From Process Mining to fine-grained Step-up#

5.1 Why Step-up has been under-used#

Step-up authentication has existed for over a decade. It has been under-used because most teams step up the same way regardless of risk: force an OTP on every transaction above a threshold. That is a blunt rule, not a risk-scored decision. It creates friction on 95% of legitimate high-value transactions to stop the 5% that are suspicious.

5.2 Risk-scored Journeys#

With process-mining data, you can score a session continuously. Device reputation, cohort baseline success rate, time-of-day anomalies, deviation from the user's own historical path, credential manager identity, IP reputation. The risk score then drives a fine-grained step-up decision: require a second factor only when the session's risk score exceeds the transaction value threshold. Low-risk sessions for high-value transactions go through. High-risk sessions for low-value transactions get stepped up.

6. What this means for the CIAM Vendor Landscape#

6.1 Journey Design as a Specialist Discipline#

The identity industry has historically bundled journey design inside the IDP. Orchestration engines inside Okta, Ping, ForgeRock, Auth0 and others let you configure flows. What they do not do well is observe them. That mismatch is what opens space for a specialist analytics layer.

6.2 Why no IDP will ship this natively#

IDP vendors optimize for the control plane: who can sign in, with what credential, under what policy. Process mining is a data-plane discipline: every event, at scale, normalized across OS/browser/credential-manager combinations. The event volume, the cardinality and the cross-customer baselines all work against a native IDP build. See the field notes in our buy-vs-build guide for passkeys for the same pattern applied to the SDK layer.

6.3 Analytics Layer as the new Category#

What emerges is a thin analytics and adoption layer that sits above the IDP, ingests events from the front-end, normalizes them against cross-deployment baselines and feeds back into orchestration decisions. It does not replace the IDP. It makes the IDP measurable.

7. How Corbado helps with Authentication Process Mining#

Corbado provides the measurement and adoption layer that sits above existing IDPs. It integrates with Okta, Auth0, Ory, ForgeRock and custom stacks without replacing them. What it adds is specifically the process-mining capability:

• End-to-end Event Taxonomy. The client-side SDK captures the full ceremony from page load to assertion, including pre-identifier events, Conditional UI invocation and credential manager selection.
• Variant Analysis out of the Box. The platform reconstructs journey graphs per cohort and ranks deviation variants by frequency, recovery opportunity and cost.
• Cohort Drift Alerting. When a variant distribution shifts for a specific OS, browser or credential manager, the platform flags it before it becomes a day-2 problem.
• Cross-deployment Baselines. Because Corbado aggregates anonymized data across customer environments, new errors or regressions surfaced in one deployment are classified and documented before they reach yours. See why Corbado for the full approach.
• Feedback into Orchestration. Risk-scored step-up decisions and suppression rules can be pushed back into the IDP or handled at the adoption layer, including dynamic kill-switches and cohort-specific nudging.

8. Conclusion#

Passkeys were not the destination. They were the instrumentation wedge that is forcing the first wave of CIAM teams to log client-side events at all. Once that observability layer exists, a new discipline sits on top of it: authentication process mining. It is how identity teams move from "did the login succeed" to "which variant of the journey did this user take, what did it cost and how should the next session be routed differently." Teams that build the observability layer first, and the process-mining layer immediately after, will set the benchmark for the category. Teams that stay on aggregate success rates will keep missing the systemic variants underneath.

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 →

FAQ#

What is Authentication Process Mining?#

Authentication process mining is the application of business process-mining techniques to login event logs. It reconstructs the directed graph of events per session, compares the lived authentication journey against the designed journey and ranks deviation variants by frequency and cost. It sits above authentication observability and below orchestration.

How is it different from Authentication Analytics?#

Authentication analytics report metrics such as login success rate, drop-off rate and passkey usage rate. Process mining goes further by reconstructing the full event sequence per session and asking which variants of the journey exist, how often each occurs and where each diverges from the designed happy path. Analytics report outcomes. Process mining explains paths.

Why does Passkey Adoption make this Discipline necessary?#

Passkey rollouts are the first reason CIAM teams are instrumenting client-side events at all. Once those events exist, aggregate metrics hide too much: a 92% success rate can mask a 40% abandonment rate on the passkey path. Process mining refuses that averaging and forces teams to look at variants separately.

How does Process Mining connect to Step-up Authentication?#

Step-up authentication works best when it is risk-scored rather than rule-based. Process mining provides the session-level evidence (cohort baseline, deviation from user's historical path, device reputation) that lets a step-up engine make a fine-grained decision rather than a blunt threshold decision.

Will my IDP ship this natively?#

Unlikely in the near term. IDPs optimize for the control plane. Process mining is a data-plane discipline with high event volume and high cardinality across OS, browser and credential-manager combinations. The pattern matches what we see in the SDK layer today, covered in our buy-vs-build guide.

What is the first Thing a CIAM Team should measure?#

Start with variant frequency on the passkey path: what percentage of sessions follow the happy path, and what are the top five deviation variants ranked by frequency? That single chart is usually enough to reveal the two or three fixes that move overall passkey adoption the most.