Passkey-Wiederherstellung: Vor Einführung einer Passkey-Pflicht

Eine Übung zur Passkey-Wiederherstellung zeigt, wie ein Teammitglied wieder Zugang erhält, wenn sein üblicher Authentifikator nicht verfügbar ist. Bevor Sie Passkeys verpflichtend machen, testen Sie zwei Fälle: Ein registriertes Ersatz-Anmeldemittel ist noch verfügbar, oder sämtliche nutzbaren Anmeldemittel fehlen. Prüfen Sie, wer Ersatz freigeben darf, welche Konten erreichbar bleiben und was mit bereits angemeldeten Sitzungen geschieht.

Das ist eine praktische Antwort auf die Debatte, die diese Woche auf Hacker News geführt wird. Scott Helmes Beitrag vom 14. Oktober, „Passkeys Are Not a Trap“ widerspricht Behauptungen über die Attestierung von Passkeys. In der Diskussion stellen sich auch alltägliche Zugangsfragen: Wo wurde das Anmeldemittel gespeichert? Was passiert auf einem anderen Gerät? Wer hilft, wenn es verschwindet? Diese Kommentare sind Einzelberichte, keine gemessene Fehlerquote. Trotzdem beschreiben sie Situationen, die Ihre Einführung abdecken sollte.

Sie können phishingresistente Authentifizierung befürworten und zugleich eine brauchbare Wiederherstellung verlangen. Für ein Startup lässt sich das am besten prüfen, bevor ein Teammitglied während eines Interviews oder Produktionsvorfalls darauf angewiesen ist.

Beginnen Sie mit einem verlorenen Laptop

Nutzen Sie einen Test-Arbeitsbereich und ein fiktives Teammitglied namens Maya. In einer halben Stunde steht ein Interview an, ihr üblicher Laptop ist nicht verfügbar, und sie braucht aus einem anderen Browser Zugang zum Recruiting-System. Die Übung soll zeigen, was sie tatsächlich tun kann und bei welchen Schritten sie Hilfe benötigt.

Halten Sie die Ausgangslage fest, bevor Sie Einstellungen ändern. Welches Anmeldemittel nutzt Maya normalerweise? Wo liegt es? Kann sie ihr Smartphone ohne den Laptop verwenden? Ist ein separater Sicherheitsschlüssel bereits registriert? Erreicht sie die E-Mail-Adresse für die Wiederherstellung? Wer darf ihr helfen?

Diese Fragen betreffen unterschiedliche Abhängigkeiten. Auf einem Smartphone kann ein synchronisierter Passkey liegen; zugleich kann es Wiederherstellungs-E-Mails empfangen und den Zugang zum Passwortmanager bestätigen. Das Gerät dreimal aufzuführen schafft noch keine drei unabhängigen Zugangswege.

Lassen Sie zunächst ein registriertes Ersatz-Anmeldemittel verfügbar und behandeln Sie das übliche Gerät für die Übung als nicht verfügbar. Öffnen Sie einen separaten Browser und melden Sie sich mit dem Ersatz an. Ein zweites Anmeldemittel in den Kontoeinstellungen zu sehen reicht als Nachweis nicht aus. Entscheidend ist, ob Maya es unter den Bedingungen nach dem Verlust nutzen kann.

Versuchen Sie anschließend, ein neues Anmeldemittel hinzuzufügen. Die Anwendung kann vor Änderungen eine erneute Authentifizierung verlangen, selbst wenn noch eine Seite geöffnet ist. Notieren Sie, an welcher Stelle sie diese verlangt, welche Methode sie akzeptiert und ob der Ersatz diesen Schritt ermöglicht.

Erfassen Sie die benötigte Zeit und beobachtete Hindernisse. Sie brauchen keine Zielvorgabe eines anderen Unternehmens. Sie brauchen genügend Nachweise, um zu beurteilen, ob Ihr Team die Unterbrechung verkraftet und ob die Anleitung auch ohne ihren Verfasser verständlich ist.

Trennen Sie Ersatz-Anmeldung und Passkey-Kontowiederherstellung

