--- url: 'https://www.corbado.com/de/blog/authentication-process-mining' title: 'Authentifizierungs-Process-Mining: Die nächste CIAM-Disziplin' description: 'Authentifizierungs-Process-Mining verwandelt Passkey-Ereignisprotokolle in optimierte Login-Journeys. Erfahren Sie mehr über diese CIAM-Observability-Disziplin.' lang: 'de' author: 'Vincent Delitz' date: '2026-05-19T14:50:54.198Z' lastModified: '2026-05-20T06:01:52.710Z' keywords: 'Authentifizierungs-Process-Mining, User Journey Authentifizierung, CIAM Observability, Step-up Authentifizierung, Auth Journey Optimierung' category: 'Passkeys Strategy' --- # Authentifizierungs-Process-Mining: Die nächste CIAM-Disziplin ## Key Facts - **Authentifizierungs-Process-Mining** überträgt die **Ereignisprotokoll-Rekonstruktion** (bekannt durch **Celonis**), die von der **IEEE Task Force on Process Mining** in den **2010er** Jahren für **ERP**-Workflows formalisiert wurde, auf Passkey-Login-Vorgänge. - Es erfordert eine **clientseitige Observability-Schicht**. **IDP-Protokolle** erfassen serverseitig nur **Versuch**, **Erfolg** und **Fehlschlag** und übersehen **Conditional UI**, biometrische Aufforderungen, die Auswahl des **Passwortmanagers** sowie stille Abbrüche. - In beobachteten Implementierungen folgen nur etwa **30 %** der berechtigten Nutzer dem **vorgesehenen Passkey-Happy-Path**, und eine **Gesamterfolgsquote von 92 %** maskiert routinemäßig eine **Abbruchquote von 40 %** allein beim Passkey-Pfad. - Die **fünf häufigsten Abweichungsvarianten** machen typischerweise **85 %** aller Abweichungen aus. Gezielte Korrekturen steigern die Akzeptanz daher mehr als jeder A/B-Test auf dem Happy Path. - Das Ereignismodell benötigt **3 Initiierungstypen** (`text-field`, `one-tap`, `cui`), **6 Ergebnisklassen** und ein **Credential-Inventar**, das nach **Transport** und Authenticator segmentiert ist (**Apple**, **Google Password Manager**, **iCloud Keychain**, **Windows Hello**, **YubiKey**). - Process-Mining-Daten verwandeln **Step-up-Authentifizierung** von einer stumpfen OTP-Regel – Reibung bei **95 %** des legitimen Traffics, um **5 %** verdächtigen Traffic abzufangen – in eine kontinuierlich **risikobewertete Entscheidung**. - Kein **IDP** liefert dies nativ: **Okta**, **Ping**, **ForgeRock** und **Auth0** besitzen die **Control Plane**, während Process Mining eine **Data-Plane-Disziplin** ist. Dies macht **Variantenanalyse**, **Kohorten-Drift-Erkennung** und **Conformance Checking** bis **2027** für CIAM-Analytics-Teams obligatorisch. ## 1. Einführung Passkeys treiben CIAM voran. Best-in-Class-Teams beginnen damit, die Login-Journey End-to-End zu instrumentieren, Fehler zu klassifizieren, die sie zuvor nie protokolliert hatten, und schauen sich zum ersten Mal clientseitige Telemetrie an. Die überwiegende Mehrheit der Identity-Teams ist jedoch noch nicht so weit: Es gibt keine echte Authentifizierungs-Observability-Schicht, keinen sitzungsbezogenen Ereignisgraphen und keine clientseitigen Vorgangsdaten. Serverseitige Versuche, Erfolge und Fehlschläge stellen nach wie vor das Gesamtbild dar. Authentifizierungs-Process-Mining ist der nächste logische Schritt, allerdings erst, wenn diese grundlegenden Ereignisdaten existieren. Ohne die Observability-Schicht gibt es nichts zu analysieren ("minen"). Mit ihr wird eine neue Disziplin verfügbar. Sie lehnt sich direkt an das Business-Process-Mining an, das in den 2010er Jahren rohe ERP-Ereignisprotokolle in optimierte Workflows verwandelte. Auf das Identitätsmanagement angewendet, vergleicht es die konzipierte Login-Journey mit der tatsächlich erlebten Journey, deckt abweichende Pfade auf und schließt diese Lücke durch fein abgestimmte Step-up-Authentifizierung, Unterdrückungsregeln oder UX-Änderungen, die End-to-End gemessen werden. Dieser Artikel definiert neu, was CIAM-Teams auf der Authentifizierungs-Observability-Schicht aufbauen sollten. ### 1.1 Fragen, die dieser Artikel beantwortet In diesem Artikel behandeln wir folgende Fragen: 1. Was hat Process Mining für BPM geleistet, und was ist die direkte Parallele für die Authentifizierung? 2. Warum haben Passkey-Einführungen diese Lücke aufgezeigt, und warum waren Authentifizierungsprotokolle allein nie ausreichend? 3. Wie sieht ein Ereignismodell für Authentifizierungs-Process-Mining End-to-End tatsächlich aus? 4. Wie verbindet sich Process Mining mit feingranularer Step-up-Authentifizierung und Autorisierung? 5. Was bedeutet dies für die CIAM-Anbieterlandschaft und für Identity-Teams, die bereits einen IDP besitzen? ## 2. Was Process Mining für BPM geleistet hat ### 2.1 Von Ereignisprotokollen zu optimierten Prozessen Business-Process-Mining entstand aus der Erkenntnis, dass jedes ERP-, CRM- oder Ticketing-System Ereignisprotokolle schreibt, die bei einer Rekonstruktion den tatsächlichen Workflow offenlegen – nicht den, der im Wiki steht. Eine Bestellung, die eigentlich von drei Genehmigern geprüft werden sollte, umging in 40 % der Fälle zwei von ihnen. Ein Schadensfall-Ablauf, der als gerade Linie dokumentiert war, drehte sich bei 18 % der Fälle fünfmal im Kreis. Process-Mining-Tools, wie sie von Celonis populär gemacht wurden, rekonstruierten diese Graphen aus mit Zeitstempeln versehenen Ereignissen und ließen Betreiber eine neue Frage stellen: Wo weicht der erlebte Prozess vom konzipierten Prozess ab, und was kostet diese Abweichung? ### 2.2 Parallele in der Authentifizierung Authentifizierung hat die gleiche Struktur. Jeder Login ist eine mit Zeitstempeln versehene Abfolge von Ereignissen: Seite geladen, Kennung eingegeben, Challenge ausgewählt, [Biometrie](https://www.corbado.com/de/blog/biometrie-payer-awareness) angefordert, [Assertion](https://www.corbado.com/glossary/assertion) zurückgegeben. Die strukturelle Parallele ist exakt. Der praktische Unterschied besteht darin, dass diese Ereignisdaten – im Gegensatz zu ERP oder CRM – noch nicht in Ihren IDP-Protokollen liegen, zumindest nicht in der granularen Form, die Process Mining benötigt. IDPs protokollieren Anmeldeergebnisse und die verwendete Methode. Sie protokollieren nicht den clientseitigen Ablauf darunter: Aufrufe der [Conditional UI](https://www.corbado.com/glossary/conditional-ui), biometrische Aufforderungen, die Auswahl des Passwortmanagers oder stille Abbrüche, bevor eine Anfrage überhaupt den Server erreicht. Diese Schicht vor der [Assertion](https://www.corbado.com/glossary/assertion) muss auf der Frontend-SDK-Schicht instrumentiert und in einem sitzungsbezogenen Graphen neu zusammengesetzt werden, bevor Process Mining darauf angewendet werden kann. Sobald die Daten vorliegen, gelten die gleichen Techniken: konzipierte Passkey-Journey vs. erlebte Passkey-Journey, konzipierter Wiederherstellungsfluss vs. erlebter Wiederherstellungsfluss, konzipiertes Step-up vs. erlebtes Step-up. Die akademische Disziplin rund um diese Arbeit wird erwachsen. Ein nützlicher Einstiegspunkt ist das [Process Mining Manifesto](https://www.tf-pm.org/resources/manifesto) der IEEE Task Force on Process Mining, das Conformance Checking, Variantenanalyse und Erweiterung als die drei Kerntechniken festlegt. Jede davon lässt sich eins-zu-eins auf die Authentifizierung übertragen. ## 3. Warum Passkey-Einführungen die Lücke aufzeigten ### 3.1 Passkeys zwingen Teams dazu, Frontend-Protokollierung neu zu überdenken Klassische Passwort-Authentifizierung protokollierte serverseitig drei Dinge: Versuch, Erfolg, Fehlschlag. Das reicht aus, um ein Passwortsystem zu betreiben, da das Fehlermodell einfach ist: Der Nutzer hat eine Zeichenfolge falsch abgetippt, und der nächste Versuch funktionierte entweder oder nicht. Mit Passkeys verlagern sich die kritischen Momente ins Frontend: Das Auslösen der [Conditional UI](https://www.corbado.com/glossary/conditional-ui), die Entscheidung des Browsers, ob eine Aufforderung angezeigt wird, der Passwortmanager, der eine Auswahl anbietet, die biometrische Challenge, die erfolgreich ist oder abgewiesen wird. All dies geschieht auf dem Gerät des Verbrauchers, bevor die [Assertion](https://www.corbado.com/glossary/assertion) jemals das Backend erreicht. Diese Verschiebung ist der Grund, warum viele Teams nun darüber nachdenken, wie sie clientseitiges Verhalten protokollieren. Ohne Frontend-Instrumentierung können sie nicht sehen, warum Nutzer abspringen, welche Schritte Nutzer vor dem Login unternehmen oder was tatsächlich passiert ist, wenn ein Anmeldeversuch nicht abgeschlossen wurde. Serverprotokolle zeigen nur das Fehlen, nicht die Ursache. Sehen Sie sich unseren Deep-Dive zur Authentifizierungs-Observability für die vollständige Ereignistaxonomie an. ### 3.2 Lücke zwischen konzipierter und erlebter Journey Sobald Teams clientseitige Ereignisse hatten, konnten sie etwas Neues erkennen: Die konzipierte Passkey-Journey (auf dem Login landen, [Passkey-Button](https://www.corbado.com/de/blog/passkey-anmeldung-optimieren) sehen, tippen, authentifizieren, fertig) wurde von vielleicht 30 % der berechtigten Nutzer verwendet. Die restlichen 70 % wichen auf Passwortfelder, [Social Login](https://www.corbado.com/glossary/social-login) oder Magic Links aus oder brachen ganz ab. Das ist ein Process-Mining-Problem, kein Protokollierungsproblem. Keine Menge an zusätzlichen WebAuthn-Fehlercodes hätte diese Lücke allein geschlossen. ### 3.3 Warum Authentifizierungsprotokolle nie ausreichten Authentifizierungsprotokolle für sich genommen verraten Ihnen Ergebnisse. Sie zeigen Ihnen keine Pfade auf. Eine Login-Erfolgsquote von 92 % über alle Methoden hinweg kann eine Abbruchquote von 40 % auf dem Passkey-Pfad und 15 % auf dem Passwort-Pfad verbergen, was unterm Strich als "in Ordnung" erscheint. Process Mining weigert sich, diese Durchschnitte zu bilden. Es besteht darauf, jede Variante einzeln zu betrachten und diese dann nach Häufigkeit, Kosten und Ausfallrate zu ranken. ## 4. Wie Authentifizierungs-Process-Mining tatsächlich aussieht ### 4.1 Ereignismodell: Prozesse, Ereignisse und Ergebnisklassifizierung Die Analyseeinheit ist kein einzelnes Ereignis, sondern ein **Prozess**: Ein vollständiger Login- oder Credential-Hinzufügen-Versuch auf dem Gerät des Verbrauchers, vom Moment des Ladens der Auth-Oberfläche bis zum Moment, in dem die Sitzung entweder abgeschlossen oder abgebrochen wird. Jeder Prozess enthält einen Stream von feingranularen Ereignissen, trägt identifizierende Metadaten und endet in einer Ergebnisklassifizierung, die reichhaltiger ist als das binäre "Erfolg oder Fehlschlag". **Prozess-Metadaten.** Jeder Prozess hat eine Prozess-ID und einen Zeitstempel. Er ist mit einer Anwendung, einem Betriebssystem, einem Browser und einer Gerätemarke verknüpft. Er ist mit einer Besucherkategorie getaggt (echter Nutzer, manueller Tester, automatisierter Tester, noch nicht klassifiziert), sodass Automatisierung und Bot-Traffic herausgefiltert werden können, bevor eine Metrik berechnet wird. Er trägt außerdem einen Prozess-Score und eine Ereignisanzahl, die die beiden einfachsten Signale für "Wie komplex war diese spezielle Sitzung" darstellen. **Login-Initiierung.** Jeder Prozess zeichnet auf, wie der Ablauf gestartet wurde. Die Hauptinitiierungstypen sind `text-field` (der Nutzer hat seine Kennung abgetippt), `one-tap` (eine gespeicherte Kennung wurde wiederverwendet) und `cui` (Conditional UI zeigte ein Credential ohne expliziten Button-Klick an). Die Initiierung ist eine Dimension, keine Metrik: Die gleiche Implementierung kann bei der `cui`-Kohorte ganz anders aussehen als bei der `text-field`-Kohorte, und die Durchschnittsbildung über sie hinweg verbirgt genau das Verhalten, das Process Mining aufdecken soll. **Ergebnisklassifizierung.** Statt "Erfolg" oder "Fehlschlag" ist das Ergebnis eine von mehreren Klassen, die einem bestimmten Verhalten zugeordnet sind. Ein Beispiel für Passkeys ist das Folgende: - `completed` - Der Vorgang wurde abgeschlossen und der Nutzer ist authentifiziert. - `filtered-explicit-abort` - Der Nutzer sah eine Aufforderung und hat diese explizit abgebrochen. - `filtered-implicit-abort` - Der Nutzer ist weggegangen oder die Zeit ist ohne Entscheidung abgelaufen. - `filtered-passkey-intel` - Die clientseitige Intelligenzschicht hat den Passkey-Pfad absichtlich unterdrückt, typischerweise, weil die Geräte/Betriebssystem-Kombination als defekt bekannt ist. - `filtered-no-start` - Der Fluss ist nie über den Einstiegsschritt hinausgekommen. - `not-loaded` - Die Auth-Oberfläche wurde nie vollständig geladen. Der Hinzufügen-Vorgang (Credential-Erstellung) hat eine parallele Klassifizierung, einschließlich eines `completed-exclude-credentials`-Falls, wenn ein Nutzer bereits ein Credential besitzt. **Funnel- und Inventar-Schichten.** Aufbauend auf den Prozessen spielen zwei aggregierte Schichten eine Rolle. Eine **Funnel-Schicht** gruppiert Prozesse im Zeitverlauf nach Ergebnis, Initiierung, Abschlussstatus, Betriebssystem und Anwendung, sowohl für Login als auch für das Hinzufügen. Eine **Credential-Inventar-Schicht** gruppiert die vorhandenen Passkeys nach Sync-Status (synchronisiert vs. nicht synchronisiert), Transport (`internal`, `hybrid`, `usb`, `nfc`, `ble`, `smart-card`), [Authenticator](https://www.corbado.com/glossary/authenticator) (Apple, [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager), [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Windows Hello](https://www.corbado.com/glossary/windows-hello), [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis), [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024), [Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [YubiKey](https://www.corbado.com/glossary/yubikey)), Betriebssystem und Browser. Ohne die Inventar-Schicht ist es unmöglich zu hinterfragen, ob eine bestimmte Abweichungsvariante bei einem spezifischen Passwortmanager oder Sync-Status gehäuft auftritt. Dies ist die Mindeststruktur, die Process Mining handhabbar macht. Jedes Ereignis trägt genügend Metadaten, um gruppiert, gefiltert und gerankt zu werden. Jeder Prozess kann individuell nachverfolgt werden, was die nachfolgenden Praxisbeispiele ermöglicht. ### 4.2 Happy Path vs. Abweichungsanalyse Sobald Ereignisse als gerichteter Graph pro Sitzung gespeichert sind, können Sie die Process-Mining-Frage stellen: Wie viel Prozent der Sitzungen folgen dem Happy Path, und für die, die dies nicht tun, was sind die fünf häufigsten Abweichungsvarianten, geordnet nach Häufigkeit? In unseren Analysedaten machen die fünf häufigsten Varianten typischerweise 85 % aller Abweichungen aus. Die Behebung von zwei davon bewegt die Zahlen meistens mehr als jeder A/B-Test auf dem Happy Path. ### 4.3 Kohorten-Drift-Erkennung Varianten driften. Ein Browser-Update, ein OS-Rollout oder eine Änderung beim Passwortmanager kann dazu führen, dass eine zuvor unwichtige Variante plötzlich dominiert. Kohorten-Drift-Erkennung ist die Disziplin, die Verteilung der Varianten pro Gerät/Betriebssystem/Browser-Kohorte im Zeitverlauf zu beobachten, anstatt nur auf die Gesamterfolgsquote zu schauen. So fangen Teams stille Regressionen in Stunden statt in Quartalen ab. ## 5. Vom Process Mining zum feingranularen Step-up ### 5.1 Warum Step-up bisher zu wenig genutzt wurde Step-up-Authentifizierung gibt es seit über einem Jahrzehnt. Sie wurde zu wenig genutzt, weil die meisten Teams unabhängig vom Risiko immer auf die gleiche Weise ein Step-up durchführen: Ein OTP bei jeder Transaktion über einem bestimmten Schwellenwert erzwingen. Das ist eine stumpfe Regel, keine risikobewertete Entscheidung. Es erzeugt Reibung bei 95 % der legitimen hochwertigen Transaktionen, um die 5 % aufzuhalten, die verdächtig sind. ### 5.2 Risikobewertete Journeys Mit Process-Mining-Daten können Sie eine Sitzung kontinuierlich bewerten. Gerätereputation, Basis-Erfolgsrate der Kohorte, Anomalien zur Tageszeit, Abweichungen vom historischen Pfad des Nutzers selbst, [Identität](https://www.corbado.com/de/blog/digital-credentials-api) des Passwortmanagers, IP-Reputation. Der Risikowert steuert dann eine feingranulare Step-up-Entscheidung: Einen zweiten Faktor nur verlangen, wenn das Risiko der Sitzung den Transaktionswert-Schwellenwert überschreitet. Sitzungen mit geringem Risiko für hochwertige Transaktionen werden durchgelassen. Sitzungen mit hohem Risiko für Transaktionen mit geringem Wert erfordern ein Step-up. ## 6. Was das für die CIAM-Anbieterlandschaft bedeutet ### 6.1 Journey-Design als Spezialdisziplin Die Identitätsbranche hat das Journey-Design historisch in den IDP integriert. Orchestrierungs-Engines innerhalb von Okta, Ping, ForgeRock, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) und anderen ermöglichen es Ihnen, Flows zu konfigurieren. Was sie nicht gut können, ist, diese zu beobachten. Dieser Widerspruch eröffnet den Raum für eine spezialisierte Analytics-Schicht. ### 6.2 Warum kein IDP dies nativ liefern wird IDP-Anbieter optimieren für die Control Plane: Wer kann sich anmelden, mit welchem Credential, unter welcher Richtlinie. Process Mining ist eine Data-Plane-Disziplin: jedes Ereignis, skaliert, normalisiert über Betriebssystem-/Browser-/Passwortmanager-Kombinationen hinweg. Das Ereignisvolumen, die Kardinalität und die kundenübergreifenden Baselines sprechen allesamt gegen eine native IDP-Lösung. Siehe die Feldnotizen in unserem Buy-vs-Build-Leitfaden für Passkeys für dasselbe Muster, angewendet auf die SDK-Schicht. ### 6.3 Analytics-Schicht als neue Kategorie Was entsteht, ist eine schlanke Analytics- und Adoption-Schicht, die über dem IDP sitzt, Ereignisse aus dem Frontend aufnimmt, sie gegen implementierungsübergreifende Baselines normalisiert und Erkenntnisse an Orchestrierungsentscheidungen zurückgibt. Sie ersetzt den IDP nicht. Sie macht den IDP messbar. ## 7. Wie Corbado beim Authentifizierungs-Process-Mining hilft [Corbado](https://www.corbado.com/) bietet die Mess- und Adoption-Schicht, die über bestehenden IDPs sitzt. Sie integriert sich in Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), Ory, ForgeRock und benutzerdefinierte Stacks, ohne diese zu ersetzen. Was sie hinzufügt, ist spezifisch die Process-Mining-Fähigkeit: - **End-to-End-Ereignistaxonomie.** Das clientseitige SDK erfasst den gesamten Vorgang vom Laden der Seite bis zur Assertion, einschließlich Ereignissen vor der Kennungseingabe, Aufrufe der [Conditional UI](https://www.corbado.com/glossary/conditional-ui) und die Auswahl des Passwortmanagers. - **Variantenanalyse out of the Box.** Die Plattform rekonstruiert Journey-Graphen pro Kohorte und bewertet Abweichungsvarianten nach Häufigkeit, Wiederherstellungsmöglichkeit und Kosten. - **Kohorten-Drift-Warnungen.** Wenn sich die Variantenverteilung für ein bestimmtes Betriebssystem, einen Browser oder einen Passwortmanager verschiebt, markiert die Plattform dies, bevor es zu einem Day-2-Problem wird. - **Implementierungsübergreifende Baselines.** Da Corbado anonymisierte Daten über Kundenumgebungen hinweg aggregiert, werden neue Fehler oder Regressionen, die in einer Implementierung auftreten, klassifiziert und dokumentiert, bevor sie Ihre erreichen. Sehen Sie sich an, warum Corbado für den vollständigen Ansatz steht. - **Rückkopplung in die Orchestrierung.** Risikobewertete Step-up-Entscheidungen und Unterdrückungsregeln können zurück in den IDP gepusht oder auf der Adoption-Schicht gehandhabt werden, einschließlich dynamischer Kill-Switches und kohortenspezifischem Nudging. ## 8. Fazit Passkeys waren nicht das eigentliche Ziel. Sie waren der instrumentelle Keil, der die erste Welle von CIAM-Teams dazu zwingt, überhaupt clientseitige Ereignisse zu protokollieren. Sobald diese Observability-Schicht existiert, baut eine neue Disziplin darauf auf: Authentifizierungs-Process-Mining. So entwickeln sich Identity-Teams von der Frage "War der Login erfolgreich?" hin zu "Welche Variante der Journey hat dieser Nutzer gewählt, was hat es gekostet und wie sollte die nächste Sitzung anders geroutet werden?". Teams, die zuerst die Observability-Schicht und direkt danach die Process-Mining-Schicht aufbauen, werden den Maßstab für die Kategorie setzen. Teams, die bei aggregierten Erfolgsquoten bleiben, werden die zugrunde liegenden systemischen Varianten weiterhin übersehen. ## FAQ ### Was ist Authentifizierungs-Process-Mining? Authentifizierungs-Process-Mining ist die Anwendung von Business-Process-Mining-Techniken auf Login-Ereignisprotokolle. Es rekonstruiert den gerichteten Graphen der Ereignisse pro Sitzung, vergleicht die erlebte Authentifizierungs-Journey mit der konzipierten Journey und bewertet Abweichungsvarianten nach Häufigkeit und Kosten. Es ist oberhalb der Authentifizierungs-Observability und unterhalb der Orchestrierung angesiedelt. ### Wie unterscheidet es sich von Authentifizierungs-Analytics? Authentifizierungs-Analytics berichten Metriken wie Login-Erfolgsquote, Absprungrate und Passkey-Nutzungsrate. Process Mining geht weiter, indem es die vollständige Ereignissequenz pro Sitzung rekonstruiert und fragt, welche Varianten der Journey existieren, wie oft jede vorkommt und wo jede vom konzipierten Happy Path abweicht. Analytics berichten über Ergebnisse. Process Mining erklärt Pfade. ### Warum macht die Passkey-Einführung diese Disziplin notwendig? Passkey-Einführungen sind der Hauptgrund, warum CIAM-Teams überhaupt anfangen, clientseitige Ereignisse zu instrumentieren. Sobald diese Ereignisse existieren, verbergen aggregierte Metriken zu viel: Eine Erfolgsquote von 92 % kann eine Abbruchquote von 40 % auf dem Passkey-Pfad maskieren. Process Mining lehnt diese Durchschnittsberechnung ab und zwingt Teams, Varianten separat zu betrachten. ### Wie hängt Process Mining mit Step-up-Authentifizierung zusammen? Step-up-Authentifizierung funktioniert am besten, wenn sie risikobewertet statt regelbasiert ist. Process Mining liefert die sitzungsbezogenen Beweise (Kohorten-Baseline, Abweichung vom historischen Pfad des Nutzers, Gerätereputation), die es einer Step-up-Engine ermöglichen, eine feingranulare Entscheidung statt einer stumpfen Schwellenwert-Entscheidung zu treffen. ### Wird mein IDP dies nativ liefern? Wahrscheinlich auf kurze Sicht nicht. IDPs optimieren für die Control Plane. Process Mining ist eine Data-Plane-Disziplin mit hohem Ereignisvolumen und hoher Kardinalität über alle Betriebssystem-, Browser- und Passwortmanager-Kombinationen hinweg. Das Muster entspricht dem, was wir heute auf der SDK-Schicht sehen, was in unserem Buy-vs-Build-Leitfaden behandelt wird. ### Was ist das Erste, das ein CIAM-Team messen sollte? Beginnen Sie mit der Varianten-Häufigkeit auf dem Passkey-Pfad: Wie viel Prozent der Sitzungen folgen dem Happy Path, und was sind die fünf häufigsten Abweichungsvarianten, geordnet nach Häufigkeit? Dieses eine Diagramm reicht normalerweise aus, um die zwei oder drei Fehlerbehebungen aufzudecken, die die Passkey-Adoption insgesamt am meisten vorantreiben.