Passkey vs. Security Key: Unterschiede & Auswahlhilfe

Passkeys vs Security Keys: Vergleichen Sie FIDO2-Anmeldedatentypen nach Vertrauensniveau, Attestierung, Wiederherstellung und Bereitstellungsmodellen für Unternehmen. Erfahren Sie, welche Option zu Ihrer Umgebung passt.

Was sind Passkeys und Sicherheitsschlüssel?

Im Jahr 2021 führte Colonial Pipeline einen Ransomware-Vorfall auf ein kompromittiertes VPN-Passwort zurück und zahlte laut einer Mitteilung des DOJ etwa 4,4 Millionen US-Dollar Lösegeld. Das ist die operative Realität von anmeldeinformationsbasiertem Initialzugriff: Angreifer benötigen keine Zero-Days, wenn sie Phishing betreiben, Anmeldedaten wiederverwenden oder Credential Stuffing gegen passwortbasierte Authentifizierung durchführen können.

Sowohl Passkeys als auch physische Sicherheitsschlüssel existieren, um diese Lücke zu schließen. Sie nutzen die gleiche kryptografische Grundlage, aber der Unterschied in der Speicherung und Verwaltung der Anmeldeinformationen ist entscheidend, wenn Sie ein Unternehmen schützen.

Ein Passkey ist ein FIDO-Authentifizierungsnachweis, der Passwörter durch kryptografische Schlüsselpaaren ersetzt. Laut FIDO Alliance ermöglichen Passkeys es Nutzern, sich bei Apps und Websites mit demselben Verfahren anzumelden, das sie zum Entsperren ihres Geräts verwenden: Biometrie, PIN oder Muster. Passkeys gibt es in zwei Formen:

• Synchronisierte Passkeys speichern Anmeldeinformationen in einem cloudbasierten Credential Manager und synchronisieren sie über Ihre Geräte hinweg.
• Gerätegebundene Passkeys binden den privaten Schlüssel an ein einzelnes Gerät. Er verlässt diese Hardware nie.

In der Praxis bestimmt das Speichermodell die meisten unternehmensspezifischen Abwägungen.

Ein Hardware-Sicherheitsschlüssel (auch Roaming-Authenticator genannt) ist ein externes Hardwaregerät, das über USB, NFC oder Bluetooth mittels FIDO2 CTAP (Client-to-Authenticator Protocol) mit Browsern und Betriebssystemen kommuniziert. Denken Sie an YubiKeys, Smartcards und ähnliche Token. Diese sind per Definition gerätegebunden: Der private Schlüssel wird in einem Hardware-Sicherheitsmodul gespeichert und kann nicht exportiert oder kopiert werden.

Beide Technologien teilen die gleiche kryptografische Grundlage. Jede Anmeldeinformation ist eindeutig, an eine bestimmte Service-Domain gebunden und basiert auf standardisierter Public-Key-Kryptografie. Biometrische Daten verlassen Ihr Gerät nie. Der Server speichert nur den öffentlichen Schlüssel. Dieses gemeinsame Design macht beide Optionen für das gleiche grundlegende Sicherheitsproblem relevant.

Wie Passkeys und Sicherheitsschlüssel mit Cybersecurity zusammenhängen

Der 2025 Verizon DBIR berichtet, dass Missbrauch von Anmeldeinformationen einen großen Anteil am Initialzugriff hat: 22 % der Sicherheitsverletzungen beinhalten Missbrauch von Anmeldeinformationen als Methode für den Erstzugriff, laut dem Verizon DBIR. Das entspricht den Beobachtungen in der Praxis: Sobald ein Angreifer gültige Anmeldeinformationen besitzt, kämpfen Sie gegen Ihre eigenen Zugriffswege.