Ein noch registriertes Anmeldemittel zu verwenden ist etwas anderes, als die Anwendung nach dem Verlust aller nutzbaren Anmeldemittel erneut Vertrauen herstellen zu lassen. Geben Sie diesen Fällen in Ihrer Anleitung unterschiedliche Namen. Sie verlangen vom Nutzer und vom Administrator unterschiedliche Schritte.

Das Whitepaper der FIDO Alliance zur Einführung im Unternehmen unterscheidet synchronisierte Passkeys von Anmeldemitteln, die an einen Hardwareschlüssel gebunden sind. Synchronisierung kann nach einem Gerätewechsel helfen. Ein vorher registrierter Hardwareschlüssel kann einen weiteren Anmeldeweg bieten. Sein Nutzen hängt davon ab, ob er verfügbar ist und in der benötigten Umgebung unterstützt wird.

Angenommen, Maya kann nach dem Ausfall ihres Laptops einen synchronisierten Passkey auf dem Smartphone verwenden. Dann funktioniert die Ersatz-Anmeldung. Hängen aber beide Geräte vom selben Konto beim Anmeldemittel-Anbieter ab und ist auch dieses Konto nicht erreichbar, klärt der erste erfolgreiche Test diesen zweiten Fall nicht.

Erfassen Sie die Abhängigkeiten, statt Geräte zu zählen:

Diese Tabelle ist eine Planungshilfe. Ergänzen Sie Ihre tatsächlichen Beobachtungen in einer internen Betriebsanleitung. Ein leeres Ergebnis bedeutet, dass der Weg noch nicht getestet wurde, auch wenn die Dokumentation des Anbieters ihn klar beschreibt.

Verwenden Sie „passwortlos“ nicht als Kurzform für alles, was zum Wiederherstellungsweg gehört. Ein Passkey kann einen Authentifizierungsvorgang schützen, während ein Anbieterkonto, ein Postfach oder die Entscheidung eines Administrators weiterhin nötig bleibt, um wieder Zugang zu erhalten.

Spielen Sie auch den Ausfall des Anmeldemittel-Anbieters durch

Ein synchronisierter Passkey kann die Verfügbarkeit verbessern. Der Synchronisierungsanbieter ist jedoch ein weiteres System, dessen Zugang Ihr Teammitglied gegebenenfalls wiederherstellen muss. Testen Sie, was Ihre Anwendung ohne Zugang zu diesem System ermöglicht, statt vorauszusetzen, dass ein anderes Gerät das Anmeldemittel immer bereitstellt.

Behandeln Sie für diesen Teil von Mayas Übung alle nutzbaren Passkeys als nicht verfügbar. Verwenden Sie eine Testidentität. Löschen Sie keine Anmeldemittel eines Produktionsadministrators, um das Szenario realistisch zu machen. Folgen Sie dem dokumentierten Verfahren der Anwendung in einem frischen Browser und notieren Sie die erste Voraussetzung, die Maya nicht erfüllen kann.

Vielleicht kann sie sich mit einer anderen Methode anmelden und eine eingeschränkt zugängliche Registrierungsseite öffnen. Vielleicht erlaubt die Anwendung ausschließlich Passkeys und verweist auf ein separates Verfahren zur Identitätswiederherstellung. Vielleicht kann ein Administrator eine eng begrenzte Erlaubnis zur Registrierung eines Ersatzes erteilen. Das sind wesentlich unterschiedliche Wiederherstellungsverfahren.

Das FIDO-Papier zur Einführung synchronisierter Passkeys behandelt neben synchronisierten Anmeldemitteln auch alternative Authentifizierung und Wiederherstellung. Für den Betrieb heißt das: Prüfen Sie sowohl das Verfahren des Anmeldemittel-Anbieters als auch das der Anwendung. Ein funktionierender Weg beweist nicht, dass der andere funktioniert. Auch verspricht das Wort „Passkey“ keinen Export zwischen den von Ihnen gewählten Anbietern.

