Passkeys + Device Intelligence: mehrschichtige Abwehr gegen Kontoübernahme

Passkeys sind die bedeutendste Verbesserung der Verbraucherauthentifizierung seit einem Jahrzehnt, und die branchenübliche Einordnung dazu ist auf subtile Weise irreführend. Die Einordnung lautet, dass Passkeys die Kontoübernahme „lösen“. Sie lösen sie nicht — sie beseitigen eine Klasse davon, die größte und am stärksten automatisierbare, und drängen dabei die Angreifer zu den Teilen des Konto-Lebenszyklus, die Passkeys strukturell nicht schützen können.

Dieser Beitrag richtet sich an Security-Architekten und Produktsicherheitsteams, die Passkeys einführen und eine nüchterne Übersicht darüber wünschen, was Passkeys abdecken, was sie offenlassen und wo eine Device-Intelligence-Schicht hineinpasst. Die These: Passkeys und Device Intelligence ergänzen sich. Passkeys härten die Authentifizierung; Device Intelligence sichert alles darum herum.

Was Passkeys tatsächlich beheben

Passkeys beheben den Diebstahl von Anmeldedaten, indem sie das geteilte Geheimnis vollständig entfernen. Es gibt kein Passwort zum Phishen, kein Passwort zur Wiederverwendung über Websites hinweg, kein Passwort in einem Leak-Dump, das darauf wartet, per Stuffing eingesetzt zu werden. Das schließt die größte einzelne Angriffsfläche der Kontoübernahme in einem Zug.

Technisch ist ein Passkey ein öffentlich-privates Schlüsselpaar, das pro Website mit den Standards WebAuthn und FIDO2 erstellt wird. Der private Schlüssel verlässt niemals das Gerät des Nutzers (oder seinen synchronisierten Anmeldedaten-Anbieter); die Website speichert nur den öffentlichen Schlüssel. Die Authentifizierung ist ein kryptografisches Challenge-Response-Verfahren: Die Website sendet eine Challenge, das Gerät signiert sie mit dem privaten Schlüssel, die Website verifiziert mit dem öffentlichen Schlüssel. Nichts Wiederverwendbares geht über die Leitung.

Daraus folgen zwei Eigenschaften, und es sind genau die, die für ATO zählen:

Phishing-Resistenz. Der Passkey ist kryptografisch an den Origin der Website gebunden. Ein Nutzer, der auf einer täuschend ähnlichen Phishing-Domain landet, kann seinen Passkey dort nicht vorlegen — der Browser bietet ihn nicht an, weil der Origin nicht übereinstimmt. Das hebelt die gesamte Kategorie der Echtzeit-Phishing-Proxys (Angriffe im Evilginx-Stil) aus, die Einmalcode-MFA nutzlos macht. Die Anmeldedaten können schlicht nicht an das falsche Ziel weitergeleitet werden.

Kein geteiltes Geheimnis, das sich massenhaft stehlen lässt. Es gibt keine Datenbank gehashter Passwörter zum Exfiltrieren, keine Anmeldedatenliste zum Kauf, kein Material für Credential Stuffing. Die Ökonomie automatisierter Passwortangriffe beruht darauf, dass gestohlene Anmeldedaten billig und wiederverwendbar sind; Passkeys machen sie nicht existent.

Für die Abläufe, die ein Passkey tatsächlich steuert — ein Nutzer, der sich auf einem Gerät anmeldet, das seinen Passkey bereits enthält — ist das nahezu lückenlos. Würde sich Ihre gesamte Nutzerbasis ausschließlich mit Passkeys auf Geräten authentifizieren, die sie bereits besitzt, wäre das klassische ATO-Playbook tot.

In dieser Welt operiert kein realer Dienst.

Die Angriffsfläche, die Passkeys nicht abdecken

Passkeys sichern das Authentifizierungsereignis. Kontoübernahme beschränkt sich nicht auf das Authentifizierungsereignis — sie zielt auf den gesamten Konto-Lebenszyklus, und der größte Teil dieses Lebenszyklus liegt außerhalb dessen, was ein Passkey steuert. Vier Lücken sind relevant.

