Passkeys gelten zu Recht als großer Fortschritt gegenüber Passwörtern. Sie sind phishing-resistent, werden nicht wiederverwendet und beruhen auf kryptografischen Schlüsselpaaren statt auf geteilten Geheimnissen. Für Unternehmen klingt das nach einer einfachen Botschaft: Wenn Passkeys ausgerollt sind, sinkt das Risiko von Credential Theft deutlich. Genau hier liegt aber ein praktisches Missverständnis. Passkeys entschärfen viele Passwortangriffe, sie machen ein kompromittiertes Endgerät aber nicht vertrauenswürdig.
Aktuelle Forschung von Unit 42, über die am 3. August unter anderem The Hacker News und BleepingComputer berichteten, zeigt diese Grenze sehr konkret. Die Forscher beschreiben drei Angriffspfade gegen Google Password Manager mit synchronisierten Passkeys auf Chrome unter Windows. Alle Varianten setzen voraus, dass bereits Malware auf dem Gerät läuft. Das ist eine wichtige Einschränkung, aber keine Entwarnung: In Enterprise-Umgebungen ist genau dieser Zustand der typische Startpunkt vieler Infostealer-, RMM- und Browser-Session-Angriffe.
Technischer Kern: Nicht die Kryptografie bricht, sondern die Umgebung
Die beschriebenen Angriffe brechen nicht WebAuthn und nicht die Grundidee von Passkeys. Sie greifen die Implementierungsumgebung an: lokale Chrome-Daten, TPM-gebundene Geräteschlüssel, Re-Enrollment-Prozesse und die Frage, ob der Ziel-Dienst das User-Verified-Flag korrekt auswertet.
Beim ersten Angriff, „Pass-ta-key“, kann Malware mit normalen Benutzerrechten lokale Chrome-Synchronisationsdaten auslesen und einen TPM-gebundenen Geräteschlüssel missbrauchen, um gegenüber Googles Cloud Authenticator eine Signaturanfrage als vertrauenswürdiges Gerät erscheinen zu lassen. Laut Bericht kann dadurch eine gültige Authentifizierungsantwort erzeugt werden, ohne dass der Nutzer einen Fingerabdruck, eine PIN oder eine sichtbare Freigabeaktion ausführt. Entscheidend ist dann, ob der jeweilige Dienst wirklich verlangt, dass der Nutzer verifiziert wurde. GitHub soll diese Prüfung im Test korrekt durchgesetzt haben; eBay habe sie laut den Forschern zunächst nicht korrekt ausgewertet und den Fehler nach Meldung behoben.
Die zweite Variante, „Silver Pass-ta-key“, zielt auf das erneute Registrieren des Geräts. Die Forscher beschreiben ein Zeitfenster, in dem ein Angreifer nach Manipulation lokaler Zustandsdaten einen eigenen User-Verification-Schlüssel registrieren kann. Dadurch könnte der Cloud Authenticator spätere Anfragen als biometrisch oder per PIN bestätigte Aktionen akzeptieren, obwohl die Kontrolle beim Angreifer liegt.
Die dritte Variante, „Golden Pass-ta-key“, ist am gravierendsten. Hier geht es um die 32 Byte lange Security Domain Secret, die für die Entschlüsselung synchronisierter Passkey-Private-Keys relevant ist. Unit 42 beschreibt, dass Malware diesen Wert während des Re-Enrollment-Prozesses kurzzeitig aus dem Chrome-Prozessspeicher extrahieren könne. Damit würde aus einem eigentlich nicht kopierbaren Passkey wieder ein übertragbares Gut: ein Ziel für Weiterverkauf, Wiederverwendung und langfristige Kontoübernahme.
Faktenlage und Grenzen der Meldung
Die Faktenbasis ist relativ klar, aber sie muss sauber begrenzt werden. Die Primärquelle ist der Unit-42-Bericht „Pass the Passkey: A Novel Attack Surface in Passwordless Authentication“ vom 3. August 2026. The Hacker News und BleepingComputer haben die Kernaussagen am selben Tag zusammengefasst. Der Angriff betrifft nach öffentlicher Beschreibung Google Password Manager in Chrome auf Windows-Systemen mit Trusted Platform Module. Er startet nicht aus der Ferne gegen ein sauberes Gerät, sondern nach lokaler Kompromittierung.
Ebenfalls wichtig: Zum Veröffentlichungszeitpunkt wurden keine CVEs, keine konkret betroffenen Chrome-Versionen und keine bestätigte Ausnutzung in freier Wildbahn genannt. Teile der Architektur lassen sich über öffentlichen Chromium-Code einordnen, etwa lokale Sync-Daten, enclave-bezogene Zustände und die Verarbeitung von Sicherheitsdomänen-Geheimnissen. Ob jede beschriebene Variante gegen jede aktuelle Produktkonfiguration zuverlässig funktioniert, bleibt eine Aussage der Forscher und kein allgemein reproduzierter Massenvorfall.
Trotzdem ist das Thema relevant. Denn Unternehmen führen Passkeys oft genau deshalb ein, weil klassische MFA-Methoden wie SMS, OTP und Push-Freigaben phishbar oder ermüdbar sind. Wenn ein lokaler Infostealer die neue Authentifizierungsarchitektur auf andere Weise ausnutzt, verschiebt sich das Risiko: weg vom Login-Formular, hin zum Endgerät, Browserprofil und Cloud-Sync-Zustand.
Branchenkontext: Passwortlos heißt nicht endpunktlos
Der Fall passt in einen größeren Trend. Identitätssysteme werden kryptografisch stärker, während Angreifer näher an die Ausführungsumgebung rücken. Browser-Cookies, OAuth-Tokens, Session-Speicher, Entwickler-Credentials, SSH-Schlüssel und jetzt auch passkey-nahe Zustände liegen nicht abstrakt in einem IAM-Diagramm, sondern auf realen Arbeitsstationen. Dort laufen Browser, EDR, Agenten, Extensions, lokale Automatisierung, gelegentlich auch AI-Coding-Tools und MCP-ähnliche Workflows mit Zugriff auf Repositories oder Cloud-Konten.
Für Entscheider ist deshalb die zentrale Lehre nicht, Passkeys zurückzustellen. Im Gegenteil: Passkeys bleiben ein sinnvoller Schritt gegen Phishing und Passwortdiebstahl. Aber ihre Einführung darf nicht als Ersatz für Endpoint Detection, Privileged Access Management, Browser-Härtung und Session-Risk-Monitoring verkauft werden. Wer nur die Login-Methode modernisiert, aber kompromittierte Geräte weiter als vertrauenswürdige Authentifizierungsanker behandelt, baut eine neue Komfortschicht auf einem alten Risiko.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen Passkey-Rollouts mit klaren Anforderungen an die Relying Parties verbinden. Kritische Anwendungen müssen das User-Verified-Flag korrekt auswerten, wenn User Verification verlangt wird. Der Unterschied zwischen „eine Signatur ist gültig“ und „der Nutzer wurde wirklich verifiziert“ ist kein Implementierungsdetail, sondern ein Sicherheitsmerkmal.
Zweitens gehört der Browserzustand in das Threat Model. Chrome-Profile, lokale Sync-Daten, Passwortmanager, Credential Stores und Prozessspeicher sollten in EDR- und DLP-Überlegungen sichtbar sein. Das bedeutet nicht, sensible Inhalte pauschal auszulesen, sondern verdächtige Zugriffe, ungewöhnliche Re-Enrollment-Muster, Prozess-Injektionen und Memory-Dumping-Versuche zu erkennen.
Drittens sollten privilegierte Konten anders behandelt werden als normale Nutzerkonten. Für Administratoren, CI/CD-Betreiber, Cloud-Operatoren und Entwickler mit Produktionszugriff reichen synchronisierte Komfort-Passkeys oft nicht aus. Hier sind hardwaregebundene Security Keys, Gerätebindung, Conditional Access, kurze Sitzungsdauer und zusätzliche Risikosignale sinnvoll.
Viertens müssen Incident-Response-Playbooks angepasst werden. Wenn ein Gerät mit synchronisierten Passkeys kompromittiert war, reicht es nicht, Passwörter zu ändern. Teams sollten prüfen, ob Passkeys, vertrauenswürdige Geräte, Recovery-Zustände und aktive Sessions zurückgesetzt werden müssen. Auch Account-Anbieter und SaaS-Anwendungen sollten dokumentieren, wie Passkey-Re-Enrollment, Gerätezustand und User-Verification-Policy geprüft werden können.
Risiken und Limitierungen
Die wichtigste Limitierung bleibt: Ohne lokale Malware gibt es nach öffentlicher Quellenlage keinen Angriff. Passkeys werden dadurch nicht „unsicher“. Sie lösen nur nicht das Problem eines bereits kontrollierten Endpunkts. Außerdem beziehen sich die beschriebenen Details auf eine konkrete Kombination aus Google Password Manager, Chrome, Windows und TPM. Andere Browser, Plattformen und Passkey-Anbieter können andere Schutzmechanismen oder andere Schwächen haben.
Umgekehrt wäre es gefährlich, das Thema als Nischenforschung abzutun. Synchronisierte Passkeys sollen gerade deshalb bequem sein, weil sie auf mehreren Geräten nutzbar sind. Diese Bequemlichkeit erzeugt zwangsläufig Prozesse für Onboarding, Wiederherstellung und Gerätevertrauen. Genau diese Prozesse müssen so streng betrachtet werden wie früher Passwort-Reset-Flows.
Fazit
Passkeys bleiben ein Sicherheitsgewinn. Sie reduzieren Phishing, Passwortwiederverwendung und viele Formen klassischen Credential Diebstahls. Der neue Befund zeigt aber, dass passwortlose Authentifizierung kein Ersatz für Endpoint Security ist. Wenn Malware auf dem Gerät läuft, greifen Angreifer nicht die Mathematik an, sondern die Betriebsumgebung: Browserzustand, Geräteschlüssel, Re-Enrollment und Policy-Prüfungen der Zielanwendung.
Für Unternehmen lautet die praktische Konsequenz: Passkeys einführen, aber nicht als Schlussstrich unter Identitätsrisiken behandeln. Der Maßstab muss sein, ob ein kompromittierter Arbeitsplatz noch zur Kontoübernahme führen kann. Genau dort entscheidet sich, ob passwortlose Authentifizierung nur komfortabler oder wirklich belastbarer wird.
Quellen
- Unit 42: „Pass the Passkey: A Novel Attack Surface in Passwordless Authentication“, 3. August 2026: https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/
- The Hacker News: „Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts“, 3. August 2026: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
- BleepingComputer: „New Pass-ta-key attacks let malware hijack Google-synced passkeys“, 3. August 2026: https://www.bleepingcomputer.com/news/security/new-pass-ta-key-attacks-let-malware-hijack-google-synced-passkeys/