Lassen Sie Maya der Anleitung ohne ihre üblichen Notizen oder Browser-Lesezeichen folgen. Liegt die Betriebsanleitung hinter derselben Zugangssperre, die sie gerade überwinden will, stellen Sie die nötigen Wiederherstellungshinweise über einen anderen geeigneten Kanal bereit.

Testen Sie auch die Zustelladresse. Eine Wiederherstellungsnachricht an ein altes Postfach kann ein ansonsten solides Verfahren scheitern lassen. Und wenn ein kompromittiertes Postfach zum Szenario gehört, belegt selbst eine Adresse der hilfesuchenden Person noch nicht, dass die Anfrage berechtigt ist.

Legen Sie fest, wer Ersatz freigeben darf

Bei administrativ unterstützter Wiederherstellung vertrauen Sie der freigebenden Person und den Nachweisen, die sie akzeptiert. Legen Sie diese Verantwortung vor der Einführung fest, einschließlich der Vertretung bei Abwesenheit des üblichen Administrators.

Mayas Nachricht trifft ein: „Smartphone und Laptop verloren. Können Sie meinen Passkey zurücksetzen?“ Die Freigabe sollte einem Verfahren folgen, das Ihr Administrator erklären und wiederholen kann. Ein überzeugender Anzeigename und eine dringende E-Mail-Antwort sind eine schwache Grundlage, um neuen Zugang zu einem Arbeitsbereich mit Kandidateninformationen zu gewähren.

Nutzen Sie einen unabhängigen Kanal, der zu Ihrem Team und dem Risiko passt. Ein Administrator könnte Maya beispielsweise unter Kontaktdaten anrufen, die bereits aus einem vertrauenswürdigen Verfahren vorliegen. Eine neue Telefonnummer aus derselben Wiederherstellungsanfrage ist keine unabhängige Bestätigung. Halten Sie fest, dass die Prüfung stattfand, ohne unnötige personenbezogene Daten in einem Supportticket zu sammeln.

Die NIST-Leitlinien zur Authentifizierung und Verwaltung von Authentifikatoren behandeln Wiederherstellung getrennt von der Authentifizierung mit verbliebenen Authentifikatoren. Sie beschreiben Wiederherstellungsmethoden innerhalb eines Rahmens für Vertrauensniveaus, verlangen Benachrichtigungen zur Wiederherstellung und behandeln Risikoanalysen für anwendungsspezifische Methoden. Nutzen Sie dies zur Prüfung Ihres Konzepts, ohne zu behaupten, Ihr Startup oder Anbieter erfülle ein bestimmtes Vertrauensniveau.

Lassen Sie den Administrator während der Übung genau erklären, was seine Aktion erlaubt. Ermöglicht sie eine einzige Ersatzregistrierung, öffnet sie die gesamte Anwendung, setzt sie einen weiteren Faktor zurück oder deaktiviert sie eine Richtlinie für alle? Bevorzugen Sie eine Aktion, deren Umfang und Dauer zur genehmigten Aufgabe passen.

Behandeln Sie diesen Administrator anschließend im Szenario als nicht verfügbar. Wer kann dieselbe autorisierte Aktion ebenfalls durchführen? Findet diese Person die Anleitung und kann sie Maya überprüfen? Falls niemand dazu in der Lage ist, halten Sie diese Verfügbarkeitsgrenze fest. Entscheiden Sie vor der Passkey-Pflicht, ob sie akzeptabel ist.

Deaktivieren Sie eine Richtlinie des Arbeitsbereichs nicht stillschweigend, damit die Übung gelingt. Ist eine Lockerung als ausdrückliche Notfalloption vorgesehen, dokumentieren Sie, wer sie genehmigen darf, welchen Zugang sie eröffnet und wie die Richtlinie wiederhergestellt wird. Diese Entscheidung verdient einen eigenen Eintrag.

Prüfen Sie, welche Sitzungen angemeldet bleiben

Ein Anmeldemittel zu ersetzen und bestehenden Zugang zu beenden sind getrennte Vorgänge. Ihre Wiederherstellungsübung sollte zeigen, was mit alten Browsersitzungen und verbundenen Token geschieht, besonders bei möglichem Gerätediebstahl.

