Passkeys im Unternehmensmaßstab: Praktische Lehren aus echten Implementierungen

Der Data Breach Investigations Report von Verizon stellte 2023 fest, dass 74 % aller Sicherheitsverstöße den menschlichen Faktor betrafen – Phishing, Credential-Diebstahl oder Missbrauch – bei einem Median-Schaden von 4,45 Millionen Dollar pro Vorfall. Passwörter sind die Ursache. Trotz jahrzehntelanger MFA-Pflicht werden SMS-Codes per SIM-Swap gekapert, Push-Benachrichtigungen durch Müdigkeit ausgenutzt und TOTP-Seeds über Man-in-the-Middle-Proxy wie Evilginx2 abgegriffen. Passkeys – basierend auf dem FIDO2-Standard – sind der erste Credential-Typ, der architektonisch phishing-resistent ist. Doch Enterprise-IT-Teams, die die glänzenden Vendor-Folien überfliegen, stellen schnell fest, dass die Produktionsrollout eine ganz andere Bestie ist.

Warum Passwörter – und die meisten MFA – weiterhin versagen

Das Problem ist nicht das Nutzerverhalten, sondern das Protokoll. Geteilte Geheimnisse (Passwörter, OTPs) müssen übertragen und serverseitig verifiziert werden, was auf jedem Hop Abhörflächen schafft. Phishing-resistente MFA-Kategorien nach NIST SP 800-63B erfordern besitzbasierte Authentifikatoren, bei denen der private Schlüssel das Gerät nie verlässt und die Relying-Party-Domain kryptografisch an die Challenge gebunden ist. Nur Hardware-Sicherheitsschlüssel (FIDO2/CTAP2) und Passkeys erfüllen diese Anforderung. Hardware-Schlüssel stagnierten jedoch im Consumer-Maßstab aufgrund von Kosten und UX-Reibung. Passkeys lösen das Verteilungsproblem, indem sie über Plattform-Keychains synchronisiert werden.

Was Passkeys technisch wirklich sind

Ein Passkey ist ein FIDO2-Credential, das als asymmetrisches Schlüsselpaar gespeichert wird. Der private Schlüssel lebt in einer Secure Enclave oder einem Plattform-Authentifikator – Apple Secure Enclave, Android Strongbox, Windows Hello TPM – und wird nie exportiert. Die Registrierung erzeugt eine Credential-ID, einen öffentlichen Schlüssel, der an den Relying-Party-Server gesendet wird, und optional eine Attestations-Zertifikatskette. Die Authentifizierung produziert eine signierte Assertion über eine Server-Challenge, die mit dem Origin (Schema + Host + Port) verkettet ist, sodass die Signatur auf jeder anderen Domain ungültig ist. Das ist die Anti-Phishing-Garantie.

Der WebAuthn Level 3 Spec fügt drei für Unternehmen relevante Credential-Typen hinzu:

Plattform-Passkeys (synchronisiert): Gespeichert in iCloud Keychain, Google Password Manager oder Windows Hello – über E2EE-Vaults geräteübergreifend synchronisiert. Bequem, aber das private Schlüsselmaterial verlässt die Gerätegrenze (verschlüsselt).
Plattform-Passkeys (gerätegebunden): An ein einzelnes Gerät TPM oder Secure Enclave gebunden. Hohe Assurance, überlebt einen Geräte-Wipe schlecht – das Credential ist einfach weg.
Roaming-Authentifikatoren (CTAP2): Physische Keys wie YubiKey 5 Series oder FEITIAN BioPass. Höchste Assurance, keine Synchronisation, und der Engpass für die großflächige Enterprise-Verteilung.

CTAP2.1 fügte PIN/UV Auth Protocol 2, Credential-Management (Liste/Löschen von Credentials auf dem Gerät) und Large Blob Storage hinzu. Enterprise-Deployments, die AAL3 (NIST) oder Authenticator Assurance Level 3 anstreben, schreiben in der Regel gerätegebundene oder Roaming-Authentifikatoren vor.

Realitäten der Enterprise-Einführung

Geräteverwaltung und Attestationsprüfung