Sowohl Passkeys als auch Sicherheitsschlüssel sind von Haus aus resistent gegen Phishing. Wie die WebAuthn-Spezifikation definiert, ist jede Authentifizierungsbestätigung auf eine bestimmte Website-Domain beschränkt, sodass eine Phishing-Seite auf einer anderen Domain keine gültige Bestätigung erhalten kann. Dies verhindert Credential Phishing, Credential Stuffing und Adversary-in-the-Middle-Angriffe auf Protokollebene, weshalb Behörden und regulierte Sektoren auf phishing-resistente MFA drängen.

Deshalb schreibt OMB M-22-09 nun vor, dass Bundesbehörden ausschließlich phishing-resistente Authentifizierung verwenden. Die Frage für Ihre Organisation ist nicht, ob Sie FIDO2-Authentifizierung einführen, sondern welches Implementierungsmodell zu Ihrem Risikoprofil passt. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

Passkey vs. Sicherheitsschlüssel im Überblick

Funktion	Passkey (synchronisiert)	Physischer Sicherheitsschlüssel
Speicherung der Anmeldeinformationen	Cloud Credential Manager (Apple Keychain, Google Password Manager)	Hardware-Sicherheitsmodul auf physischem Token
Exportierbarkeit des Schlüssels	Synchronisiert über Geräte via Cloud-Infrastruktur	Nicht exportierbar; an Hardware gebunden
NIST Assurance Level	AAL2	AAL3
Phishing-Resistenz	Ja (FIDO2 Domain-Bindung)	Ja (FIDO2 Domain-Bindung)
Geräteattestierung	Nicht unterstützt (Cloud-Sync unterbricht Vertrauenskette)	Unterstützt (hardwarebasierte Herstellerzertifikate)
Wiederherstellungsmodell	Cloud-Kontowiederherstellung über Anbieter	Physischer Backup-Schlüssel oder Admin-gesteuerte Neueinrichtung
Benutzererlebnis	Transparent, funktioniert über synchronisierte Geräte hinweg	Erfordert physischen Token bei jeder Anmeldung
Hardwarekosten	Keine (softwarebasiert)	Token-Kauf pro Nutzer und Lebenszyklusmanagement
Plattformübergreifende Unterstützung	Abhängig vom Anbieter-Ökosystem	Universell (USB, NFC, BLE auf jeder FIDO2-Plattform)
Optimaler Einsatzbereich	Allgemeine Belegschaft, BYOD-Umgebungen	Privilegierte Admins, regulierte Branchen, AAL3-Konformität

Der Protokoll-Stack, das Speichermodell und die Attestierungsunterstützung jeder Option bestimmen Ihr Vertrauensniveau. So setzen sich diese Komponenten zusammen.

Wie FIDO2-Authentifizierung im Hintergrund funktioniert

Sowohl Passkeys als auch Sicherheitsschlüssel basieren auf demselben FIDO2-Protokoll-Stack, unterscheiden sich jedoch in der Speicherung, dem Schutz und der Verwaltung des zugrunde liegenden kryptografischen Materials. Das Verständnis dieser Komponenten hilft Ihnen, den richtigen Anmeldetyp dem passenden Risikoniveau zuzuordnen.

FIDO2-Protokoll-Stack

FIDO2 besteht aus zwei Kernkomponenten, die in den FIDO-Spezifikationen definiert sind:

1. W3C Web Authentication (WebAuthn): Die Browser-API, die FIDO-Authentifizierung auf Websites und Anwendungen ermöglicht.
2. Client-to-Authenticator Protocol (CTAP): Das Protokoll, das externen Authenticatoren die Kommunikation mit FIDO2-fähigen Browsern und Betriebssystemen ermöglicht.

Diese beiden Ebenen sorgen für Origin-Bindung und den kryptografischen Nachweis, der starke, phishing-resistente Anmeldungen ermöglicht.

Architektur der Anmeldedatenspeicherung

Das Speichermodell ist der entscheidende Unterschied zwischen Passkeys und Sicherheitsschlüsseln. Jede Methode behandelt den privaten Schlüssel unterschiedlich:

• Hardware-Sicherheitsschlüssel speichern private Schlüssel in dedizierten Hardware-Sicherheitsmodulen (HSM), häufig unter Verwendung eines Trusted Platform Module (TPM)-Chips. Laut Microsoft Entra-Dokumentation ist das Schlüsselmateriel nicht exportierbar. Sie können es nicht kopieren, sichern oder synchronisieren.
• Synchronisierte Passkeys verwenden ein Betriebssystem oder eine Drittanbieter-Synchronisationsinfrastruktur, um kryptografische Schlüssel über Geräte hinweg zu replizieren. Der Enterprise Deployment Guide der FIDO Alliance weist darauf hin, dass dies eine Abhängigkeit von der Synchronisationsinfrastruktur des Passkey-Anbieters und dessen Sicherheitskontrollen schafft.

Diese Unterscheidung bei der Speicherung beeinflusst alle nachgelagerten Entscheidungen zu Attestierung, Compliance und Wiederherstellung.

Attestierung

Geräteattestierung ist eine Technik, die in FIDO- und WebAuthn-Protokollen integriert ist und es dem Authenticator ermöglicht, die Vertrauenskette vom Gerätehersteller kryptografisch zu verifizieren. Laut dem Attestation White Paper der FIDO Alliance erfordert dies ein hardwarebasiertes Herstellerzertifikat im sicheren Element des Authenticators.

Synchronisierte Passkeys können keine Geräteherkunft nachweisen, da die Cloud-Synchronisation diese kryptografische Kette unterbricht. Wenn Sie in Ihrer Identitätsplattform Attestierung erzwingen, qualifizieren sich nur gerätegebundene Anmeldeinformationen.

Compliance-Ausrichtung

NIST SP 800-63B-4 zieht eine klare Grenze. AAL2 erfordert phishing-resistente Authentifizierung, und sowohl synchronisierte Passkeys als auch Sicherheitsschlüssel können dies erfüllen. AAL3 verlangt einen nicht exportierbaren Authentifizierungsschlüssel, was synchronisierte Passkeys vollständig ausschließt.

Diese Komponenten spiegeln sich direkt im Anmeldeprozess wider und zeigen, wo sich die beiden Anmeldetypen unterschiedlich verhalten.

Registrierung, Authentifizierung und die Unterschiede

Der Authentifizierungsablauf für Passkeys und Sicherheitsschlüssel folgt demselben FIDO2-Muster. Der Unterschied zeigt sich in der Speicherung, Portabilität und Wiederherstellung der Anmeldeinformationen im Hintergrund.

Registrierung (beide Methoden)

Während der Registrierung generiert der Authenticator ein eindeutiges öffentliches/privates Schlüsselpaar, das an die Domain des Dienstes gebunden ist. Der private Schlüssel verbleibt auf dem Authenticator, und der Server speichert nur den öffentlichen Schlüssel.

Authentifizierung (beide Methoden)

1. Der Server sendet eine kryptografische Herausforderung.
2. Sie führen eine lokale Verifizierung durch: Fingerabdruckscan, Gesichtserkennung, PIN oder einen physischen Tastendruck.
3. Der Authenticator signiert die Herausforderung mit dem privaten Schlüssel.
4. Der Server validiert die Signatur mit dem gespeicherten öffentlichen Schlüssel.

Dieser gemeinsame Ablauf ist der Grund, warum beide Ansätze Phishing-Angriffe auf Protokollebene verhindern.

Portabilität

Mit einem physischen Sicherheitsschlüssel tragen Sie ein Token, das auf unbegrenzt vielen Geräten authentifiziert. Stecken Sie es in einen FIDO2-kompatiblen Browser oder tippen Sie es via NFC an, und Sie sind angemeldet.

Mit synchronisierten Passkeys werden Ihre Anmeldeinformationen automatisch über Geräte im Ökosystem Ihres Anbieters repliziert: Apple, Google oder ein Drittanbieter-Manager. Sie authentifizieren sich auf Ihrem Laptop, und derselbe Passkey funktioniert auf Ihrem Smartphone, ohne dass Sie etwas mitnehmen müssen. Plattformübergreifende Portabilität ist jedoch weiterhin uneinheitlich. Ein Ablauf, der auf Chrome/Windows funktioniert, kann sich auf Safari/macOS anders verhalten, und Unterschiede in der Browser-UX bleiben ein fortlaufender Reibungspunkt für Unternehmensbereitstellungen.

