--- url: 'https://www.corbado.com/de/blog/passwordless-b2c-skalierung' title: 'Passwordless für B2C in der Skalierung: Guide 2026' description: 'Passwordless für B2C in der Skalierung, einfach erklärt. Referenzarchitektur, TCO und die Passkey Adoption Ladder für Enterprise-Deployments mit über 500k MAU.' lang: 'de' author: 'Vincent Delitz' date: '2026-05-19T11:34:02.055Z' lastModified: '2026-05-19T12:28:03.675Z' keywords: 'passwordless für b2c, passwortlose authentifizierung in der skalierung, b2c passkeys enterprise, passwordless ciam, 500k mau passkeys, passkey orchestration' category: 'Passkeys Strategy' --- # Passwordless für B2C in der Skalierung: Guide 2026 ## Key Facts - **Passwordless in der Skalierung stagniert bei 5-10 % Passkey-Login-Rate**, wenn sich Teams ausschließlich auf die native WebAuthn-API eines CIAM verlassen, unabhängig davon, ob die zugrunde liegende Plattform Auth0, Cognito, Ping Identity oder Clerk ist. - **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 – eine 2-fache Spreizung, die flache CIAM-UIs ignorieren. - **Das Advanced Rollout Shape** (Passkey-First Return Flow mit automatischer Erstellung und Identifier-First Recovery) hebt die Passkey-Login-Rate bei derselben Web-Readiness-Obergrenze von 89 % auf über 60 % an. - **Bei 500k MAU** führt eine Reduzierung der SMS-OTPs um 60-90 % zu jährlichen Einsparungen von 50.000 bis 100.000 USD oder mehr, wobei sich der Orchestration-Layer in der Regel bereits im ersten Quartal amortisiert. - **Der native Aufbau von Passwordless** in einer CIAM-Plattform erfordert etwa 25-30 FTE-Monate in Produkt, Entwicklung und QA sowie 1,5 FTE pro Jahr für die fortlaufende plattformübergreifende Wartung. - **Kein Anbieter im CIAM-Vergleich 2026** liefert nativ und standardmäßig Device-Aware Prompting, Identifier-First Recovery und Conditional Create – diese Funktionen befinden sich in einem separaten Orchestration-Layer. ## 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](https://www.corbado.com/blog/passkey-adoption-business-case) eine messbare Reduzierung der [SMS-OTP-Kosten](https://www.corbado.com/blog/sms-cost-reduction-passkeys), weniger Account-Takeovers und eine höhere [Checkout-Conversion](https://www.corbado.com/blog/logins-impact-checkout-conversion). Dennoch fließen bei den meisten B2C-Deployments [im großen Maßstab](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview), 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](https://www.corbado.com/kpi/passkey-usage-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](https://www.corbado.com/glossary/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](https://www.corbado.com/kpi/passkey-usage-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](https://www.corbado.com/blog/world-passkey-day-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](https://www.corbado.com/blog/auth0-passkeys-analysis)- oder [Cognito](https://www.corbado.com/blog/passkeys-amazon-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](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/passkey-benchmark-2026/passkey-enrollment-rate) misst eine Web-Registrierung beim ersten Versuch von 49-83 % auf [iOS](https://www.corbado.com/blog/webauthn-errors), 41-67 % auf [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/webauthn-errors) bündelt Browser, [Authenticator](https://www.corbado.com/glossary/authenticator) und Credential Provider sehr eng. [Windows Hello](https://www.corbado.com/glossary/windows-hello) ist noch kein Pfad für [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys) 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](https://www.corbado.com/blog/passkeys-vs-password-managers) den Autofill blockiert, bevor er diesen Punkt erreicht, zeichnet das Backend nichts auf. Standard-CIAM-Logs wurden nicht für [Client-seitige Telemetrie](https://www.corbado.com/observe) 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)** | **Rollout Shape** | **Enrollment** | **Usage** | **Passkey Login Rate** | | ---------------------------------------- | -------------- | --------- | ---------------------- | | **Settings-only availability** (Passive) | \~4% | \~5% | <1% | | **Simple post-login nudge** (Baseline) | \~25% | \~20% | \~4-5% | | **Optimized enrollment** (Managed) | \~65% | \~40% | \~23% | | **Passkey-first return flow** (Advanced) | \~80% | \~95% | >60% | 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](https://www.corbado.com/blog/conditional-create-passkeys) dort, wo das Ökosystem es unterstützt (derzeit am stärksten auf iOS, praktikabel auf macOS, fragmentiert auf [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), eingeschränkt auf Windows) und die [One-Tap](https://docs.corbado.com/corbado-connect/features/one-tap-login)-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](https://www.corbado.com/glossary/social-login), die MFA-Policy und den Consent. Für 500k-MAU-B2C-Deployments bleiben die vorherrschenden Optionen [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), [Amazon Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito), Ping Identity, Ory, FusionAuth und selbstgebaute IDPs auf Basis von [Keycloak](https://www.corbado.com/blog/keycloak-passkeys). Die Wahl hier ist entscheidend für die Lizenzierung und die Ökosystem-Integration, jedoch weniger für die [Passkey-Adoption](https://www.corbado.com/blog/passkey-adoption-business-case) an sich. Siehe die vollständige [CIAM-Anbieter-Evaluierung 2026](https://www.corbado.com/blog/best-ciam-solutions) 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](https://www.corbado.com/passkey-benchmark-2026/passkey-authentication-success-rate) immer noch über Cross-Device Authentication auf ein Smartphone ausweichen – in andere Recovery-Pfade als [iOS](https://www.corbado.com/blog/webauthn-errors)- oder [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/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](https://www.corbado.com/blog/passkey-creation-best-practices) in Richtung der Advanced-Obergrenze von über 80 % und schalten die 60-90 % [SMS-OTP-Kostenreduzierungen](https://www.corbado.com/blog/sms-cost-reduction-passkeys) frei, die in der Skalierung stark ins Gewicht fallen. ### 4.3 Authentication Observability Layer Bei 500k MAU ist die Frage, die jedem [CISO](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/integrate-passkeys-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](https://www.corbado.com/glossary/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](https://www.corbado.com/passkey-benchmark-2026/conditional-ui-usage) 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](https://www.corbado.com/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](https://www.corbado.com/blog/webauthn-server-implementation) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkeys-vs-password-managers), 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](https://www.corbado.com/blog/sms-cost-reduction-passkeys) 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](https://www.corbado.com/blog/digital-identity-guide)**: Vermeidet die Reset-Schleifen von [Security Keys](https://www.corbado.com/glossary/security-key), 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](https://www.corbado.com/blog/auth0-passkeys-analysis) liegt bei 15k-30k USD/Monat für 500k MAU in branchenüblichen Enterprise-Verträgen. Die Passkey-fähige Essentials-Stufe von [Cognito](https://www.corbado.com/blog/passkeys-amazon-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](https://www.corbado.com/glossary/aaguid)-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](https://www.corbado.com/blog/passkeys-buy-vs-build-guide) 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](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill) 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](https://www.corbado.com/blog/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](https://www.corbado.com/blog/webauthn-client-capabilities). Identifiziere die Windows-, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)- und [iOS](https://www.corbado.com/blog/webauthn-errors)-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](https://docs.corbado.com/corbado-connect/features/one-tap-login)-Passkey-Authentifizierung mit Identifier-First Recovery für neue Devices. Dies ist die Stufe, auf der die Kurve der [SMS-OTP-Kosten](https://www.corbado.com/blog/sms-cost-reduction-passkeys) 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](https://www.corbado.com/kpi/passkey-usage-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](https://www.corbado.com/glossary/account-takeover) 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](https://www.corbado.com/observe) macht die aktuelle Stufe sichtbar. [Corbado Connect](https://www.corbado.com/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. ## 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.