CIAM-Verantwortung im Unternehmen neu denken

1. Einleitung#

Fragen Sie zehn Unternehmen, wer für die Kunden- oder Verbraucheridentität (CIAM) verantwortlich ist, und Sie erhalten zehn verschiedene Antworten. Manchmal ist es der CISO. Manchmal ist es der CTO, weil CIAM direkt in die App, die Website und die APIs integriert werden muss, die das Produkt ausliefern. Manchmal ist es der CPO. Manchmal ist es ein Fraud-Team, das stückweise übernommen hat, weil niemand anderes das Gesamtbild im Blick hatte. Oft ist es niemand, und das System wird von einem DevOps-Ingenieur am Leben erhalten, der es vor drei Umstrukturierungen geerbt hat.

Der Gartner CIAM Magic Quadrant unterteilt Customer IAM in fünf funktionale Bereiche – Registrierung, Authentifizierung, Autorisierung, Self-Service und Analytik –, die fast nie sauber einem einzigen Team zuzuordnen sind. Laut Grand View Research wurde der globale CIAM-Markt im Jahr 2023 auf 8,12 Milliarden USD geschätzt und soll bis 2030 26,72 Milliarden USD erreichen, was einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 17,4 % entspricht. Die Fragen zur Verantwortung skalieren mit diesen Ausgaben.

CIAM ist eines der funktionsübergreifendsten Programme, die die meisten B2C-Unternehmen betreiben. Es sitzt an der Schnittstelle von Sicherheit, Engineering, Produkt, Betrugsprävention und Wachstum, und jede dieser Funktionen optimiert für eine andere Metrik. Die Verantwortung entscheidet, welche Metrik gewinnt, wenn sie in Konflikt geraten. Unklare Verantwortung bedeutet, dass keine gewinnt und das Identitätsprogramm ins Stocken gerät.

Dieser Artikel überdenkt die CIAM-Verantwortung für das moderne Unternehmen: die häufigsten Verantwortlichen-Profile, wie die Branche die Antwort prägt, warum fragmentierte Daten und eine "Nicht-mein-Problem"-Kultur die Frage offen halten, und wie ein gemeinsames Betriebsmodell aussieht, wenn eine Umstrukturierung nicht zur Debatte steht.

1.1 Fragen, die dieser Artikel beantwortet#

In diesem Artikel beschäftigen wir uns mit den folgenden Fragen:

1. Warum ist die CIAM-Verantwortung in den meisten Unternehmen unklar und was kostet diese Unklarheit tatsächlich?
2. Wer sind die typischen CIAM-Verantwortlichen und wie optimiert jeder das Programm unterschiedlich?
3. Warum korreliert fragmentierte Verantwortung oft mit einer fehlenden Authentifizierungsanalyse-Ebene?
4. Wie verändert der Branchenkontext (E-Commerce vs. Banking vs. reguliertes B2C) die Antwort?
5. Wo tut geteilte Verantwortung am meisten weh?
6. Welche CIAM-KPIs besitzt niemand vollständig, werden aber von jedem Team benötigt?
7. Wie sieht eine gemeinsame CIAM-Scorecard aus und wie führen Sie diese ohne eine Umstrukturierung ein?

2. Das Münzwurf-Problem#

2.1 Warum CIAM Ihr funktionsübergreifendstes Programm ist#

Kunden- und Verbraucheridentität betrifft alles. Sie entscheidet darüber, ob ein Nutzer kaufen, verlängern, den Zugang wiederherstellen oder ein reguliertes Feature erreichen kann. Das CISO-Büro interessiert sich dafür, weil jedes Authentifizierungsereignis ein Sicherheitsereignis ist. Das CTO-Büro interessiert sich dafür, weil CIAM in die App, die Website und die APIs integriert werden muss, und jede Änderung am Login zusammen mit echtem Produktcode ausgeliefert wird. Das CPO-Büro interessiert sich dafür, weil jedes Authentifizierungsereignis ein Conversion-Event ist. Das Fraud-Team interessiert sich dafür, weil jedes Step-up ein Betrugssignal ist. Das Growth-Team interessiert sich dafür, weil Personalisierung davon abhängt, den Nutzer zu identifizieren. Kein anderes System hat gleichzeitig fünf legitime Eigentümer.

2.2 Die Kosten unklarer Verantwortung#