Sicherheitsgrenzen

Bei gerätegebundenen Anmeldeinformationen benötigt ein Angreifer Ihre Anmeldeinformationen, physischen Zugriff auf das Hardware-Token und die Fähigkeit, die lokale Authentifizierung zu umgehen.

Bei synchronisierten Anmeldeinformationen verschiebt sich die Sicherheitsgrenze zu Ihrem Cloud-Anbieter. Wenn ein Angreifer das Cloud-Konto durch Social Engineering oder Manipulation des Anbieter-Resets kompromittiert, kann er Anmeldeinformationen auf ein angreiferkontrolliertes Gerät synchronisieren.

Diese Verschiebung der Sicherheitsgrenze ist der Punkt, an dem operative Planung erforderlich ist. Beide Anmeldetypen bringen Abwägungen mit sich, die Sie vor der unternehmensweiten Durchsetzung berücksichtigen müssen – und diese Abwägungen sind nur relevant, wenn die von Ihnen genutzten Plattformen, Browser und Identitätsanbieter den gewählten Anmeldetyp tatsächlich unterstützen.

Wo Passkeys und Sicherheitsschlüssel heute unterstützt werden

Mit Stand 2025 haben Passkey- und Sicherheitsschlüssel-Lösungen einen praktischen Wendepunkt in Verbraucher- und Unternehmensökosystemen erreicht.

• Betriebssysteme und Browser. Apple (iOS 16+, macOS Ventura+), Google (Android 9+) und Microsoft (Windows 10/11 via Windows Hello) unterstützen die Erstellung und Authentifizierung von Passkeys nativ. Jeder große Browser, einschließlich Chrome, Safari, Edge und Firefox, unterstützt WebAuthn. Laut der FIDO Alliance sind über 95 % der iOS- und Android-Geräte jetzt passkey-fähig, und mehr als eine Milliarde Nutzer haben mindestens einen Passkey aktiviert.
• Identitätsanbieter. Unternehmens-IdPs haben FIDO2-Unterstützung flächendeckend eingeführt. Microsoft Entra ID unterstützt gerätegebundene Passkeys auf FIDO2-Sicherheitsschlüsseln und in Microsoft Authenticator, mit synchronisierten Passkeys in der Vorschau. Okta unterstützt sowohl Passkeys als auch FIDO2-Sicherheitsschlüssel als phishing-resistente Authenticatoren, mit Attestierungsdurchsetzung und AAGUID-basierten Richtlinienkontrollen. Cisco Duo, Ping Identity und andere große IdPs unterstützen ebenfalls FIDO2-Registrierung für beide Anmeldetypen. Ihr IdP ist also wahrscheinlich kein Hindernis.
• Hardware-Sicherheitsschlüssel funktionieren universell auf FIDO2-kompatiblen Plattformen über USB, NFC oder Bluetooth. Führende Hersteller wie Yubico liefern Multi-Protokoll-Schlüssel (YubiKey 5 Serie), die FIDO2, PIV/Smart Card und OTP unterstützen und sowohl moderne als auch Legacy-Authentifizierungsanforderungen in einem Token abdecken.
• Plattformübergreifende Portabilitätslücken. Synchronisierte Passkeys stoßen weiterhin auf Hürden beim Wechsel zwischen Ökosystemen. Ein in Apple Keychain erstellter Passkey wird nicht nativ mit Google Password Manager oder einem Windows-Gerät synchronisiert. Die FIDO Alliance adressiert dies mit dem Credential Exchange Protocol (CXP), einer von Apple, Google, Microsoft, 1Password, Bitwarden und Dashlane entwickelten Entwurfsspezifikation zur Standardisierung sicherer, verschlüsselter Passkey-Übertragungen zwischen Anbietern. CXP wird voraussichtlich 2026 als öffentlicher Entwurfsstandard veröffentlicht. Bis dahin bieten Drittanbieter-Passwortmanager wie 1Password und Bitwarden die konsistenteste plattformübergreifende Passkey-Erfahrung.

