Passwordless für B2C in der Skalierung: Guide 2026

1. Einführung: Passwordless für B2C in der Skalierung#

Passwordless für B2C in der Skalierung ist keine strategische Option mehr – es ist eine wichtige Anforderung für CIAM-Teams. Bei 500.000 Monthly Active Users (MAU) auf einer Basis von insgesamt 2 Millionen bedeutet jeder Prozentpunkt der Passkey-Adoption eine messbare Reduzierung der SMS-OTP-Kosten, weniger Account-Takeovers und eine höhere Checkout-Conversion. Dennoch fließen bei den meisten B2C-Deployments im großen Maßstab, die „Passkeys aktiviert“ haben, immer noch 90 % der täglichen Logins über Passwörter oder SMS-OTP.

Dieser Guide erklärt, warum generische CIAM-Passwordless-Rollouts in der Skalierung stagnieren, wie die Vier-Schichten-Referenzarchitektur aussieht, die die Passkey-Login-Rate beständig über 60 % hebt, und mit welchen Total Cost of Ownership (TCO) ein Fortune-500-Einkäufer bei 500k MAU planen sollte.

2. Warum generisches CIAM-Passwordless in der Skalierung stagniert#

Das Narrativ im Einkauf rund um Passwordless ist einheitlich: Jedes CIAM im Jahr 2026 bietet eine WebAuthn-API, jeder Anbieter verkauft „Passwordless“ in seiner Preisstruktur und jeder Analystenbericht listet Passkeys als Basisanforderung auf. Das Ergebnis, gemessen bei 500k MAU, ist konsistent. Die Passkey-Login-Rate pendelt sich bei etwa 5 % ein, das SMS-OTP-Volumen bewegt sich kaum und die prognostizierten Einsparungen bleiben aus. Der Grund dafür ist oft strukturell.

2.1 Der Trugschluss der Passkey-Adoption#

Der Corbado Passkey Benchmark 2026 misst vier Rollout-Szenarien bei der gleichen Web-Readiness-Obergrenze von 89 %. Ein Settings-only-Ansatz führt zu einer Passkey-Login-Rate von unter 1 %. Ein einfacher Nudge nach dem Login hebt sie auf etwa 4-5 % an. Eine optimierte Registrierung mit Device-Aware Prompting klettert auf 23 %. Ein Passkey-First Return Flow mit automatischer Erstellung und Identifier-First Recovery überschreitet 60 %. Das darunterliegende CIAM ändert an diesen Zahlen nichts. Was den Unterschied macht, sind die Prompt-Logik, die Device-Klassifizierung und das Login-Frontend, das darauf aufbaut.

Dasselbe Unternehmen, das denselben Auth0- oder Cognito-Mandanten nutzt, kann an beiden Enden dieser Leiter landen – je nachdem, ob das Team die Orchestration-Muster, die der Benchmark dokumentiert, im Custom-Frontend umsetzt. Das ist der Adoptions-Trugschluss: „Die Plattform unterstützt Passkeys“ bedeutet nicht automatisch „Die Plattform erreicht eine erfolgreiche Passkey-Adoption in der Skalierung.“

2.2 Fragmentierung im Device-Stack#

Bei 500k MAU in einer traditionellen B2C-Zielgruppe ist die Device-Population alles andere als homogen. Der Corbado Passkey Benchmark 2026 misst eine Web-Registrierung beim ersten Versuch von 49-83 % auf iOS, 41-67 % auf Android, 41-65 % auf macOS und nur 25-39 % auf Windows.

Diese Lücke liegt nicht nur an den Vorlieben der User. Sie spiegelt den jeweiligen Ökosystem-Stack wider. iOS bündelt Browser, Authenticator und Credential Provider sehr eng. Windows Hello ist noch kein Pfad für Conditional Create und das Speichern von Passkeys in Edge wurde erst Ende 2025 eingeführt. Eine realistische Kalkulation muss diese Aspekte einbeziehen, einschließlich Smart Prompting und Cross-Device-Usage zwischen Mobile und Desktop.

2.3 Pre-Identifier-Blindness#

Bei der Consumer-Authentifizierung ist der User anonym, bis er eine E-Mail-Adresse oder einen Usernamen eingibt. Wenn ein Passwordless-Prompt ihn verwirrt oder das Overlay eines Passwort-Managers den Autofill blockiert, bevor er diesen Punkt erreicht, zeichnet das Backend nichts auf. Standard-CIAM-Logs wurden nicht für Client-seitige Telemetrie entwickelt, sodass die Fehler, die die Adoption in der Skalierung behindern, außerhalb des Reporting-Rahmens des IDPs (einschließlich Backend-Logging) liegen.