Kontowiederherstellung. Das ist die große Lücke. Jeder Dienst braucht einen Weg, über den ein Nutzer, der sein Gerät verloren hat, wieder Zugang erhält. Dieser Wiederherstellungspfad — E-Mail-Link, SMS-Code, Sicherheitsfragen, Backup-Codes, Help-Desk-Verifizierung — ist per Definition eine Möglichkeit, sich ohne den Passkey zu authentifizieren. Ein Angreifer, der den Passkey nicht aushebeln kann, greift stattdessen den Wiederherstellungsablauf an, und Wiederherstellungsabläufe sind typischerweise weit schwächer als die primäre Authentifizierung, die sie umgehen. Ein Passkey-Deployment mit einem Fallback „Zurücksetzen per SMS-Code“ hat eine phishing- und SIM-Swap-anfällige Hintertür, so stark die Vordertür auch sein mag.

Geräte-Enrollment. Einem Konto einen neuen Passkey hinzuzufügen, ist eine kontoändernde Aktion, und wenn ein Angreifer den Passkey seines eigenen Geräts registrieren kann, hat er nun dauerhaften legitimen Zugang. Das Enrollment wird üblicherweise durch eine bestehende authentifizierte Sitzung abgesichert — was bedeutet, dass es die Schwächen dessen erbt, was diese Sitzung begründet hat, einschließlich des oben genannten Wiederherstellungsablaufs. Einen neuen Passkey zu registrieren ist das moderne Äquivalent zu „eine Weiterleitungsregel hinzufügen“: leise, dauerhaft und leicht zu übersehen.

Session-Hijacking. Passkeys authentifizieren; sie authentifizieren nicht fortlaufend erneut. Sobald sich ein Nutzer angemeldet hat, ist das resultierende Session-Token eine Bearer-Anmeldeinformation wie jede andere. Stehlen Sie es — über Malware, eine bösartige Erweiterung, ein kompromittiertes Gerät oder einen Token-Exfiltrationsangriff — und Sie haben die authentifizierte Sitzung, ohne den Passkey je berührt zu haben. Die Stärke des Logins sagt nichts über die Sicherheit der darauf folgenden Stunde aus.

Der lange Schwanz der nicht Registrierten. Die Passkey-Verbreitung ist real, aber partiell. Ein bedeutender Teil jeder Verbrauchernutzerbasis wird keinen Passkey haben: ältere Geräte, gemeinsam genutzte oder Unternehmensrechner, Nutzer, die die Aufforderung weggeklickt haben, Nutzer, die sie nicht verstehen. Jedes dieser Konten hat weiterhin einen passwort- oder codebasierten Pfad, und die Angreifer konzentrieren sich genau auf diesen Pfad. Ein Dienst ist nur so geschützt wie seine schwächste verfügbare Authentifizierungsmethode, und für den nicht registrierten Schwanz ist diese Methode die alte.

Das Muster über alle vier hinweg: Starke Authentifizierung nimmt nicht den Anreiz, Konten zu übernehmen, sie verlagert den Angriff. Das ist die durchgängige Lehre der ATO-Landschaft 2026 — mit jedem Vektor, der sich härtet, strömen die Angreifer zum nächstschwächeren. Passkeys verlagern den Kampf vom Login-Formular zum Wiederherstellungsablauf, zum Enrollment-Schritt und zur Sitzung nach dem Login.

Warum Device Intelligence die Lücken abdeckt

Device Intelligence deckt die Passkey-Lücken ab, weil sie auf einer anderen Achse arbeitet: Passkeys fragen „hält dieser Nutzer den richtigen Schlüssel“, Device Intelligence fragt „ist dies das Gerät und der Kontext, den wir für dieses Konto erwarten, bei jeder Aktion“. Die zweite Frage lässt sich auch dann beantworten, wenn kein Passkey im Spiel ist — was genau die Situation bei Wiederherstellung, Enrollment und dem nicht registrierten Schwanz ist.