Das Modell für Anmeldemittel und Assertions in WebAuthn bindet Public-Key-Anmeldemittel an eine Relying Party und legt die Validierung bei der Authentifizierung fest. Diese Eigenschaften bilden bei korrekter Implementierung die Grundlage für Phishingresistenz. Sie bedeuten weder, dass jede spätere Anfrage den Vorgang wiederholt, noch dass das Löschen eines Anmeldemittels eine zuvor ausgestellte Sitzung automatisch beendet.

Kehren Sie nach der Ersatzregistrierung zu Mayas ursprünglichem Browser zurück. Verwenden Sie in der kontrollierten Übung einen weiteren Testbrowser als Stellvertreter für das nicht verfügbare Gerät. Kann er noch Daten lesen? Einstellungen ändern? Ändert das Entfernen des alten Anmeldemittels eines dieser Ergebnisse? Beobachten Sie das Verhalten, statt aus der Bezeichnung „Zurücksetzen“ auf eine vollständige Bereinigung des Kontos zu schließen.

Prüfen Sie anschließend die mit dem Konto verbundenen Werkzeuge. Ein API-Token kann weiter funktionieren, weil es ein eigenständiges Anmeldemittel ist. Eine Assistentenverbindung kann eigene Autorisierungs- und Widerrufsregeln haben. Entscheiden Sie, welche Zugänge beim gewöhnlichen Gerätewechsel bestehen bleiben sollen und welche bei einem Kompromittierungsverdacht widerrufen werden müssen.

Unsere Abnahme-Checkliste zum SSO-Offboarding behandelt verwandte Fragen zu Sitzungen und verbundenen Zugängen. Die Unterscheidung gilt auch hier: Eine Änderung der Authentifizierung zeigt für sich genommen nicht, welche bisherigen Berechtigungen oder Anmeldemittel beendet wurden.

Halten Sie das Ergebnis konkret fest: Der alte Browserzugang wurde widerrufen, das fehlende Anmeldemittel entfernt und ein benanntes Token erneuert, sofern diese Schritte tatsächlich erfolgt sind. „Konto wiederhergestellt“ ist zu ungenau, um dem nächsten Administrator zu sagen, ob ein Angreifer noch eine nutzbare Sitzung besitzen könnte.

Entscheiden Sie anhand der Übung über die Einführung

Machen Sie Passkeys verpflichtend, wenn Sie die unterstützten Anmeldewege verstehen und die verbleibenden Wiederherstellungsgrenzen akzeptiert haben. Eine erfolgreiche Übung liefert ein nutzbares Verfahren, einen verantwortlichen Administrator und eine Aufzeichnung des Zugangs, der nach der Ersatzregistrierung fortbesteht.

Halten Sie die Nachweise knapp. Notieren Sie für jedes Szenario die Ausgangslage, den versuchten Weg, das beobachtete Ergebnis und die nötige Änderung. Vermerken Sie Abhängigkeiten von bestimmten Personen, Postfächern, Anbietern oder Geräten. Beheben Sie fehlgeschlagene Schritte und testen Sie diese erneut, bevor Sie die Pflicht ausweiten.

Trennen Sie das technische Ergebnis von der Entscheidung. „Der Ersatzschlüssel ermöglichte die Anmeldung am Ersatzlaptop“ ist eine Beobachtung. „Vor der Einführung muss jedes Teammitglied einen separat verfügbaren Ersatz registrieren“ ist Ihre Richtlinienentscheidung. „Wir akzeptieren eine Verzögerung, bis ein autorisierter Administrator zurückkehrt“ ist ebenfalls eine mögliche Entscheidung, sofern das betroffene Team sie versteht.

Während der Einführung können Sie Bearbeitungszeit, Supportanfragen und abgebrochene Registrierungsversuche erfassen. Das sind Messwerte Ihres eigenen Verfahrens. Sie brauchen dafür weder einen erfundenen Branchenvergleich noch das Versprechen, Passkeys würden den Supportaufwand um einen bestimmten Prozentsatz senken.