3. Die Passkey Adoption Ladder bei 500k MAU#

Für ein B2C-Deployment bei 500k MAU auf einer Basis von 2 Millionen Usern ist das operative Ziel, die Adoption Ladder hinaufzuklettern, anstatt das CIAM auszutauschen. Jedes Level entspricht einem spezifischen Rollout Shape, nicht einem anderen Anbieter.

Passkey Adoption Ladder (Corbado Passkey Benchmark 2026)

Der nicht-lineare Sprung wird offensichtlich, wenn man dieselbe Readiness-Obergrenze gegen die vier Rollout-Shapes aufträgt:

Die meisten CIAM-nativen Rollouts enden auf den Baseline-Ebenen, weil das Out-of-the-box-Passwordless-UIs eben liefern: einen einzigen Toggle nach dem Login, kein Device-Aware Prompting, keine Identifier-First Recovery für neue Devices und keine automatische Erstellung nach einem Login über ein gespeichertes Passwort. Der Aufstieg zu den Managed- und Advanced-Leveln erfordert segmentierte Enrollment-Nudges, Conditional Create dort, wo das Ökosystem es unterstützt (derzeit am stärksten auf iOS, praktikabel auf macOS, fragmentiert auf Android, eingeschränkt auf Windows) und die One-Tap-Erkennung wiederkehrender Devices, um Assisted Logins zu fördern.

4. Referenzarchitektur für Passwordless B2C in der Skalierung#

Passwordless in der Skalierung ist eine Vier-Ebenen-Konstruktion mit dem CIAM als Fundament. Jede Ebene hängt architektonisch von der darunter liegenden ab – das folgende Diagramm zeigt die Pyramide und was jede Komponente beiträgt:

Jede Schicht spielt eine eigene Rolle. Das CIAM bleibt das System of Record. Ein Passkey-Orchestration-Overlay kümmert sich um das intelligente Prompting. Ein Observability-Layer erfasst den Client-seitigen Vorgang. Ein Fallback-Layer fängt Umgebungen auf, die heute noch keine Passkey-Flows abschließen können. Die folgenden Abschnitte schlüsseln jede Schicht im Detail auf.

4.1 Identity Layer: CIAM als System of Record#

Das CIAM speichert den User-Record, die Session, OAuth/OIDC-Token, den Social Login, die MFA-Policy und den Consent. Für 500k-MAU-B2C-Deployments bleiben die vorherrschenden Optionen Auth0, Amazon Cognito, Ping Identity, Ory, FusionAuth und selbstgebaute IDPs auf Basis von Keycloak. Die Wahl hier ist entscheidend für die Lizenzierung und die Ökosystem-Integration, jedoch weniger für die Passkey-Adoption an sich. Siehe die vollständige CIAM-Anbieter-Evaluierung 2026 für Preisstufen, KI-Agenten-Identity-Unterstützung und TCO bei 500k MAU.

4.2 Passkey Orchestration Layer#

Im Orchestration-Layer entscheidet sich der Erfolg von Passwordless in der Skalierung. Er fängt das Authentifizierungsereignis ab, bevor der WebAuthn-Prompt ausgelöst wird, klassifiziert Hardware, OS, Browser und Credential-Provider des Devices und leitet den User in eine Journey, die genau auf diese Umgebung abgestimmt ist.

In der Praxis ist der Orchestration-Layer bei 500k MAU fast immer eine Custom-Frontend-Implementierung, die vor dem CIAM sitzt und ein maßgeschneidertes Login-UI rendert. Das zugrunde liegende CIAM kümmert sich weiterhin um Credential-Speicherung, Session und OAuth/OIDC, aber das Team besitzt den Login-Einstiegspunkt, die Device-Aware Prompt-Logik und den Recovery-Flow. Der Grund dafür ist strukturell: Enterprise-B2C-Teams benötigen volle Kontrolle über Branding, Conversion-kritische Texte, A/B-Testing und die Segmentierungsregeln, die bestimmen, welcher User welchen Prompt sieht. Eine von einem Anbieter gerenderte Login-Seite lässt in der Skalierung selten dieses Maß an Anpassung zu.

Konkrete Muster, die der Custom Orchestration Layer implementieren muss:

• Device- und Capability-Klassifizierung: Das Abfragen von Device-Hardware, OS, Browser und Credential Provider, bevor ein WebAuthn-Prompt ausgegeben wird, sodass User in Umgebungen, die laut Benchmark fehlschlagen werden, von Sackgassen-Flows ferngehalten werden.
• Conditional Create: Die automatische Registrierung eines Passkeys nach einem erfolgreichen, durch einen Passwort-Manager unterstützten Login auf kompatiblen Stacks. Dies entfernt den expliziten Enrollment-Prompt auf iOS und gängigen macOS-Konfigurationen komplett.
• One-Tap Return Flow: Das Wiedererkennen von wiederkehrenden Devices durch datenschutzfreundliche Device-Trust-Signale und das Anbieten einer Single-Tap-Passkey-Authentifizierung beim nächsten Besuch.
• Identifier-First Recovery: Das Routen von Windows-Usern – wo der Benchmark misst, dass 40-65 % der Identifier-First-Passkey-Erfolge immer noch über Cross-Device Authentication auf ein Smartphone ausweichen – in andere Recovery-Pfade als iOS- oder Android-User, bei denen nur 0-10 % diesen Weg nehmen.
• Gradual Rollout: Zielgruppenspezifische Ansprache nach OS-Version, Geografie oder User-Segment und das Ausrollen intelligenter Fallbacks ohne App-Releases.

Diese Schicht intern aufzubauen ist das dominante Muster bei 500k MAU, da die meisten großen B2C-Deployments bereits einen ausgefeilten Frontend-Stack und ein Inhouse-Design-System betreiben, welches der Login-Flow übernehmen muss. Der Kompromiss sind die laufenden Engineering-Kosten, um mit Browser-, OS- und Credential-Provider-Updates Schritt zu halten. Für Teams, die diese Schicht lieber kaufen als bauen möchten, bietet Corbado Connect dieselben Orchestration-Muster als Overlay auf jedem CIAM an, ohne dass eine Migration der User-Datenbank erforderlich ist. Beide Wege heben die Passkey-Registrierung in Richtung der Advanced-Obergrenze von über 80 % und schalten die 60-90 % SMS-OTP-Kostenreduzierungen frei, die in der Skalierung stark ins Gewicht fallen.

4.3 Authentication Observability Layer#

Bei 500k MAU ist die Frage, die jedem CISO, CTO und Product Owner gestellt wird, der Passwordless betreibt, eindeutig: „Wie hoch ist unsere Sign-in Success Rate End-to-End? Warum brechen User bei der Registrierung ab? Sollten wir von 10 % auf 50 % skalieren? Können Sie dem Management den Impact zeigen?“ Die ehrliche Antwort bei den meisten großen B2C-Deployments lautet heute: „Wir wissen es nicht“ – nicht, weil die Daten nicht existieren, sondern weil sie in fünf separaten Systemen liegen, die nie dafür entwickelt wurden, rund um einen Passkey-Vorgang verknüpft zu werden.

Der typische Enterprise-Stack deckt jedes Puzzleteil einzeln ab:

• Die Frontend Content and Experience Plattform sieht Pageviews, Content-Varianten und Funnel-Events auf der Marketing-Ebene, aber nicht den WebAuthn-Vorgang an sich.
• Der FIDO- oder WebAuthn-Server sieht das Ergebnis der Credential-Registrierung und Assertion, aber nicht, was vorher oder nachher auf dem Device des Users passiert ist.
• Das Backend-APM sieht API-Latenzen und Traces, kann aber einen User-Abbruch nicht von einem biometrischen Timeout unterscheiden.
• Die Orchestration-Logs des Identity Providers sehen, welche Policy ausgelöst wurde und welchen Flow-Schritt der User erreicht hat, aber nicht, warum das Browser-Overlay nie erschienen ist.
• Das SIEM sieht Backend-Security-Events, aber die Fehler, die die Passkey-Adoption zerstören, passieren auf dem Client, bevor überhaupt ein Backend-Request gesendet wird.

Das folgende Diagramm mappt die Silos auf die unbeantworteten Fragen und die Oberfläche, auf der der Passkey-Login tatsächlich stattfindet:

Jedes dieser Tools ist Best-in-Class in seiner eigenen Kategorie, doch keines beantwortet die oben genannten Fragen allein. Die Fragen sitzen genau in der Lücke dazwischen. Die drei Conditional UI Measurement Points veranschaulichen das Ausmaß dieser Lücke: Serverseitig sieht der Passkey-Erfolg mit 97-99 % nahezu perfekt aus, die User-seitige Login-Completion-Rate liegt bei 90-95 % und die First-Suggestion-Interaction-Rate, bei der die User tatsächlich abspringen, liegt nur bei 55-90 %. Standard-Backend-Tools können die 35-Punkte-Spanne zwischen dem ersten und dem letzten Messpunkt nicht sehen.

Corbado Observe ist das einzige Produkt, das kombiniert, was jede der oben genannten Kategorien einzeln sehen kann. Es erfasst den gesamten Client-seitigen Vorgang mit dem Device-Kontext, der der Frontend-Plattform gehört, verbindet ihn mit dem Credential-Ergebnis, das der FIDO-Server aufzeichnet, klassifiziert den Fehlermodus, den der APM-Stack nicht interpretieren kann, und liefert ihn über einen einzigen Funnel und eine pro-User Timeline aus. Der Layer wird als leichtgewichtiges SDK bereitgestellt, das auf jedem WebAuthn-Server aufsetzt, unabhängig vom CIAM, ohne dass eine IDP-Migration erforderlich ist:

• Funnel und Journey Analytics: Sichtbarkeit von Entscheidungspunkten über Enrollment, Sign-in, Fallback und Append-Flows hinweg, wobei Drop-offs nach Device-, OS- und Browser-Kohorten aufgeschlüsselt werden – die Antwort auf „warum brechen User beim Enrollment ab“.
• Pro-User Debug Timeline: Suche nach einem User, spiele die Zeremonie ab, sehe exakte Branch-Transitions hinter einem Fehler – die Debugging-Zeit sinkt von ~14 Tagen auf ~5 Minuten.
• Readiness Insights: Browser-, OS-, OEM- und Authenticator-Readiness aufgeschlüsselt nach Kohorte und Rollout-Phase, sodass Suppression- und Ramp-Entscheidungen datengestützt statt reaktiv getroffen werden.
• Intelligente Fehlerklassifizierung: Unterscheidet User-Abbrüche von biometrischen Timeouts, Interferenzen durch Passwort-Manager, wiederholte Abbrecher und echte Device-Inkompatibilitäten, mit automatischer Klassifizierung von über 100 WebAuthn-Fehlertypen.
• Stakeholder Reporting: Dashboards, die dem CFO Einsparungen bei den SMS-Kosten und Conversion-Verbesserungen belegen, mit KI-gestützter Analyse von Rollout-Mustern und nächsten Fixes – die Antwort auf „können Sie dem Management den Impact zeigen“.

Corbado Observe wird mit einer reinen UUID-basierten, Zero-PII-Architektur (DSGVO-konform) ausgeliefert und ist die Schicht, die die vier oben genannten Management-Fragen in messbare KPIs verwandelt.

4.4 Fallback und Recovery Layer#

Selbst auf der Advanced-Stufe werden etwa 11 % der Versuche beim ersten Mal keinen Passkey-Flow abschließen. Der Fallback-Layer muss diese Realität akzeptieren, ohne standardmäßig auf ein Passwort zurückzufallen. Muster, die bei 500k MAU funktionieren:

• Cross-Device Authentication per QR: Schließt die Windows-Lücke und überbrückt vom Desktop zu einem Smartphone, das bereits einen Passkey enthält.
• Magic Link oder E-Mail OTP: Wird als sekundärer Faktor mit einem bewussten Reibungs-Budget beibehalten, sodass die Nutzung unter 5 % der monatlichen Logins bleibt.
• SMS-OTP als Auslaufmodell: Wird nur bei markierten Risikoereignissen erzwungen, nicht als primärer Passwordless-Ersatz, um die 60-90 % Kostenreduktion in der Skalierung zu sichern.
• Account Recovery über verifizierte sekundäre E-Mail oder Identity Proofing: Vermeidet die Reset-Schleifen von Security Keys, die die Produktivität des Supports ruinieren.

5. TCO von Passwordless in der Skalierung#

Procurement-Evaluierungen, die sich auf Lizenzgebühren konzentrieren, unterschätzen die wahren Kosten von Passwordless in der Skalierung oft um eine ganze Größenordnung. Die drei Treiber bei 500k MAU sind Plattformgebühren, Implementierungsaufwand und laufende Wartung.