Die Kosten zeigen sich bei Passkey-Rollouts. Implementierungen, die bei 5 % bis 15 % Akzeptanz stehen bleiben, haben fast immer eines gemeinsam: Kein einzelner Verantwortlicher hatte den Rollout durchgängig in der Hand. Die Sicherheit finanzierte das Pilotprojekt, das Produkt besaß die UI, die IT den IDP, Fraud besaß das Step-up, und niemand kümmerte sich um das kohortenspezifische Nudging, das die Registrierung tatsächlich antreibt. Das Programm bewegte sich mit der Geschwindigkeit des langsamsten Beteiligten.

Das FIDO Alliance 2024 Online Authentication Barometer ergab, dass die Bekanntheit von Passkeys weltweit auf 57 % gestiegen ist und 42 % der Befragten, die Passkeys kennen, diese für mindestens ein Konto aktiviert haben. Die Lücke zwischen Bekanntheit und Aktivierung zeigt, wo unklare CIAM-Verantwortung am deutlichsten zutage tritt: Die Technologie funktioniert, der Rollout nicht. Wie Gartner-Analyst David Mahdi im Kontext konvergierender IAM-Disziplinen formulierte: "Unternehmen müssen ihre IAM-Architektur überdenken, um der zunehmenden Dezentralisierung von Identitäts- und Zugriffsmanagement zu begegnen" (vgl. Gartner Press Release). Ohne einen Verantwortlichen findet dieses Überdenken nicht statt.

2.3 Das Problem getrennter Analysen#

Ein Grund dafür, dass so viele Teams am Ende einen Anteil an CIAM haben, ist, dass es von vornherein kein gemeinsames Tool für die Authentifizierungsanalyse gibt. Das untenstehende Diagramm zeigt das Muster: Vier Systeme halten vier Teile der Authentifizierungsreise, und nichts sitzt darüber, um die Signale zu verbinden.

Die NIST Special Publication 800-63-4 Richtlinien für digitale Identität fordern ausdrücklich eine "kontinuierliche Bewertung" der Authenticator Assurance, was ohne eine End-to-End-Ereignissicht unmöglich ist. In der Praxis verfügt nur eine Minderheit der B2C-Programme über diese Sicht: Die 2024 Ping Identity Consumer Survey ergab, dass 63 % der Verbraucher ein Konto nach zwei fehlgeschlagenen Anmeldeversuchen aufgeben würden. Dies ist eine Metrik, die nur wenige CIAM-Teams überhaupt verfolgen, da die dafür benötigten Daten in drei verschiedenen Systemen liegen.

Jeder Verantwortliche schützt dann seinen Teil. Teils liegt es am Budget – das Team, das für die Daten bezahlt hat, meint, die Kontrolle verdient zu haben. Teils liegt es am Einfluss – Daten sind der einfachste Weg, den Wert in einer funktionsübergreifenden Überprüfung zu demonstrieren. Der praktische Effekt ist, dass selbst dann, wenn sich ein CIAM-Problem über alle vier Systeme erstreckt, keine einzige Person es durchgängig sehen kann. Eine dedizierte Observability-Ebene für die Authentifizierung beseitigt diese Ausrede und löst in der Regel die längst überfällige Diskussion über die Zuständigkeit aus.

3. Typische Verantwortliche#

Fünf Funktionen erheben routinemäßig Anspruch auf CIAM, und jede optimiert für eine andere Metrik. Der folgende Vergleich fasst zusammen, woran jeder Archetyp gemessen wird und wo sein blinder Fleck liegt.

3.1 CISO-Büro#

Optimiert für: Betrugsrate, MFA-Abdeckung, Rate kompromittierter Konten und Audit-Ergebnisse. Betrachtet CIAM als Sicherheitskontrolle. Stärken: klare KPIs und Budgetautorität unter regulatorischem Druck (DORA, NIS2 oder NIST 800-63). Blinde Flecken: Conversion-Auswirkungen von Reibung, Supportkosten für fehlerhafte Prozesse und die Erfahrung des Long-Tails von Nutzern, deren Geräte unbemerkt ausfallen.

3.2 CTO-Büro#

