CIAM ist nicht primär ein UX-Thema. Es ist ein Kontrollproblem entlang der Customer Journey.

Der neue Service ist live. Das Produktteam hat den Launch gehalten, Marketing hat die Kampagne vorbereitet, und der erste Traffic kommt wie geplant über Web, Mobile und Partnerkanäle. Auf dem Papier wirkt alles geordnet. Erst im Betrieb zeigt sich das eigentliche Muster: Nutzer registrieren sich mehrfach, Einwilligungen sind je Kanal unterschiedlich dokumentiert, Support beantwortet Anfragen zu Kontozugriffen, die niemand sauber zuordnen kann, und jede neue digitale Strecke erzeugt einen weiteren Sonderfall in der Identitätslogik.

Das Problem beginnt selten mit einem Ausfall. Es beginnt damit, dass die digitale Kundenbeziehung zwar wächst, die zugrunde liegende Steuerung aber fragmentiert bleibt. Viele SaaS-Unternehmen investieren deshalb viel Energie in Conversion, Personalisierung und Self-Service, behandeln Identität jedoch weiterhin als nachgelagerten Login-Prozess. Das ist verständlich. Es ist aber strategisch zu kurz gedacht.

Die Debatte wird oft als Spannungsfeld zwischen Kundenzufriedenheit und Sicherheit geführt. Sie sollte als Frage operativer Kontrolle verstanden werden. Der Punkt ist nicht, ob ein Login bequem oder stark abgesichert ist. Der Punkt ist, ob ein Unternehmen Kundenidentitäten über Kanäle, Systeme, Einwilligungen und Zugriffsentscheidungen hinweg konsistent steuern kann.

Die These ist deshalb klar: Das Problem ist nicht eine schlechte Anmeldung. Das eigentliche Problem ist eine unzureichend geführte Identitätsarchitektur für externe Nutzer. Wo diese Kontrolle fehlt, entstehen nicht nur Reibung in der Customer Journey, sondern auch höhere Supportkosten, schwächere Compliance-Fähigkeit, langsamere Produkteinführung und vermeidbares Vertrauensrisiko.

Kundenzufriedenheit scheitert selten am Frontend, sondern an der fragmentierten Identitätslogik dahinter

In vielen Organisationen wird Customer Experience noch immer an sichtbaren Touchpoints gemessen: Ladezeiten, Formulare, Conversion-Raten, Designkonsistenz. Diese Faktoren sind relevant, aber sie erklären nur einen Teil der Wirklichkeit. Die erste strukturelle Schwäche liegt oft tiefer: dieselbe Person erscheint in mehreren Systemen unterschiedlich, erhält je Kanal andere Rechte oder muss Informationen mehrfach eingeben, weil Registrierung, Authentifizierung, Profilverwaltung und Consent historisch getrennt gewachsen sind.

Das hat direkte wirtschaftliche Folgen. Wenn Identitätsdaten nicht übergreifend abgestimmt sind, wird jede Personalisierung teurer, jeder neue Kanal langsamer und jede regulatorische Anforderung aufwendiger. Was als kundenfreundliche Flexibilität gedacht war, wird zur Integrationsschuld. Eine häufige operative Beobachtung ist, dass das Thema zunächst im Support sichtbar wird, nicht in der Architektur. Die ersten Symptome sind nicht Sicherheitsvorfälle, sondern Passwort-Resets, doppelte Accounts, widersprüchliche Stammdaten und eskalierte Fälle zwischen Produkt, CRM und Compliance.

Besonders deutlich wird das in regulierten oder vertrauenssensiblen Branchen, aber nicht nur dort. Finanzdienstleister, Versicherer und digitale Plattformanbieter müssen heute Web- und Mobile-Zugänge, Partnerbeziehungen und wachsende Datenschutzanforderungen gleichzeitig bedienen. Für SaaS-Unternehmen mit mehreren Produktlinien kommt ein weiterer Faktor hinzu: Mit jedem neuen Service steigt der Druck, Zugänge zu vereinheitlichen, ohne bestehende Kundenpfade zu stören. Genau dort kippt eine operative Herausforderung in ein Governance-Thema.

Die verbreitete Annahme lautet, mehr Personalisierung brauche vor allem mehr Daten. In der Praxis gilt oft das Gegenteil. Mehr Daten ohne saubere Identitätsführung erhöhen die Koordinationskosten. Sie verbessern nicht automatisch die Entscheidungqualität. Wer Kundenzufriedenheit steigern will, muss daher nicht zuerst mehr digitale Erlebnisse bauen, sondern die Identitätslogik stabilisieren, auf der diese Erlebnisse beruhen.

Warum die alte Trennung zwischen Marketing, Sicherheit und Service nicht mehr trägt