Die Plattformgebühren variieren stark. Auth0 liegt bei 15k-30k USD/Monat für 500k MAU in branchenüblichen Enterprise-Verträgen. Die Passkey-fähige Essentials-Stufe von Cognito liegt bei etwa 7,3k USD/Monat, versteckt aber Engineering-Overhead. Stytch B2C Essentials und Clerk landen bei etwa 4,9k USD bzw. 9k USD.

Der Implementierungsaufwand ist der übersehene Kostenfaktor. Der native Aufbau von Passkeys auf einer CIAM-Plattform bei 500k MAU erfordert grob 25-30 FTE-Monate: etwa 5,5 FTE-Monate im Produktmanagement, 14 FTE-Monate in der Entwicklung und 8 FTE-Monate in QA. Plattformen mit vorgefertigter Passkey-UI komprimieren dies auf 5-10 FTE-Monate, erfordern aber dennoch Aufwand für die Adoptionsoptimierung. Bei API-First-Plattformen wie Ory muss die gesamte UX von Grund auf neu gebaut werden.

Die laufende Wartung ist der versteckte TCO-Multiplikator. Passkey-Vorgänge müssen kontinuierlich gegen neue OS-Releases, Browser-Updates und OEM-spezifische Bugs getestet werden. Plane etwa 1,5 FTE/Jahr für Post-Launch-Operations ein: Rollout-Management, plattformübergreifendes Retesting, Metadata-Updates und Support-Training. Auf Plattformen, die eine Custom UI erfordern, kommen 1-2 zusätzliche FTEs allein für die Frontend-Wartung hinzu.

6. Buy vs. Build bei Passwordless in der Skalierung#

Für Organisationen mit 500k MAU und mehr lautet die Entscheidung selten „kaufe ein neues CIAM“. Das bestehende CIAM ist bereits mit Abrechnung, Fraud-Detection, Marketing und Analytics integriert. Die eigentliche Entscheidung liegt eine Ebene höher: Baut man Orchestration und Observability intern auf oder nutzt man ein spezialisiertes Overlay?

Die Buy-vs-Build-Kalkulation für den Orchestration-Layer bei 500k MAU spricht durchgängig für die Adoption. Der interne Aufbau absorbiert 25-30 FTE-Monate, danach 1,5-3 FTEs pro Jahr im Betrieb, wobei die Passkey-Login-Rate typischerweise bei der Baseline- oder Managed-Stufe gedeckelt ist, da das Team nicht mit dem Release-Rhythmus von Browsern und Betriebssystemen Schritt halten kann. Der Overlay-Pfad bedeutet ein Integrationsprojekt von wenigen Wochen und profitiert kontinuierlich von Plattformverbesserungen, während sich das Ökosystem weiterentwickelt.

Die Buy-vs-Build-Rechnung ändert sich noch einmal für Organisationen, die Passkeys bereits nativ eingeführt haben und auf der Baseline-Stufe feststecken. Hier ist der Hebel größer, zunächst nur den Observability-Layer hinzuzufügen, die Drop-off-Punkte aufzudecken und dann zu entscheiden, ob die verbleibende Lücke intern oder mit einem Orchestration-Overlay geschlossen wird.

7. Rollout-Playbook für Passwordless B2C in der Skalierung#

Das Deployment-Muster, das bei 500k MAU konstant auf der Advanced-Stufe landet, folgt einer vierphasigen Struktur:

1. Zuerst instrumentieren: Implementiere Authentication Observability, bevor du den Prompt änderst. Erfasse die aktuelle Baseline-Stufe, segmentiert nach OS, Browser und Credential Provider, damit jede spätere Änderung an echten Daten gemessen wird und nicht an Schätzungen des Managements.
2. Device-Population segmentieren: Klassifiziere die Kohorte mittels Abfrage der Client-Capabilities. Identifiziere die Windows-, Android- und iOS-Subpopulationen und ihre spezifischen Fehlermodi.
3. Intelligent Prompting und Conditional Create ausrollen: Route jede Kohorte in ihren ertragreichsten Enrollment-Pfad. Unterdrücke Prompts in Umgebungen, bei denen der Benchmark und deine eigene Telemetrie ein Fehlschlagen vorhersagen. Wandle durch Passwort-Manager unterstützte Logins in automatische Passkey-Erstellungen um, wo der Stack dies unterstützt.
4. Wechsel zu Passkey-First Return: Sobald das Enrollment bei über 65 % liegt und die Nutzung steigt, drehe den Standard für wiederkehrende User auf One-Tap-Passkey-Authentifizierung mit Identifier-First Recovery für neue Devices. Dies ist die Stufe, auf der die Kurve der SMS-OTP-Kosten sinkt.