Optimiert für: Integrationsaufwand, Plattformzuverlässigkeit, SDK-Qualität, Release-Geschwindigkeit und Engineering-Kosten. Betrachtet CIAM als Produktintegrationsproblem, da Login Code ist, der mit der App, der Website und den APIs ausgeliefert wird. Stärken: Nähe zum Produkt, Verantwortung für das clientseitige SDK, Fähigkeit, fehlerhafte Prozesse schnell zu beheben. Blinde Flecken: regulatorische Feinheiten, Betrugs-Trade-offs und langfristige Credential-Hygiene, sobald die Integration live ist. Der CIO taucht in dieser Rolle im öffentlichen Sektor und in stark zentralisierten IT-Unternehmen auf, aber in den meisten verbraucherorientierten Unternehmen ist das CTO-Büro die passendere Wahl.

3.3 CPO oder Produkt-Büro#

Optimiert für: Login-Conversion, Aktivierungsrate, Wiederherstellungserfolg und Time-to-First-Value. Betrachtet CIAM als Produkt. Stärken: UX-Rigorosität, A/B-Tests und Kundenempathie. Blinde Flecken: Betrugsrisiko, regulatorische Einschränkungen und langfristige Credential-Hygiene.

3.4 Fraud- oder Risiko-Büro#

Optimiert für: Step-up-Auslöserate, False-Positive-Rate, Chargeback-Rate und Account-Takeover-Rate. Besitzt einen Teil der Identität, selten den gesamten. Stärken: Risikomodellierung, Echtzeitsignale und Incident Response. Blinde Flecken: Registrierungsprozesse, Wiederherstellungsprozesse und die Teile der Identität, die nicht transaktional sind.

3.5 Growth- oder Marketing-Büro#

Aufstrebender Verantwortlicher, insbesondere bei Verbraucherabonnements und im Einzelhandel. Optimiert für: Re-Engagement-Rate, Cross-Sell-abhängige Logins und Personalisierungsbereitschaft. Betrachtet Identität als Grundlage für Growth Loops. Stärken: Lebenszyklus-Denken und Experimentierkultur. Blinde Flecken: alles, was kein Wachstum ist.

4. Wo geteilte Verantwortung wirklich schmerzt#

4.1 Bereitstellung vs. Deaktivierung#

Die Bereitstellung (Provisioning) ist ein Effizienzproblem: Wie schnell bekommt man einen Nutzer ins System. Die Deaktivierung (Deprovisioning) ist ein Sicherheitsproblem: Wie schnell bekommt man einen kompromittierten oder abgewanderten Nutzer wieder heraus. Sie werden fast immer als ein Tool gekauft und nicht optimal eingestellt, weil der auf Effizienz fokussierte Verantwortliche nie den Schmerz der Deaktivierung spürt und der sicherheitsfokussierte Verantwortliche nie den Schmerz der Bereitstellung.

4.2 Fraud-UX vs. Produkt-UX#

Fraud fügt Reibung hinzu, weil Reibung böswillige Akteure blockiert. Produkt entfernt Reibung, weil Reibung Umsatz blockiert. Wenn beide Teams dieselbe Anmeldeseite ohne gemeinsamen Verantwortlichen gestalten, ist das Ergebnis ein Kompromiss, der niemanden zufriedenstellt: genug Reibung, um Nutzer zu verärgern, aber nicht genug, um Betrug zu stoppen. Risikobasiertes Step-up ist die technische Antwort. Ein einziger Verantwortlicher für die Nutzerreise ist die organisatorische Antwort.

4.3 Keine gemeinsame Sicht auf die Login-Performance#

Geteilte Verantwortung schmerzt auch, weil es keine gemeinsame Analyseebene gibt. Die echten Login-Performance-Zahlen – End-to-End-Erfolgsrate, Wiederherstellungserfolg, Step-up-Auslöserate, Fallback-Anteil nach Kohorte und Erfolgsraten nach Methode (Passwörter, OTP, Social, Passkeys) – liegen verstreut über den IDP, die Produktanalyse-Suite, die Betrugs-Engine, das SIEM und ein paar Tabellenkalkulationen dazwischen. Jedes Team sieht seinen eigenen Teil, niemand sieht die gesamte Reise, und die Symptome werden in Metriken begraben, die einzeln gut aussehen, aber das eigentliche Problem verbergen.