Customer Identity and Access Management wird in vielen Unternehmen noch aus einer von zwei Richtungen betrachtet: entweder als Marketing-nahe Grundlage für personalisierte Journeys oder als Sicherheitsbaustein für externe Zugriffe. Beides ist richtig. Beides ist allein nicht ausreichend. Der strukturelle Fehler besteht darin, Identität funktionsbezogen zu organisieren, obwohl sie längst zur gemeinsamen Kontrollschicht geworden ist.

Sobald Kunden über mehrere Produkte, Geräte oder Partnerkanäle interagieren, reichen lokale Lösungen nicht mehr aus. Dann geht es nicht nur um Registrierung und Login, sondern um Zuständigkeiten: Wer entscheidet über Datenkonsistenz, über Einwilligungsnachweise, über Schritt-für-Schritt-Autorisierung in sensiblen Prozessen, über die Verbindung zwischen Kundenkonto und Servicehistorie? Wenn diese Entscheidungen verteilt und implizit bleiben, entsteht kein flexibles Modell, sondern eine stille Instabilität.

Ein zweites Missverständnis betrifft die Automatisierung. Viele Teams hoffen, dass mehr Self-Service die Belastung der IT und des Supports reduziert. Das geschieht nur dann, wenn das zugrunde liegende Identitätsmodell konsistent ist. Andernfalls verlagert sich die Arbeit lediglich. Nutzer verwalten zwar ihre Daten selbst, aber Konflikte bei Konten, Rollen, Einwilligungen und Wiederherstellungsprozessen nehmen zu. In midsize Organisationen wird das Problem meist sichtbar, wenn Internationalisierung oder B2B-Erweiterungen hinzukommen. Was lokal noch handhabbar war, wird grenzüberschreitend und kanalübergreifend unübersichtlich.

Hinzu kommt ein verändertes regulatorisches Umfeld. Datenschutz ist keine Dokumentationsfrage mehr, sondern eine Betriebsfrage. Anforderungen aus Datenschutzrecht, sektorspezifischen Vorgaben und Sicherheitsstandards wie FIDO2 für phishing-resistente Authentisierung oder NIS2-nahe Governance-Erwartungen verschieben die Messlatte. Sie fragen nicht nur, ob ein Unternehmen Regeln formuliert hat. Sie fragen, ob es Zugriffe, Einwilligungen und Verantwortlichkeiten unter realen Bedingungen beherrscht.

Das Identity Journey Control Model

Um diese Lücke greifbar zu machen, hilft ein einfaches Entscheidungsmodell. Das Identity Journey Control Model ordnet Customer Identity Management nicht nach Funktionen, sondern nach der Qualität der unternehmensweiten Steuerung. Es beantwortet eine strategische Frage: Wird Identität als lokale Technik für einzelne Touchpoints betrieben oder als kontrollierte Schicht, die Kundenbeziehung, Risiko und Betriebsfähigkeit miteinander verbindet?

Das Modell unterscheidet vier Stufen. Entscheidend ist nicht, auf welcher Stufe ein Unternehmen heute steht, sondern ob die aktuelle Stufe noch zum Geschäftsmodell passt. Viele Teams halten ihr Setup für ausreichend, weil der Login funktioniert und Audits bestanden wurden. Die eigentliche Prüfung lautet jedoch anders: Kann die Organisation neue Kanäle, Märkte, Partner und regulatorische Anforderungen aufnehmen, ohne die Identitätslogik jedes Mal neu zu verhandeln?

• Isoliert: Registrierung, Login, Profile und Zustimmungen sind pro Anwendung oder Kanal organisiert. Die Customer Journey wirkt digital, die Identitätsführung bleibt lokal.
• Synchronisiert: Daten werden zwischen Systemen abgeglichen, meist über Integrationen und nachträgliche Vereinheitlichung. Das verbessert Sichtbarkeit, erhöht aber die Abhängigkeit von Schnittstellen und Sonderlogiken.
• Gesteuert: Identitätsentscheidungen folgen unternehmensweiten Regeln für Zugriff, Einwilligung, Nutzerkontext und Lifecycle. Neue Services lassen sich schneller anbinden, weil die Grundlogik bereits definiert ist.
• Orchestriert: Identität wird als laufende Kontrollschicht geführt, die Kundenerlebnis, Sicherheitsniveau, regulatorische Nachweise und Partnereinbindung zusammenhält. Auf dieser Stufe sinkt nicht die Komplexität der Umgebung, sondern die Komplexität ihrer Steuerung.

Was sich im Markt tatsächlich verändert hat

Der Druck auf dieses Thema kommt nicht nur aus steigenden Kundenerwartungen. Drei Verschiebungen verändern die Lage substanziell. Erstens hat sich der Kanalmix verändert. Kunden wechseln selbstverständlich zwischen App, Web, Support, Partnerportal und eingebetteten Services. Jedes Medienbruchstück wird schneller als Vertrauensproblem wahrgenommen, nicht nur als Usability-Mangel.