Consumer-Passkey-Demos überspringen die Attestation; Enterprise-Deployments können das nicht. Attestation ermöglicht es der Relying Party, das Authentifikatormodell und den Hersteller zu überprüfen, bevor sie eine Registrierung akzeptiert. Microsoft Entra ID unterstützt die Durchsetzung von Attestationsrichtlinien – Sie können Passkey-Registrierungen auf YubiKey 5 Series oder bestimmte Android-Geräte mit hardwaregestützten Keys beschränken. Okta FastPass verknüpft die Geräteattestation über die Device Trust-Funktion ebenfalls mit dem MDM-Compliance-Status; ein macOS-Gerät, das nicht in Jamf Pro eingeschrieben ist, wird die Registrierung verweigern. Duo Trusted Endpoints erzwingen ähnliche Hürden über ihren Endpoint-Agenten.

Die Herausforderung: Attestationszertifikate müssen aus dem FIDO Metadata Service (MDS3) abgerufen, zwischengespeichert und erneut validiert werden. MDS3-Einträge haben einen Widerruf – ein kompromittiertes Authentifikatormodell kann auf eine Blockliste gesetzt werden, und Ihr Code muss das elegant handhaben, ohne bestehende Nutzer mit bereits registrierten Credentials auszusperren.

Plattformübergreifende Synchronisation und das Ecosystem-Fragmentierungsproblem

Apple, Google und Microsoft betreiben jeweils separate Passkey-Vaults. Ein Mitarbeiter, der auf seinem iPhone (iCloud Keychain) einen Passkey registriert, kann ihn auf seinem dienstlichen Windows 11-Laptop nicht nutzen, es sei denn, er verwendet einen geräteübergreifenden Authentifizierungsablauf – einen QR-Code-Scan über den Hybrid-Transport von CTAP2, der auf Bluetooth LE-Nähe angewiesen ist. Dies wird in Chrome 109+ und Safari 16+ auf allen Plattformen unterstützt, erfordert jedoch aktiviertes Bluetooth – etwas, das viele Enterprise-Endpoint-Härtungsrichtlinien deaktivieren.

Windows Hello for Business mit Entra ID Hybrid Join funktioniert gut innerhalb des Microsoft-Ökosystems. Aber eine gemischte BYOD+Corporate-Umgebung mit macOS, iOS, Android und Windows schafft bis zu vier separate Credential-Vaults, die verwaltet, überwacht und beim Offboarding berücksichtigt werden müssen. Keiner von ihnen föderiert nativ mit den anderen. Das Business-Passkey-Angebot von 1Password – verfügbar ab 1Password 8 – fungiert als Drittanbieter-Passkey-Manager, der Ökosysteme überbrückt, führt jedoch eine neue Vertrauensgrenze ein und erfordert die 1Password-Browsererweiterung, um WebAuthn-Aufrufe über die publicKeyCredential.isConditionalMediationAvailable()-API zu verarbeiten.

Mitarbeiter-Onboarding und -Offboarding

Onboarding ist die einfachere Hälfte. Die meisten IdPs unterstützen jetzt das bootstrapierte Passkey-Enrollment: Okta und Entra ID können einen zeitlich begrenzten Enrollment-Link senden, der es einem neuen Mitarbeiter ermöglicht, sofort nach der Identitätsüberprüfung über einen separaten Kanal (E-Mail-OTP oder manager-verifizierte Identitätsprüfung) einen Passkey zu registrieren. Die schwierige Hälfte ist das Offboarding. Das Widerrufen eines Passkeys erfordert das Widerrufen des Credentials bei der Relying Party – was eine sofortige serverseitige Operation ist –, aber das Credential könnte weiterhin in iCloud Keychain oder Google Password Manager existieren und Authentifizierungsversuche auslösen, die nun abgewiesen werden. Mitarbeiter, die im Bösen gehen, können ihre Passkeys nicht erfolgreich zur Authentifizierung mitnehmen, aber IT-Teams benötigen klare Runbooks, damit sie nicht den Widerruf des Credentials (erledigt) mit der Löschung des Credentials aus dem persönlichen Gerätevault des Nutzers (nicht Ihre Zuständigkeit) verwechseln.

Conditional-UI-Fallbacks