Ein Login, das für Nutzer auf älteren Android-Versionen langsam ist, zeigt sich als kleiner Ausschlag bei der IDP-Latenz, als kleiner Einbruch bei der Conversion und als kleiner Anstieg der Support-Tickets. Nichts davon ist für sich genommen alarmierend. Zusammen ergeben sie eine Regression, die es wert ist, behoben zu werden. Ohne einen Verantwortlichen und eine Sichtweise kann diese Regression quartalsweise unberührt bleiben.

5. Die Branche prägt die Antwort#

Wer letztendlich die Verantwortung für die Kunden- und Verbraucheridentität trägt, hängt auch von der Branche ab. Dasselbe Organigramm, das für einen Sektor funktioniert, wirkt in einem anderen über- oder unterreguliert.

• E-Commerce betrachtet CIAM als Conversion-Problem. Produkt verantwortet das Login, Growth verantwortet das Re-Engagement und Fraud sitzt neben beiden. Die Risikobereitschaft für Sicherheit ist moderat. Der Rhythmus besteht aus wöchentlichen Experimenten. Die Baymard Institute Forschung zu Warenkorbabbruchen meldet eine durchschnittliche Abbruchrate von 70,2 %, und ein erheblicher Teil ist auf Konto-Reibungen zurückzuführen, was das Produkt fest im Fahrersitz hält.
• Banken und Finanzdienstleistungen betrachten CIAM als Sicherheits- und Compliance-Problem. Der CISO verantwortet das Programm, Risiko verantwortet Step-up und die IT betreibt die Plattform. Der Sicherheitsappetit ist hoch und der Rhythmus ist quartalsweise mit strengen Audits.
• Telekommunikation, Versicherungen und Gesundheitswesen liegen dazwischen. Der Compliance-Druck zieht sie in Richtung Banken. Der Druck der Kundenerfahrung zieht sie in Richtung E-Commerce. Das Governance-Modell ist in der Regel eine Aufteilung zwischen CISO und CPO mit einer gemeinsamen Scorecard.
• Der öffentliche Sektor und das regulierte B2B-Umfeld priorisieren Auditierbarkeit gegenüber Experimenten. CIAM ist unter dem CIO (wo zentralisierte IT noch existiert) oder unter einer dedizierten Identity-Governance-Funktion mit einem Compliance-gesteuerten Rhythmus angesiedelt. Die Anforderungen der NIST 800-63-4 Identity Assurance Level bilden die Untergrenze.

Der folgende Quadrant ordnet jede Branche in die beiden Dimensionen ein, die die Frage der Verantwortung vorantreiben – Sicherheitsappetit und Überprüfungsrhythmus – und ordnet den dominierenden Verantwortlichen zu, der sich aus jeder Position ergibt.

Eine Scorecard, die für einen Einzelhändler funktioniert, wirkt in einer Bank unterreguliert. Ein Governance-Modell, das für eine Bank funktioniert, wirkt bei einem Einzelhändler überdimensioniert. Veröffentlichte, von Anbietern in Auftrag gegebene Forrester Total Economic Impact (TEI) Studien zu CIAM zeigen eine große Spanne: Die ForgeRock CIAM TEI berichtete von 186 % ROI über drei Jahre, während die WSO2 CIAM TEI 332 % ROI verzeichnete. Der Mix der Treiber – Conversion-Steigerung vs. Betrugsreduzierung vs. Auditkosten – unterscheidet sich erheblich zwischen den Sektoren, weshalb auch die ROI-Spanne selbst variiert. Die Wahl des richtigen Verantwortlichen beginnt damit, das Branchenmuster zu benennen, in dem Sie tatsächlich agieren.

6. Workforce Identity vs. Customer Identity#

Workforce IAM und Customer IAM sitzen normalerweise in verschiedenen Teams, und das ist in der Regel das richtige Setup. Beide befassen sich mit Identität, aber sie optimieren für unterschiedliche Dinge. Workforce IAM verwaltet bekannte Mitarbeiter auf verwalteten Geräten mit langen Sitzungen und einer kleinen Nutzerpopulation, typischerweise 1.000 bis 100.000 Nutzer. CIAM verwaltet anonyme Interessenten und Kunden auf nicht verwalteten Geräten mit kurzen, konversionssensiblen Sitzungen und einer um mehrere Größenordnungen größeren Nutzerpopulation, oft zig oder hunderte Millionen. Die Bedrohungsmodelle, KPIs und Werkzeugauswahl weichen voneinander ab.