Der Mechanismus ist eine dauerhafte Geräteidentität: eine stabile Kennung aus Browser-, Hardware-, Netzwerk- und Verhaltenssignalen, die ein wiederkehrendes Gerät sitzungsübergreifend erkennt, ohne auf eine gespeicherte Anmeldeinformation angewiesen zu sein. (Wie diese Kennung konstruiert wird und warum sie gelöschte Cookies übersteht, behandelt der Beitrag wie Device-Fingerprinting funktioniert.) Ist diese Identität mit der Historie eines Kontos verknüpft, erhält jede der vier Lücken eine Kontrolle, die Passkeys nicht bieten können.

An bekannte Geräte gebundene Wiederherstellung. Wenn ein Wiederherstellungsversuch eintrifft, beantwortet Device Intelligence eine Frage, die der Wiederherstellungsablauf sonst nicht kann: Wird diese Wiederherstellung von einem Gerät aus initiiert, das dieses Konto je genutzt hat? Eine Wiederherstellung von einem brandneuen Gerät in einem neuen Land über eine Rechenzentrums-IP ist kategorisch riskanter als eine Wiederherstellung vom gewohnten Laptop des Nutzers. Dieses Signal erlaubt es Ihnen, den Wiederherstellungsablauf abzustufen — leichte Verifizierung von einem bekannten Gerät, strenge Verifizierung (oder eine Sperre) von einem unbekannten — statt für alle dieselbe schwache SMS-Prüfung anzuwenden.

Durch Gerätevertrauen abgesichertes Enrollment. Eine Anfrage, einen neuen Passkey zu registrieren, kann gegen die Gerätehistorie bewertet werden. Einen Passkey vom etablierten Gerät des Nutzers zu registrieren, ist erwartbar. Einen von einem Gerät zu registrieren, das vor Minuten aufgetaucht ist, unmittelbar nach einem Wiederherstellungsereignis, aus einem verdächtigen Netzwerk, ist die Signatur einer Kontoübernahme. Device Intelligence macht diese Enrollment-Anfrage lesbar statt unsichtbar.

Fortlaufende Sitzungsbewertung nach dem Login. Weil die Geräteidentität bei jedem Request bewertet wird, nicht nur beim Login, ist eine Sitzung, die auf einem Gerät beginnt und auf einem anderen fortgesetzt wird — der Fingerabdruck eines gestohlenen Tokens, das anderswo erneut abgespielt wird — erkennbar. Wenn sich der Geräte- oder Netzwerkkontext mitten in der Sitzung vom authentifizierten Gerät entfernt, ist das ein Hijack-Signal, das keine noch so starke Authentifizierung an der Vordertür erfassen kann. Das ist das Prinzip der Zero-Trust-Geräteverifizierung: Vertrauen wird fortlaufend bewertet, nicht einmalig an der Tür gewährt.

Abdeckung für die nicht Registrierten. Für die Nutzer, die nie einen Passkey übernommen haben, ist Device Intelligence die Schicht, die die Arbeit leistet — sie erkennt ihr bekanntes Gerät und lässt legitime Logins mit geringer Reibung durch, während sie die Credential-Stuffing- und Unbekanntes-Gerät-Versuche markiert, die genau auf diese Population abzielen. Die Nutzer, die durch die partielle Passkey-Verbreitung am stärksten exponiert sind, sind jene, die Device Intelligence am direktesten schützt.

Der rote Faden: Passkeys beweisen den Schlüsselbesitz in einem Moment; Device Intelligence etabliert den Geräte- und Verhaltenskontext über jeden Moment hinweg. Die Lücken des Ersten sind genau die Domäne des Zweiten.

Wie sich die beiden Schichten in der Praxis verbinden

In einem mehrschichtigen Deployment laufen Passkeys und Device Intelligence parallel, jeweils maßgeblich für die Entscheidungen, für die sie geeignet sind, und speisen ein einziges Risikobild.

Beim Login ist ein Passkey, sofern vorhanden, der starke primäre Faktor — phishing-resistent, kein geteiltes Geheimnis. Device Intelligence läuft daneben und bestätigt stillschweigend, dass das Gerät bekannt und der Kontext normal ist. Für einen Passkey-Login von einem erkannten Gerät ist das unsichtbar: Der Nutzer meldet sich an, nichts fordert ihn auf. Das Gerätesignal wird nur herangezogen, wenn es der Erwartung widerspricht.