Nicht jeder Browser, jedes Gerät oder jede OS-Version unterstützt Passkeys. Safari führte Passkey-Unterstützung in iOS 16 / macOS Ventura 13 ein. Chrome brachte eine stabile Passkey-UI in Version 108. Firefox fügte Passkey-Unterstützung in Version 122 hinzu – auffällig spät. Windows Hello-Passkeys erfordern mindestens Windows 10 22H2 oder Windows 11 21H2. Ihr Authentifizierungsablauf muss Conditional Mediation implementieren – Aufruf von navigator.credentials.get() mit mediation: "conditional" –, um Passkeys im Autofill-Stil anzuzeigen, ohne dass Nutzer auf nicht unterstützten Browsern daran gehindert werden, auf Passwörter oder TOTP zurückzugreifen. Ein zu frühes Abschaffen des Fallbacks wird Nutzer von Legacy-Geräten aussperren und sofort Helpdesk-Tickets generieren.

Die Vendor-Landschaft

Microsoft Entra ID bietet heute die umfassendste Enterprise-Passkey-Geschichte. FIDO2-Sicherheitsschlüssel-Unterstützung (gerätegebunden) ist seit 2021 GA; synchronisierte Passkeys für Windows Hello wurden 2024 hinzugefügt. Attestationsfilterung, Number Matching für MFA-Push und Conditional Access Policies können die Passkey-Registrierung auf compliant Geräte beschränken. Der Schwachpunkt: Hybrid-Azure-AD-Join-Szenarien in älteren Windows-Server-AD-Umgebungen haben raue Kanten, insbesondere bei On-Premise-Apps, die über AD FS statt Entra laufen.

Okta unterstützt FIDO2 WebAuthn als Authentifikatorfaktor in Okta Verify FastPass. Die Device-Trust-Integrationen (Jamf, Microsoft Intune, VMware Workspace ONE) ermöglichen die Attestation, dass das Gerät MDM-enrolled ist, bevor die Registrierung zugelassen wird. Oktas Passkey-Unterstützung als primärer passwortloser Faktor (der Passwörter vollständig ersetzt, nicht nur als MFA-Step-Up) erreichte Ende 2024 GA.

Duo Security (Cisco) hat WebAuthn-Unterstützung als Duo-Faktor hinzugefügt, aber die Passkey-Geschichte für vollständig passwortlose Abläufe ist weniger ausgereift als bei Entra oder Okta. Duo glänzt in heterogenen Umgebungen, in denen nicht alle Apps SAML/OIDC unterstützen – seine Unix-PAM- und Windows-Credential-Provider-Plugins ermöglichen Passkey-ähnliche Assurance für SSH- und RDP-Flows.

1Password Business erlaubt das Speichern und Verwenden von Passkeys im 1Password-Vault mit teamweiten Freigaberichtlinien und Audit-Logs. Nützlich für gemeinsame Service-Accounts, birgt jedoch ein Vendor-Lock-in-Risiko und erfordert die Bewertung, ob Ihre AAL-Anforderungen einen softwarebasierten Passkey-Manager zulassen.

Häufige Fehlermodi in der Produktion

Attestationsrichtlinie blockiert Rollout: Die Aktivierung einer strikten Attestation vor der Überprüfung der Authentifikatormodelle Ihrer Geräteflotte wird Mitarbeiter auf älteren Android-Geräten oder nicht FIDO2-zertifizierter Hardware sperren. Beginnen Sie mit attestation: "indirect" und verschärfen Sie später.
Deaktiviertes Bluetooth killt geräteübergreifende Auth: Identifizieren Sie QR-Code-basierte geräteübergreifende Authentifizierungsabläufe, die auf BLE angewiesen sind, und schaffen Sie Ausnahmen oder leiten Sie Nutzer stattdessen zu Roaming-Hardware-Keys um.
iCloud Keychain synchronisiert mit persönlichen Geräten: Corporate-enrolled Macs teilen iCloud Keychain mit den privaten iPhones der Mitarbeiter, wenn dieselbe Apple ID verwendet wird. MDM-Profile können dies ohne eine Managed Apple ID nicht isolieren – planen Sie Ihr Apple Business Manager-Enrollment entsprechend.
RP-ID-Konflikt bricht Drittanbieter-Apps: Apps, die mit einer Relying-Party-ID von app.company.com registriert sind, werden Passkeys ablehnen, die gegen company.com registriert wurden, und umgekehrt. Überprüfen Sie vor dem Rollout alle Ihre SP-/RP-ID-Konfigurationen.
Kein Account-Recovery-Pfad: Ein verlorenes Gerät mit einem gerätegebundenen Passkey und keinem Backup-Authentifikator bedeutet eine helpdesk-gestützte Identitäts-Neuüberprüfung von Grund auf. Definieren Sie die Recovery-SLA vor dem Go-Live.