7. Keine einzige richtige Antwort#

Es gibt keinen universell richtigen oder falschen Ort für CIAM. Wichtig ist, dass die internen Abhängigkeiten funktionieren: Das verantwortliche Team hat die Befugnis, Entscheidungen zu treffen, die beitragenden Teams haben offiziell einen Platz am Tisch, und die Scorecard wird so geteilt, dass niemand eine Metrik aus dem Kontext reißen kann.

Eine regulierte Bank kann CIAM unter dem CISO betreiben und erfolgreich sein. Ein Einzelhändler kann CIAM unter dem CPO betreiben und erfolgreich sein. Ein Telekommunikationsunternehmen kann ein geteiltes Modell zwischen CISO und CPO betreiben und erfolgreich sein. Was überall scheitert, ist eine implizite Verantwortung ohne treibende Kraft, ohne gemeinsame Analyseebene und ohne Rhythmus für funktionsübergreifende Überprüfungen. Das organisatorische Muster ist weniger wichtig als das Betriebsmodell, das darauf aufbaut.

8. Gemeinsame CIAM-Scorecard#

Die Auswahl einer Scorecard ist oft einfacher als die Wahl eines Verantwortlichen, und sie funktioniert ohne Umstrukturierung. Die Idee ist simpel: Das funktionsbezogene Dashboard jedes Führungskräftebereichs ist lokal korrekt und global unvollständig. Die Lösung ist eine Seite, fünf Metriken, die monatlich von den verantwortlichen Funktionen gemeinsam überprüft werden.

8.1 Metriken, die niemand vollständig besitzt#

Dies sind die fünf funktionsübergreifenden KPIs, die zwischen die Ansichten von CISO, CTO, CPO, Fraud und Growth fallen. Jede ist tragend und in den meisten Unternehmen unzureichend instrumentiert. Das folgende Diagramm zeigt, wie jede Metrik an der Schnittstelle mehrerer Verantwortungsbereiche sitzt, weshalb keine von ihnen sauber bei einem einzigen Team landet.

• Anmeldeerfolgsrate nach Kohorte. Aggregierter Anmeldeerfolg verbirgt alles. Eine globale Rate von 92 % kann eine Rate von 70 % auf einer spezifischen Kombination aus Betriebssystem, Browser und Passwort-Manager verbergen. Die Erfolgsrate nur aggregiert zu melden, ist der häufigste Fehler bei der CIAM-Messung.
• Zeit bis zur ersten authentifizierten Aktion. Die Latenz, die ein Nutzer tatsächlich erlebt, von der Ankunft auf der Login-Seite bis zu dem Moment, in dem er transagieren kann. Umfasst die Fire-Time der Conditional UI, die Auswahl der Anmeldeinformationen, den biometrischen Prompt und die Umleitung zurück. Korreliert mit Conversion, und niemand besitzt es.
• Nutzung und Erfolg des Wiederherstellungspfads. Wie viele Nutzer auf die Wiederherstellung zugreifen, welche Pfade sie nutzen und wie viele erfolgreich sind. Wiederherstellung ist der Punkt, an dem Betrug, Reibung und Supportkosten aufeinandertreffen. Sie gehört dem CISO, dem CPO und dem CTO gleichzeitig, was meistens bedeutet: niemandem.
• Passkey-Erstellung vs. Passkey-Nutzung. Die Erstellung ist der Anteil der berechtigten Nutzer, die sich registriert haben. Die Nutzung ist der Anteil der Logins, die tatsächlich einen Passkey verwenden. Ein Rollout kann 60 % Reichweite und 20 % Nutzung haben, wenn registrierte Nutzer aus Gewohnheit weiterhin Passwörter eingeben. Die gleiche Lücke gilt für jede neue Authentifizierungsmethode.
• Abbruch nach Auth-Methode. Mit welcher Methode begann die Sitzung und wie oft wurde sie nicht beendet. Abbrüche bei Passwörtern, OTP, Social Login und Passkeys haben unterschiedliche Ursachen – Credential-Hygiene, Zustellungsfehler, Ausfälle von Drittanbietern, Platzierung in der Benutzeroberfläche oder Konflikte mit dem Passwort-Manager. Eine Durchschnittsbildung verbirgt sie alle.