Zweitens ist die Kostenfrage härter geworden. In einem Umfeld knapperer Budgets tolerieren Vorstände und Buying Committees weniger gern Systeme, die bei jedem neuen Produkt oder jeder Expansion zusätzliche manuelle Abstimmung erzeugen. Identitätsarchitektur wird damit zu einer Frage der Skalierungskosten. Je mehr Ausnahmen im Modell stecken, desto teurer wird Wachstum.

Drittens steigt die Relevanz von Souveränität und Kontrollnachweis, gerade in Europa. Für viele Unternehmen reicht es nicht mehr, irgendeine cloudbasierte Zugangslösung zu betreiben. Sie müssen nachvollziehbar entscheiden können, wo Daten liegen, wie Einwilligungen verwaltet werden, welche Authentisierungsniveaus für welche Prozesse gelten und wie sich externe Identitäten in bestehende Governance einfügen. Das ist keine ideologische Debatte. Es ist eine Beschaffungs- und Risikofrage.

Eine weitere Feldbeobachtung: Der erste ernsthafte Architekturstreit entsteht oft nicht beim Kunden-Login selbst, sondern bei Partnern, Delegation und Sonderrollen. Sobald externe Nutzer nicht nur kaufen, sondern verwalten, freigeben oder im Namen anderer handeln, bricht ein rein verbraucherzentriertes Modell auf. Dann zeigt sich, ob CIAM als Marketing-Enabler gedacht wurde oder als belastbare Kontrollschicht.

Was das für SaaS-Entscheider bedeutet

Für SaaS-Unternehmen ist die operative Konsequenz eindeutig: Customer Identity sollte nicht als isoliertes Projekt zwischen Produkt und Security hängen bleiben. Sie gehört in die Diskussion über Betriebsmodell, Integrationsarchitektur und Governance. Wer das Thema zu eng fasst, optimiert meist an der falschen Stelle. Die sichtbare Reibung sinkt kurzzeitig, die strukturelle Abhängigkeit wächst weiter.

Das gilt in unterschiedlicher Ausprägung für verschiedene Reifestufen. Jüngere SaaS-Anbieter brauchen vor allem Klarheit darüber, wie sie künftige Produktlinien und Regionen ohne Neukonstruktion der Identitätslogik anschließen. Etablierte Anbieter mit mehreren Systemgenerationen müssen dagegen eher über Konsolidierung, Nachweisfähigkeit und abgestufte Zugriffsmodelle nachdenken. In beiden Fällen ist die zentrale Managementfrage dieselbe: Ist Identität ein Nebenthema der Anwendung oder eine steuerbare Schicht des Geschäfts?

In diesem Zusammenhang sind Plattformen wie Nevis für Organisationen relevant, die externe Identitäten nicht nur verwalten, sondern über regulierte, mehrkanalige und heterogene Umgebungen hinweg kontrollierbar machen müssen. Der Unterschied liegt weniger in einzelnen Funktionen als in der Fähigkeit, Sicherheit, Nutzerführung, Integrationsfähigkeit und europäische Kontrollanforderungen in ein belastbares Betriebsmodell zu überführen.

Die praktische Folge ist nüchtern. Wenn CIAM richtig eingeordnet wird, verbessert es nicht nur Registrierung oder Login. Es senkt Koordinationskosten zwischen Teams, verringert den Aufwand bei neuen digitalen Services und reduziert das Risiko, dass Kundenzufriedenheit, Compliance und Sicherheit gegeneinander ausgespielt werden.

Vier Fragen, die ein Buying Committee beantworten können sollte

Wer Customer Identity strategisch bewerten will, braucht keine lange Wunschliste. Er braucht einige wenige Fragen, die Missverständnisse sichtbar machen. Wenn diese Fragen intern nicht klar beantwortet werden können, ist die Organisation meist noch mit Symptomen beschäftigt.

Diese vier Fragen sind für eine belastbare Entscheidung ausreichend, weil sie nicht die Oberfläche, sondern das Betriebsmodell prüfen:

• Wo entstehen heute doppelte oder widersprüchliche Kundenidentitäten, und welche Teams tragen die Folgekosten davon tatsächlich im Alltag?
• Welche Zugriffs- und Einwilligungsentscheidungen sind kanalübergreifend definiert, und welche werden pro Anwendung stillschweigend neu gelöst?
• Wie schnell kann ein neuer Service, Markt oder Partner angebunden werden, ohne Authentisierung, Registrierung und Profilprozesse neu zu entwerfen?
• Kann die Organisation gegenüber Kunden, Revision und Regulierung erklären, warum eine bestimmte Person zu einem bestimmten Zeitpunkt genau diesen Zugriff hatte?