Teilen Sie schließlich mit, was vor Beginn der Pflicht zu tun ist und wie später Hilfe angefordert wird. Erklären Sie, wo Anmeldemittel verwaltet werden, welche Ersatzwege Ihr Team unterstützt und was ein Administrator vor einer Ersatzregistrierung verlangt. Eine kurze Nachricht zu einem getesteten Verfahren hilft mehr als die pauschale Zusicherung, dass niemand ausgesperrt wird.

So funktioniert Passkey-Wiederherstellung in Kit

Ihre Anwendung muss ihre Zugangs- und Wiederherstellungsgrenzen so klar beschreiben, dass sie sich testen lassen. In Kit gehört ein Passkey zur Person. Ein Konto kann zugleich eine Passkey-Verifizierung verlangen, bevor ein Browser diesen Arbeitsbereich öffnet. Das betrifft den Teamzugang zum Produkt; der Zugang zum Kandidatenportal ist ein separates Verfahren.

Der Administrator, der die Pflicht aktiviert, muss bereits einen Passkey besitzen. Die Einstellung erfordert die Berechtigung Sicherheit verwalten, die den Rollen Admin und Security Analyst zur Verfügung steht. Eine allgemeine Ausnahme für Kontoinhaber gibt es nicht. Prüfen Sie vorher die Übersicht zur Erfüllung der Vorgabe durch die Mitglieder: Die Pflicht gilt sofort, ohne integrierte Übergangsfrist oder stufenweise Einführung.

Für die Browsersitzung muss eine Passkey-Verifizierung vermerkt sein. Dass ein Teammitglied ein Anmeldemittel registriert hat, belegt nicht, dass jeder bestehende Browser es verwendet hat. Nach der Verifizierung kann die Sitzung für ihre gesamte Laufzeit die Vorgabe erfüllen; die Richtlinie verlangt nicht auf jeder Seite eine neue Assertion. Auch eine Sitzung, die über verpflichtendes SAML authentifiziert wurde, kann die Vorgabe erfüllen. Die Stärke dieser Authentifizierung hängt von der Richtlinie Ihres Identitätsanbieters ab.

Verliert ein angemeldetes Teammitglied sämtliche Passkeys, kann ein autorisierter Sicherheitsadministrator eine Freigabe zur erneuten Registrierung ausstellen. Kit sendet sie direkt per E-Mail an das Mitglied. Der Link öffnet eine Bestätigungsseite. Die Bestätigung verbraucht die Freigabe und öffnet ein 15-minütiges Registrierungsfenster für dieses Konto. Die Freigabe ist innerhalb von 24 Stunden einmalig nutzbar; eine neue ersetzt die vorherige. Die Dokumentation zur Passkey-Pflicht erklärt das Verfahren.

Das Mitglied muss dafür weiterhin als derselbe Nutzer angemeldet sein. Dieses Verfahren verspricht nicht, eine vollständig unzugängliche Kit-Identität wiederherzustellen. Der Administrator muss die Anfrage unabhängig überprüfen, und die E-Mail-Zustellung bleibt Teil der Vertrauenskette. Eine erneute Registrierung widerruft außerdem nicht automatisch alte Browsersitzungen.

Für API-Token und MCP-Verbindungen gilt eine andere Grenze: Sie prüfen, ob ihr Nutzer einen Passkey registriert hat, statt eine WebAuthn-Assertion durchzuführen. Bewerten Sie dies bei verbundenen Werkzeugen als geringeres Vertrauensniveau als den Nachweis im Browser.

Testen Sie diese Grenzen, bevor Sie die Einstellung aktivieren. Beginnen Sie mit der Anleitung zur Passkey-Einrichtung. Testen Sie anschließend die Ersatzregistrierung und prüfen Sie mit einem weiteren autorisierten Administrator die Anmeldesicherheit. Das brauchbare Ergebnis ist ein Teammitglied, das dem Wiederherstellungsverfahren folgen kann, und ein Administrator, der genau weiß, welchen Zugang er wiederhergestellt hat.