8.2 Eine Seite, fünf Metriken, monatliche Überprüfung#

Die Scorecard ist ein einseitiges Artefakt, das monatlich von den verantwortlichen Funktionen gemeinsam überprüft wird. Jede Metrik hat einen Hauptverantwortlichen für die Datenqualität, einen funktionsübergreifenden Verantwortlichen für den Aktionsplan und ein Ziel, das zu Beginn jedes Quartals gemeinsam festgelegt wird. Eine Notion-Seite oder Google Sheet reicht aus – die Überprüfung findet anhand des One-Pagers statt, nicht in den zugrundeliegenden Dashboards.

Jeder Verantwortliche steuert den Teil bei, den nur er sehen kann:

• Sicherheit steuert Betrugsrate, Rate kompromittierter Konten und Step-up-Ergebnisse pro Kohorte bei.
• CTO / Engineering steuert Uptime, Integrationsfehlerrate, SDK-Performance und Kosten pro Authentifizierung nach Methode bei.
• Produkt steuert Conversion-Trichter, Drop-off nach Schritt und Time-to-First-Value bei.
• Betrug (Fraud) steuert Step-up-Auslöserate und False-Positive-Rate nach Kohorte bei.
• Growth steuert das Verhältnis von anonymen zu identifizierten Sitzungen und die Re-Engagement-Rate bei.

Die folgende Matrix fasst das Beitragmuster zusammen und macht die Abdeckungslücken explizit – kein einzelner Verantwortlicher produziert alle fünf Metriken allein.

8.3 Einführung ohne Umstrukturierung#

Die meisten Scorecard-Programme scheitern an der Instrumentierung, nicht an der Governance. Wenn die zugrundeliegende Observability-Ebene die Erfolgsrate nicht nach Betriebssystem, Browser und Credential Manager aufschlüsseln kann, wird auch die beste Überprüfungsfrequenz keine nützliche Scorecard hervorbringen. Die Sequenz, die sich in der Praxis bewährt:

1. Zuerst instrumentieren. Clientseitige Event-Telemetrie, die die Erfolgsrate nach Kohorten aufschlüsseln kann, ist die Voraussetzung für jede andere Scorecard-Metrik.
2. Wählen Sie zuerst eine Metrik für die gemeinsame Verantwortung. Die Anmeldeerfolgsrate nach Kohorte ist meist die richtige erste Wahl, da sie die kohortenübergreifende Instrumentierung erzwingt, von der jede andere Metrik abhängt.
3. Monatliches 60-minütiges Review. Meeting eins: Einigung auf die fünf Metriken und die aktuelle Baseline. Meeting zwei: Einigung auf Quartalsziele. Meeting drei: erster Aktionsplan. Fügen Sie Metriken über zwei Quartale verteilt hinzu, anstatt alle auf einmal.

Nach sechs Monaten meldet ein reifes Deployment die Anmeldeerfolgsrate nach Kohorte mit benannten Verantwortlichen für die schlechtesten drei, Passkey-Reichweite und -Nutzung als zwei getrennte Zahlen, Wiederherstellungserfolg mit einem gemeinsamen CISO/CPO-Verantwortlichen, Step-up-Auslöserate zusammen mit der False-Positive-Rate und die Kosten pro Authentifizierung aufgeschlüsselt nach Methode. Die monatliche Überprüfung entwickelt sich von Diskussionen über Daten hin zu Diskussionen über Entscheidungen, was das eigentliche Ziel ist.

9. Wie Corbado die fehlende Datenschicht für Authentifizierung hinzufügt#

Corbado entscheidet nicht, wer CIAM besitzt, und versucht es auch nicht. Die Verantwortung ist eine organisatorische Entscheidung. Was Corbado mitbringt, ist die Datenschicht, die von Anfang an fehlte – die Ebene, die durch Silos, geteilte Budgets und eine "Nicht mein Problem"-Haltung nie von allein entstanden ist. Die Authentifizierung erhält endlich das Äquivalent zu dem, was Produktanalyse, Observability und Fraud-Tools bereits in ihren eigenen Bereichen haben.

Die Authentifizierungs-Observability-Ebene sitzt über dem IDP, der Fraud-Engine und dem SIEM und vereint deren Signale in einer Sicht auf die Login-Reise. Backend-Versuche, clientseitige Abläufe, das Verhalten des Passwort-Managers, kohortenspezifischer Erfolg und Wiederherstellungsergebnisse leben in einem System und werden miteinander verglichen.