Für die Unternehmensplanung ist die wichtigste Erkenntnis, dass die Plattformunterstützung kein Hindernis mehr für die Einführung ist. Die verbleibende Hürde ist die plattformübergreifende Portabilität synchronisierter Passkeys und die organisatorische Bereitschaft für Registrierung, Wiederherstellung und Richtliniendurchsetzung. Diese operativen Herausforderungen verdienen eine genauere Betrachtung.

Herausforderungen und Einschränkungen, die Sie einplanen sollten

Keine Authentifizierungsmethode eliminiert alle Risiken. Bei der großflächigen Einführung von Passkeys und Sicherheitsschlüsseln stoßen Sie auf eine kleine Anzahl wiederkehrender Herausforderungen:

• Wiederherstellungs-Workflows werden zur zentralen Kontrolle. Wenn Angreifer Ihren Helpdesk oder den Anbieter-Reset-Prozess beeinflussen können, können sie selbst den stärksten Anmeldeablauf umgehen.
• Schlüsselverlust wird zum Verfügbarkeitsproblem. Ein verlorenes Token kann einen Nutzer aussperren, sofern Sie keine Backups und Admin-Workflows vorab eingerichtet haben.
• Plattformunterschiede erzeugen Reibung. Fragmentierung bei Browsern und Betriebssystemen kann zu inkonsistenter WebAuthn-UX und höherem Supportaufwand führen.
• Lebenszyklus-Overhead ist real. Ausgabe, Ersatz und Widerruf verursachen Aufwand, insbesondere wenn Sie die Token-Abdeckung über privilegierte Nutzer hinaus ausweiten.

Das sind keine theoretischen Probleme. 2023 meldete MGM Resorts einen durch Social Engineering ausgelösten Cybervorfall mit einem geschätzten negativen Einfluss von 100 Millionen US-Dollar, laut einer MGM-Meldung. Starke Anmeldefaktoren helfen, aber Sie müssen dennoch die Identitätsoperationen absichern, einschließlich Service-Desk- und Fallback-Prozesse. Die gute Nachricht ist, dass jede dieser Einschränkungen einer spezifischen Bereitstellungspraxis zugeordnet werden kann, die Sie vor der Durchsetzung implementieren können.

Best Practices für die Einführung von Passkeys und Sicherheitsschlüsseln

Ob Sie Passkeys, Sicherheitsschlüssel oder beides einführen – diese Praktiken helfen Ihnen, die Bereitstellung an Risiko, Benutzerfreundlichkeit und operative Realität anzupassen:

1. Segmentieren Sie nach Risiko und Vertrauensniveau. Geben Sie einen Hardware-Sicherheitsschlüssel für privilegierte Administratoren, Führungskräfte und regulierte Rollen aus, bei denen AAL3 oder hohe Attestierung relevant sind. Verwenden Sie synchronisierte Passkeys für die breite Belegschaft, wenn AAL2 ausreicht.
2. Machen Sie Registrierung und Backups zur Routine. Verlangen Sie die Passkey-Einrichtung beim Geräte-Onboarding und registrieren Sie mehrere Authenticatoren pro Nutzer, damit ein Backup vorhanden ist, das nicht auf leicht zu phishende Faktoren zurückfällt.
3. Härten Sie Kontowiederherstellung und Fallbacks. Behandeln Sie die Kontowiederherstellung als Kontrollmechanismus: Verschärfen Sie die Identitätsprüfung für Helpdesk-Resets, beschränken Sie Fallback-Methoden und überwachen Sie ungewöhnliche Fallback-Nutzung.
4. Führen Sie die Einführung phasenweise durch und überwachen Sie kontinuierlich. Starten Sie mit Hochrisikogruppen, erweitern Sie schrittweise und erzwingen Sie die Richtlinien erst, wenn Nutzer-Support und Reset-Workflows stabil sind. Behalten Sie weiterhin ungewöhnliche Reisen, riskante Gerätewechsel und verdächtige Neuregistrierungen im Blick.