Bei Wiederherstellung und Enrollment, wo kein Passkey vorgelegt wird (das ist der ganze Sinn dieser Abläufe), wird Device Intelligence zum primären Risiko-Input. Das Verdikt der Smart Signals — bekanntes Gerät, Netzwerkreputation, Verhaltenskonsistenz — bestimmt, ob der Ablauf leichtgängig fortgesetzt wird, zu einer stärkeren Verifizierung eskaliert oder zur Prüfung angehalten wird. Genau hier erhält die eigentliche Hintertür des Passkey-Deployments ein Schloss.

Nach dem Login liefert Device Intelligence eine fortlaufende Bewertung. Die Aufgabe des Passkeys endete bei der Authentifizierung; die Geräteschicht beobachtet die Sitzung auf Kontextverschiebungen, die auf Token-Diebstahl hindeuten, und kann eine erneute Authentifizierung erzwingen, wenn das Gerätesignal mitten in der Sitzung bricht.

Für die nicht Registrierten trägt Device Intelligence auch beim Login die Hauptlast und unterscheidet das wiederkehrende bekannte Gerät vom Credential-Stuffing-Versuch, bis (und falls) der Nutzer einen Passkey übernimmt.

Die Arbeitsteilung ist sauber, weil die beiden Mechanismen wirklich unterschiedliche Fragen beantworten und auf wirklich unterschiedliche Weise versagen. Ein Passkey kann Ihnen nicht sagen, ob das Gerät, das ein Passwort-Zurücksetzen anfordert, vertrauenswürdig ist; Device Intelligence kann keinen phishing-resistenten kryptografischen Nachweis des Schlüsselbesitzes liefern. Das eine ohne das andere einzusetzen, hinterlässt eine vorhersehbare Lücke — Passkeys allein lassen die Wiederherstellungs- und Sitzungsabläufe weich; Device Intelligence allein fehlt die kryptografische Authentifizierungsstärke an der Vordertür.

Die ehrliche Einordnung für einen Passkey-Rollout

Wenn Sie Passkeys ausrollen, lautet die zutreffende interne Botschaft nicht „wir haben die Kontoübernahme gelöst“. Sie lautet „wir haben den Diebstahl von Anmeldedaten als Angriffsvektor beseitigt und müssen nun die Abläufe härten, zu denen die Angreifer ausweichen werden“. Diese Abläufe — Wiederherstellung, Enrollment, Sitzung und der nicht registrierte Schwanz — sind der Ort, an dem sich die nächste Runde der ATO-Versuche konzentrieren wird, gerade weil die Vordertür stark geworden ist. Ein Passkey-Rollout, der nicht gleichzeitig die Wiederherstellung härtet, verlegt das Schloss von der Tür ans Fenster und lässt das Fenster offen.

Diese Härtung liefert eine Device-Intelligence-Schicht, und deshalb kombinieren die stärksten ATO-Aufstellungen beides. Passkeys machen das Authentifizierungsereignis nahezu unschlagbar. Device Intelligence macht den Rest des Konto-Lebenszyklus — die Teile, denen sich ein Angreifer zuwendet, weil das Authentifizierungsereignis unschlagbar wurde — beobachtbar und bewertbar.

Tracio liefert die Device-Intelligence-Hälfte dieser Kombination: eine dauerhafte Geräteidentität, die gelöschte Cookies und neue Sitzungen übersteht, Netzwerk- und Verhaltensrisikosignale und ein Verdikt in unter 50 ms, das sich in Wiederherstellung, Enrollment und fortlaufende Sitzungsprüfungen einfügt. Es läuft leise hinter Passkey-Logins von bekannten Geräten und tritt genau dort hervor, wo Passkeys nicht hinreichen.

Möchten Sie sehen, wie Device Intelligence die Abläufe abdeckt, die Ihr Passkey-Deployment offenlässt?

Starten Sie Ihre kostenlose Testphase — 2.500 Verifizierungen kostenlos, keine Kreditkarte erforderlich. Buchen Sie eine Demo, um Device Intelligence gegen Ihre Authentifizierungs-, Wiederherstellungs- und Sitzungsarchitektur abzubilden.