Schritt-für-Schritt-Rollout-Framework

Das folgende Framework geht von Entra ID oder Okta als IdP aus, einer gemischten Windows/macOS/iOS/Android-Flotte und dem Ziel, Passwörter als primären Faktor innerhalb von 18 Monaten zu eliminieren.

Monat 1-2 – Audit: Inventarisieren Sie Authentifikatormodelle in Ihrer Flotte via MDM. Überprüfen Sie Browserversionen. Kartieren Sie jede Authentifizierungsmethode der Anwendungen (SAML, OIDC, Legacy NTLM). Identifizieren Sie AAL-Anforderungen pro Anwendungstier.
Monat 2-3 – Richtliniendesign: Definieren Sie, welche Nutzersegmente synchronisierte vs. gerätegebundene Passkeys erhalten. Erstellen Sie den Attestationsrichtlinienentwurf (beginnen Sie mit indirect). Definieren Sie Account-Recovery-Runbooks. Bestätigen Sie, dass Conditional Access / Adaptive MFA Policies die Registrierung nicht blockieren.
Monat 3-5 – Pilot: Rollout an IT-Mitarbeiter und Early Adopters. Aktivieren Sie Passkeys als optionalen zusätzlichen Faktor neben Passwörtern. Messen Sie Registrierungserfolgsraten, geräteübergreifende Authentifizierungsversuche und Fallback-Raten in Ihren IdP-Logs.
Monat 5-10 – Breite Registrierung: Senden Sie Enrollment-Kampagnen mit Self-Service-Enrollment-Links. Ziel: 80 % der Belegschaft registriert. Halten Sie Passwörter als Fallback aktiv. Überwachen Sie das Helpdesk-Ticketvolumen – Account-Recovery- und verlorene Passkey-Tickets sind Ihr Signal.
Monat 10-18 – Passworteliminierung: Erzwingen Sie bei registrierten Nutzern Conditional Access Policies, die Passkey (FIDO2) als Authentifizierungsmethode vorschreiben. Deaktivieren Sie die Passwortauthentifizierung für abgedeckte Anwendungstiers. Halten Sie einen Break-Glass-Recovery-Prozess mit Hardware-Token für Admin-Konten aufrecht.

Was dem Ecosystem noch fehlt

Passkeys sind nicht abgeschlossen. Mehrere Lücken bestehen Stand Mitte 2025:

Kein nativer Enterprise-Passkey-Roaming-Standard: Es gibt keinen FIDO Alliance-Standard zum Migrieren von Passkeys zwischen Plattformen (z. B. iCloud Keychain zu Google Password Manager). Vendor-Lock-in ist real.
Begrenzte SSH-/RDP-/VPN-Unterstützung: WebAuthn ist eine Browser-API. SSH-Agents, die FIDO2-Hardware-Keys unterstützen (via ssh-keygen -t ecdsa-sk), existieren, aber synchronisierte Passkeys können ohne eine Bridge-Schicht nicht in nativen SSH-Flows verwendet werden.
Attestations-Widerrufsbehandlung ist unreif: Die meisten IdP-Implementierungen behandeln MDS3-Widerrufsereignisse für vorhandene registrierte Credentials nicht elegant. Sie benötigen benutzerdefinierte Logik oder eine Vendor-Zusage.
Firefox-Verzögerung: Die Passkey-Unterstützung von Firefox (v122+) hat noch UX-Kanten bei Conditional Mediation und geräteübergreifenden Abläufen, und ihr Marktanteil in Enterprise-Umgebungen – insbesondere in Behörden und Finanzdienstleistungen – ist nicht trivial.

Die Enterprise-Passkey-Adoption ist über die Early-Adopter-Phase hinaus – Microsoft, Google und Okta liefern alle GA-Features. Die Teams, die erfolgreich sind, behandeln es als Infrastrukturmigration, nicht als App-Update: zuerst auditieren, unermüdlich pilotieren und Fallbacks länger aktiv lassen, als es sich angenehm anfühlt. Die Phishing-Resistenz am anderen Ende ist die operativen Kosten wert.