Wenn Sie diese vier Praktiken umsetzen, reduzieren Sie Sperrungen und schränken die Optionen für Angreifer ein, ohne die Nutzer auszubremsen. Darauf aufbauend können Sie ein klares Segmentierungsmodell entwickeln, welcher Anmeldetyp wo eingesetzt wird.

Wie Sie zwischen Passkey und Sicherheitsschlüssel wählen

Die Wahl zwischen Passkey und Sicherheitsschlüssel ist kein Entweder-oder. Die meisten Unternehmen setzen auf ein hybrides Modell, da unterschiedliche Nutzergruppen unterschiedliche Vertrauensniveaus und Wiederherstellungspfade benötigen.

Nutzen Sie diese Segmentierung für eine klare Entscheidung:

• Hardware-Sicherheitsschlüssel: Verwenden Sie diese, wenn Sie AAL3, nicht exportierbare Schlüssel und starke Geräteattestierung für privilegierten Zugriff benötigen.
• Synchronisierter Passkey: Verwenden Sie diesen, wenn AAL2 ausreicht und Sie geringeren IT-Aufwand für den breiten Zugriff der Belegschaft wünschen.
• Hybride Richtlinie: Verwenden Sie Sicherheitsschlüssel für Administratoren und regulierte Rollen und synchronisierte Passkeys für den Rest Ihrer Nutzer.
• Recovery-First-Design: Behandeln Sie Reset- und Fallback-Pfade als Teil Ihres Kontrollsets, nicht als nachträglichen Gedanken, da sie phishing-resistente MFA aushebeln können.

Wenn Sie diese Segmentierung vorgenommen haben, besteht der nächste Schritt darin, sicherzustellen, dass Sie identitätsbasierte Aktivitäten auch nach der Anmeldung erkennen und stoppen können.

Wichtige Erkenntnisse

Passkeys und physische Sicherheitsschlüssel bieten beide phishing-resistente Authentifizierung durch FIDO2-Kryptografie, bedienen aber unterschiedliche Unternehmensanforderungen. Synchronisierte Passkeys priorisieren das Benutzererlebnis und die Skalierbarkeit für allgemeine Belegschaften auf AAL2. 

Gerätegebundene Sicherheitsschlüssel bieten nicht exportierbare Anmeldeinformationen, hardwarebasierte Attestierungsunterstützung und AAL3-Konformität für privilegierte Nutzer und regulierte Umgebungen. In den meisten Unternehmen werden Sie beide in einem risikobasierten Modell einsetzen und anschließend Identitätsbedrohungserkennung darüberlegen, um das abzufangen, was Authentifizierungskontrollen allein nicht verhindern können.

FAQs

Was ist ein Passkey?

Ein Passkey ist ein FIDO2-Authentifizierungsnachweis, der Public-Key-Kryptografie anstelle eines gemeinsam genutzten Geheimnisses wie ein Passwort verwendet. Wenn Sie einen Passkey registrieren, erzeugt Ihr Gerät ein einzigartiges Schlüsselpaar: Der private Schlüssel verbleibt auf dem Gerät (oder wird über einen Cloud-Anbieter synchronisiert), und der Server speichert nur den öffentlichen Schlüssel. 

Sie authentifizieren sich mit einem biometrischen Scan, einer PIN oder der Gerätesperre. Da das Anmeldekennzeichen an eine bestimmte Domain gebunden ist und niemals übertragen wird, verhindert es Phishing und Credential Stuffing bereits auf Protokollebene.

Was ist der Unterschied zwischen AAL2 und AAL3?