• Eine Datenschicht für die Authentifizierung. Backend-, Frontend-, Fraud- und Sicherheitssignale werden pro Sitzung, pro Kohorte und pro Reise korreliert, sodass die tatsächliche Anmeldeperformance nicht länger über vier Systeme verstreut ist.
• Erfolgsrate auf Kohortenebene. Anmeldeerfolg aufgeschlüsselt nach Betriebssystem, Browser, Credential Manager und Hardware – die erste Scorecard-Metrik, die die meisten Teams mit ihren bestehenden Tools nicht erstellen können.
• Erstellung und Nutzung als separate Zahlen. Passkey-Erstellung und Passkey-Nutzung werden als zwei getrennte KPIs ausgewiesen, was die wichtigste Messungskorrektur darstellt, die die meisten Scorecards benötigen.
• Analytik der Wiederherstellungspfade. Die Nutzung, der Erfolg und der Abbruch von Wiederherstellungsprozessen tauchen in der gleichen Ereignistaxonomie auf wie die Anmeldeabläufe, sodass CISO und CPO dieselben Zahlen sehen.
• Abbruch nach Methode. Abbrüche pro Methode ermöglichen es der Scorecard, Passwort-Abbrüche (Credential-Hygiene) von Passkey-Abbrüchen (UI- oder Passwort-Manager-Konflikte) zu trennen.
• Sicherheitsvorkehrungen für den Rollout. Dynamische Unterdrückung, kohortenspezifisches Nudging und Kill-Switches ermöglichen es dem Einberufer des Programms, Änderungen vorzunehmen, ohne den IDP direkt zu berühren.
• Referenz-Benchmarks. Vergleiche über Deployments hinweg aus dem Kundenstamm von Corbado ermöglichen den Vergleich interner Zahlen mit externen, was oft ein monatliches Review in eine konkrete Entscheidung verwandelt.

Streitigkeiten um die Zuständigkeit verschwinden nicht durch eine Datenschicht. Sie werden jedoch leichter zu lösen, weil Streitigkeiten nach dem Motto "meine Daten sagen" aufhören und Diskussionen darüber beginnen, was zu tun ist.

10. Fazit#

CIAM hat mehrere legitime Eigentümer, und das wird sich nicht ändern. Was sich ändert, ist, ob das Unternehmen einen Eigentümer oder eine Scorecard wählt. Einen Eigentümer zu wählen ist schneller, erfordert aber politisches Kapital. Eine Scorecard zu wählen ist langsamer, funktioniert aber ohne Umstrukturierung. Beide Wege sind besser als der implizite Münzwurf, den die meisten Unternehmen heute betreiben. Die Kosten unklarer Verantwortung messen sich in feststeckenden Rollouts, unzusammenhängenden Prozessen und der schleichenden Erosion von Sicherheits- und Conversion-Zahlen zur gleichen Zeit.

Über Corbado

Corbado ist die Passkey Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

FAQ#

Wer verantwortet typischerweise CIAM in einem großen Unternehmen?#

Unserer Erfahrung nach ist die Verantwortung oft zwischen CISO, CTO, CPO, Fraud und Growth aufgeteilt. In regulierten Branchen hat das CISO-Büro die primäre Autorität. In verbraucherorientierten, digital-nativen Unternehmen haben meistens der CPO oder der CTO die Hauptverantwortung, da CIAM in das Produkt integriert werden muss. Ein dedizierter Identity-Produktmanager, der eine gemeinsame Scorecard betreibt, ist in beiden Bereichen das ausgereiftere Modell.

Ändert die Branche, wer CIAM verantworten sollte?#

Ja. Der E-Commerce betrachtet CIAM als Conversion-Problem und verortet es meist beim Produkt oder Growth. Banken betrachten es als Sicherheits- und Compliance-Problem und verorten es beim CISO. Telekommunikation, Versicherungen und das Gesundheitswesen nutzen geteilte Modelle. Die richtige Antwort richtet sich nach dem Sicherheitsappetit und dem Überprüfungsrhythmus der Branche, nicht nach abstrakten Best Practices.

Warum schadet eine geteilte CIAM-Verantwortung neuen Authentifizierungs-Rollouts?#