8. Fazit#

Passwordless für B2C in der Skalierung ist ein Orchestration-Problem, kein CIAM-Auswahlproblem. Die Anbieterlandschaft im Jahr 2026 hat die Lücken beim WebAuthn-Support geschlossen, aber die Spanne zwischen einer Passkey-Login-Rate von 5 % und über 60 % liegt in den Orchestration- und Observability-Layern, die auf dem IDP aufsetzen. Bei 500k MAU ist das der Unterschied zwischen einem festgefahrenen Piloten und einer Passwordless-Transformation, die jährliche SMS-Einsparungen von 50.000 bis 100.000 USD oder mehr verbucht, die Checkout-Conversion steigert und den größten verbleibenden Vektor für Account Takeovers eliminiert.

Für Fortune-500-Einkäufer, die bereits ein CIAM betreiben, ist der Schritt mit dem höchsten ROI zu instrumentieren, zu segmentieren und zu orchestrieren – nicht zu migrieren. Corbado Observe macht die aktuelle Stufe sichtbar. Corbado Connect schließt die Lücke zur Advanced-Stufe oben auf dem bestehenden CIAM. Zusammen machen sie Passwordless in der Skalierung von einem Versprechen im Einkauf zu einem einsatzbereiten KPI.

Ü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 →

Häufig gestellte Fragen#

Was erfordert Passwordless für B2C in der Skalierung wirklich?#

Passwordless für B2C in der Skalierung erfordert vier übereinanderliegende Schichten: ein CIAM als System of Record, einen Passkey-Orchestration-Layer, der Device, OS, Browser und Credential Provider klassifiziert, bevor WebAuthn gepromptet wird, einen Observability-Layer, der den Client-seitigen Ablauf erfasst, und einen Fallback-Layer für User in Umgebungen, die Passkey-Flows nicht abschließen können. Die meisten CIAM-Plattformen liefern nur die erste Schicht, weshalb native Rollouts bei einer Adoption von 5 bis 10 Prozent stagnieren.

Warum stagnieren Passwordless B2C-Rollouts bei 500k MAU bei niedriger Adoption?#

Generische CIAM-Passwordless-UIs fordern alle User auf die gleiche Weise auf, aber die Web-Passkey-Registrierung beim ersten Versuch reicht laut dem Corbado Passkey Benchmark 2026 von 49-83 % auf iOS bis hinunter zu 25-39 % auf Windows. Ohne Segmentierung des Device-Stacks, intelligentes Prompting und Identifier-First Recovery erzielen Deployments im Durchschnitt nur eine Passkey-Login-Rate von 5 bis 10 Prozent, selbst wenn die Plattform WebAuthn technisch unterstützt.

Wie hoch ist die TCO, um Passwordless B2C bei 500k MAU von Grund auf aufzubauen?#

Der native Aufbau von Passkeys auf einer CIAM-Plattform bei 500k MAU erfordert in der Regel 25-30 FTE-Monate in Produkt, Entwicklung und QA, plus 1,5 FTE pro Jahr für die laufende Wartung. Plattformgebühren in dieser Größenordnung reichen von rund 4.900 USD pro Monat für Stytch B2C Essentials bis zu 15.000-30.000 USD pro Monat für Auth0-Enterprise-Verträge, wobei die Passkey-fähigen Essentials von Cognito bei etwa 7.300 USD und Clerk bei etwa 9.000 USD liegen. Die versteckten Kosten entstehen durch das plattformübergreifende Retesting, wenn iOS, Android, Windows und macOS Updates veröffentlichen.

Welches Architekturmuster funktioniert am besten für Passwordless bei mehr als 1 Million Usern?#

Bei über 1 Million Usern ist das vorherrschende Muster ein CIAM plus ein Passkey-Orchestration-Overlay. Das CIAM bleibt das System of Record und der Orchestration-Layer übernimmt Device-Klassifizierung, Conditional Create, Identifier-First Recovery und Adoptionsanalysen. Dies vermeidet die Migration der User-Datenbank, erhält bestehende SIEM- und APM-Investitionen und schaltet die 60-90 prozentige Reduzierung der SMS-Kosten frei, die sich in der Skalierung stark summiert.