AAL2 und AAL3 sind NIST-Authentifizierungsvertrauensniveaus, die definieren, wie stark Sie einer Anmeldung vertrauen können. AAL2 erfordert eine phishing-resistente Authentifizierung, kann jedoch synchronisierte Anmeldedaten zulassen, die unter der Kontrolle eines Anbieters zwischen Geräten übertragen werden. 

AAL3 setzt höhere Anforderungen, indem ein hardwaregestützter, nicht exportierbarer Schlüssel und strengere Anforderungen an den Verifizierer verlangt werden. In der Praxis eignen sich synchronisierte Passkeys für AAL2, während Sicherheitsschlüssel oder andere gerätegebundene Authentifikatoren für AAL3 verwendet werden.

Was sind Passkey-Redaktionsangriffe?

Passkey-Redaktionsangriffe zielen auf die Benutzerschnittstelle ab, indem Passkey-Aufforderungen ausgeblendet oder unterdrückt werden, sodass Benutzer auf Passwörter, SMS oder andere schwächere Alternativen ausweichen müssen. Angreifer können dies durch Adversary-in-the-Middle-Proxys, manipulative Anmeldeseiten oder bösartige Browser-Erweiterungen erreichen, die die Benutzeransicht verändern. 

Um das Risiko zu verringern, sollten Sie Fallbacks minimieren, bedingte Zugriffsregeln anwenden und Richtlinien für Erweiterungen absichern. Außerdem sollten Sie bei plötzlichen Anstiegen der Fallback-Nutzung alarmieren, da diese häufig auf aktive Nötigung hinweisen.

Wie führt man Passkeys und Security Keys schrittweise ein?

Ein gestaffelter Rollout beginnt in der Regel mit Grundlagenarbeit: WebAuthn-Unterstützung prüfen, AAL2- und AAL3-Richtlinien definieren sowie robuste Playbooks für Zurücksetzung und erneute Registrierung erstellen. Verteilen Sie Security Keys zuerst an privilegierte und risikoreiche Rollen, danach rollen Sie synchronisierte Passkeys in Wellen an die gesamte Belegschaft aus. 

Erzwingen Sie FIDO-only-Richtlinien, sobald Akzeptanz und Support stabil sind. Halten Sie Altfaktoren nur so lange vor, wie nötig, um Kontosperrungen während der Umstellung zu vermeiden, und stellen Sie sie dann ein.

Sind synchronisierte Passkeys in BYOD-Umgebungen sicher?

Ja, aber es sind Leitplanken erforderlich. Speichern Sie Unternehmens-Passkeys in verwalteten Containern oder Arbeitsprofilen, damit die Schlüssel im verwalteten Kontext bleiben und nicht in einem persönlichen Cloud-Tresor. Beschränken Sie die Erstellung von Passkeys nach Möglichkeit auf verwaltete Browser und Apps und prüfen Sie, ob Unternehmensanmeldedaten unter persönlichen Konten registriert wurden. 

Auch Ihr Modell zur Kontowiederherstellung ist hier entscheidend: Wenn Rücksetzungen auf leicht sozial manipulierbare Schritte zurückfallen, verlieren synchronisierte Passkeys einen Großteil ihres Vertrauensniveaus.

Warum nutzen Unternehmen sowohl Passkeys als auch Security Keys?

Sie verwenden beide, da kein einzelner Authentifikator für jede Rolle die richtige Balance zwischen Sicherheit, Benutzerfreundlichkeit und Betrieb bietet. Geben Sie Sicherheitsschlüssel an privilegierte Benutzer, Administratoren und regulierte Rollen aus, die nicht exportierbare Schlüssel und einen starken Nachweis der Authentifikator-Herkunft erfordern. 

Verwenden Sie synchronisierte Passkeys für die breite Belegschaft, bei der AAL2 ausreichend ist und Benutzerfreundlichkeit die Akzeptanz fördert. Erzwingen Sie anschließend konsistente Fallback- und Wiederanmeldungsvorgaben für beide Gruppen, damit Angreifer Benutzer nicht auf schwächere Faktoren zurückstufen können.