Jede neue Authentifizierungsmethode – von Social Login und MFA-Step-up bis hin zu Passkeys – erfordert abgestimmte Registrierungs-UX, Wiederherstellungsprozesse, Risikorichtlinien und Support-Tools. Wenn diese jeweils unter einem anderen Eigentümer mit unterschiedlicher Geschwindigkeit angesiedelt sind, bewegt sich der Rollout im Tempo des langsamsten Beteiligten. Passkey-Implementierungen sind dafür das sichtbarste aktuelle Beispiel und bleiben regelmäßig bei 5 % bis 15 % Akzeptanz stecken.

Sollten Workforce IAM und Customer IAM im selben Team sitzen?#

Meistens nicht. Sie teilen sich das Vokabular, aber sonst wenig. Workforce IAM optimiert auf verwaltete Geräte, bekannte Nutzer und Kosteneffizienz. Customer IAM optimiert auf nicht verwaltete Geräte, anonyme Nutzer und Conversion. Reife Unternehmen trennen sie in der Governance und teilen sich eher ein Gremium als einen Leiter.

Was sind die wichtigsten CIAM-KPIs?#

Fünf funktionsübergreifende Metriken, die zwischen den Dashboards der einzelnen Funktionen fallen: Anmeldeerfolgsrate nach Kohorte, Zeit bis zur ersten authentifizierten Aktion, Passkey-Reichweite und -Nutzung als zwei separate Zahlen, Erfolg von Wiederherstellungspfaden und Abbruch nach Auth-Methode. Jede Metrik ist grundlegend und in den meisten Unternehmen nicht ausreichend messbar gemacht.

Warum sind Passkey-Reichweite und Passkey-Nutzung nicht dieselbe Metrik?#

Die Reichweite ist der Prozentsatz berechtigter Nutzer, die einen Passkey eingerichtet haben. Die Nutzung ist der Prozentsatz der Logins, bei denen tatsächlich ein Passkey verwendet wird. Ein Rollout kann eine hohe Reichweite und eine geringe Nutzung aufweisen, wenn registrierte Nutzer aus Gewohnheit weiterhin Passwörter eingeben. Nur eine Metrik zu melden, führt das Management-Review in die Irre.

Was ist eine gemeinsame CIAM-Scorecard?#

Ein einseitiges Artefakt mit fünf funktionsübergreifenden Metriken, das monatlich von den verantwortlichen Funktionen zusammen überprüft wird. Jede Metrik hat einen primären Verantwortlichen für die Datenqualität, einen funktionsübergreifenden Verantwortlichen für den Aktionsplan und ein Ziel, das zu Beginn jedes Quartals gemeinsam festgelegt wird. Das Review findet anhand des One-Pagers statt, nicht mit den zugrundeliegenden Dashboards.

Wie oft sollte die Scorecard überprüft werden?#

Monatlich, in einem 60-minütigen funktionsübergreifenden Meeting mit den Eigentümerfunktionen. Passiert es häufiger, ändert sich nichts zwischen den Reviews. Passiert es seltener, bleibt systemischer Verfall unbemerkt, insbesondere bei kohortenspezifischen Regressionen nach Betriebssystem- oder Browser-Updates.

Wie fangen wir ohne eine Umstrukturierung an?#

Wählen Sie die zwei Metriken aus, die am meisten wehtun, bringen Sie die Verantwortlichen in einem monatlichen 60-minütigen Review nur für diese Metriken zusammen und weiten Sie dies über zwei Quartale aus. Es ändern sich keine Titel. Die Scorecard selbst wird zur Governance-Ebene. Die meisten Unternehmen erreichen so innerhalb von 12 bis 18 Monaten ein ausgereiftes Modell, ohne formell Berichtslinien zu verschieben.

Kann ein Anbieter helfen, Zuständigkeitskonflikte zu lösen?#

Ein Anbieter kann die Zuständigkeit nicht für Sie klären. Er kann jedoch die Unklarheit in den Daten beseitigen, die Zuständigkeitskonflikte so schwer lösbar macht. Eine gemeinsame Analyseebene gibt jedem Verantwortlichen den Teil, den er benötigt, bewahrt aber die aggregierte Sicht. Oft reicht das aus, um eine politische Debatte in eine operative zu verwandeln.