Apple integriert Browser, Authentifikator und Passwort-Manager eng; Passkey-Autofill ist bereits vertraut.
Conditional Create-Rate
Die Conditional Create-Rate misst, wo Browser-, Authentifikator- und Credential-Provider-Support die Passkey-Erstellung automatisieren: geräuschlos nach einem erfolgreichen Passwort-Login, ohne zusätzliche Aufforderung. Sie ist eher als Adoptionsbeschleuniger für ausgereifte Passkey-Rollouts zu verstehen, nicht als eigenständiger Ersatz für die Registrierungsstrategie.
Conditional Create
Conditional Create automatisiert die Passkey-Erstellung nach erfolgreichem Passwort-Login, sofern der richtige Ecosystem-Stack vorhanden ist (siehe Prerequisite-Stack unten für die vollständige Gating-Logik). Die vier Plattform-Kacheln unten gehen von folgenden Credential-Managern je OS aus: iCloud Keychain (Apple Passwords) auf iOS / macOS, Google Password Manager auf Android und Chrome / Google Password Manager auf Windows. Die Spanne ist ein Add-on-Benchmark für ausgereifte Deployments mit bestehenden, expliziten Registrierungs-Prompts; Standalone-Deployments können stark abweichen.
Chrome und Safari decken die Browser-Seite gut ab; die Wahl des Desktop-Passwort-Managers ist gemischter als bei iOS.
Chrome / Google Password Manager kann funktionieren; Samsung Internet, Samsung Pass und Standard-Provider-Setups fragmentieren die Bereitschaft.
Chrome / Google Password Manager kann funktionieren; Windows Hello ist kein Conditional Create-Pfad und Edge verringert die Bereitschaft.
Ecosystem-Interpretation
iOS ist die stärkste Umgebung, da Browser, Authenticator, Passwort-Manager und Passkey-Autofill-Verhalten eng integriert sind. macOS ist ebenfalls brauchbar, aber durchmischter. Windows und Android zeigen aktuell die größte Reibung: Windows Hello ist kein Pfad für Conditional Create, während Android stark vom gewählten Credential-Provider, dem Hersteller und den resultierenden Standardeinstellungen abhängt. In Samsung-lastigen Märkten reicht die reine Verfügbarkeit des Google Password Manager nicht aus, wenn der bevorzugte Dienstpfad für den Nutzer nicht konfiguriert ist.
Prerequisite-Stack
Browser-Support ist nur die erste Hürde. Conditional Create erfordert auch Provider- / Authenticator-Support, einen kürzlichen Login per Autofill gespeicherter Passwörter sowie das Nichtvorhandensein eines Passkeys im aktiven Credential-Provider. Siehe die Corbado Conditional Create-Analyse.
Browser-Capability-Aufteilung
Der Capability-Support im Dezember 2025 erklärt die browserseitige Obergrenze, aggregiert über alle Betriebssysteme. Diese Tabelle zeigt rein, ob der Browser Conditional Create bereitstellt, unabhängig vom zugrundeliegenden Authenticator oder OS. iOS Chrome, Edge und Firefox sind als WebKit-Kontexte separat ausgewiesen; Firefox außerhalb von iOS zeigt in diesen Daten keinen Support für Conditional Create. Die Autofill-Quote gespeicherter Passwörter wird hierbei noch nicht gemessen.
| Browser | Support |
|---|---|
| Chrome | 96% |
| Safari | 95% |
| Edge | 4% |
| Chrome iOS WebKit | 98% |
| Samsung Internet | 0% |
| Firefox | 0% |
- Browser-Support wird separat ausgewiesen, da er notwendig, aber nicht hinreichend ist. Der gewählte Credential-Provider und Authenticator müssen Conditional Create ebenfalls unterstützen.
- Die Autofill-Quote wird hier nicht veröffentlicht. Ältere Websites mit vielen wiederkehrenden Nutzern und korrekt implementierten Passwortfeldern können eine höhere Obergrenze für das Autofill gespeicherter Passwörter aufweisen.
Weiterführende Literatur
Kuratierte Corbado-Forschung und Primärquellen.
- How adidas improved sign-in with passkeys Fallstudie, die zeigt, wie Passkeys und Passkey-Prompts die Login- und Kontoerstellungsabläufe verändert haben.
- Conditional Create for Passkeys: Support & Effectiveness Plattformunterstützung, Voraussetzungen und strategischer Wert des Upgrades von Passwort-Nutzern zu Passkey-Nutzern.
- Automatic Passkey Upgrade Übersicht über automatische Passkey-Upgrade-Muster, um Nutzer gespeicherter Passwörter zu Passkeys zu migrieren.