Passwortlose Kontowiederherstellung braucht TAP und eine Identitätsprüfung

In vielen Microsoft-365- und Entra-ID-Tenants melden sich die Anwender:innen heute standardmäßig ohne Passwort an, und für die Sicherheit ist das ein echter Gewinn. Nach etlichen Projekten taucht aber immer wieder dieselbe Frage auf: Was passiert, wenn ein:e Anwender:in das einzige passwortlose Anmeldemittel verliert, etwa einen Passkey oder das Smartphone mit Authenticator-App und Passkey? Auf dem Papier wirkt die passwortlose Kontowiederherstellung elegant. In der Praxis lauern jedoch einige Stolpersteine, die man beim Recovery-Prozess von Anfang an einplanen muss.

Die Kontowiederherstellung wird zum neuen Angriffspunkt

Wer konsequent auf passwortlose Methoden setzt, nimmt Angreifern die einfachen Passwortangriffe weg und zwingt sie auf andere Wege. Damit rücken die Recovery-Optionen in den Mittelpunkt ihres Interesses. In vielen Tenants, die ich betreue, gab es anfangs keinen durchdachten Plan für den Verlustfall. Self-Service-Optionen wie Self-Service Password Reset (SSPR) waren entweder zu offen oder zu streng eingestellt, und wer sein letztes Gerät verloren hatte, kam oft überhaupt nicht mehr ins Konto. Richtig gefährlich wird es, solange noch Recovery-Mechanismen wie E-Mail-Links oder ungeprüfte Telefonnummern aktiv sind. Genau dort sollte man bei der Umstellung ansetzen und die veränderte Risikolage im Auge behalten. Mehr dazu steht in meinem Artikel Temporary Access Pass in Entra ID: Onboarding und Recovery.

Der Helpdesk stellt den Temporary Access Pass erst nach einer Identitätsprüfung aus

Für eine sichere passwortlose Kontowiederherstellung ist der Temporary Access Pass (TAP) heute das wichtigste Werkzeug. Mit der passenden Rolle, in der Regel Authentication Administrator, stellt der Helpdesk den betroffenen Anwender:innen direkt einen TAP aus (Entra admin center → Benutzer → Benutzer auswählen → Authentifizierungsmethoden → Authentifizierungsmethode hinzufügen → Temporary Access Pass). Damit kann sich die Person einmalig anmelden und anschließend ein neues passwortloses Verfahren registrieren, zum Beispiel einen neuen Passkey oder die Authenticator-App. Schwierig ist eher der Schritt davor: Der Helpdesk muss zweifelsfrei feststellen, dass sich tatsächlich die richtige Person meldet.

Dafür haben sich inzwischen mehrere Wege etabliert:

• Bestätigung durch den/die direkte:n Vorgesetzte:n (Manager Confirmation)
• Einsatz von Verified ID Face Check
• Kombination aus bekannten Prozessfragen und persönlichem Kontakt

Mit dem Verified ID Face Check habe ich in der Praxis gute Erfahrungen gemacht. Die Prüfung ist robust und datenschutzfreundlich, weil beim Helpdesk kein Ausweisdokument liegen bleibt, und sie skaliert gut. Organisationen ohne geeignetes Verfahren sollten das dringend auf ihre Roadmap setzen. Einen TAP ohne vorherige Identitätsprüfung auszugeben, verbietet sich.

sequenceDiagram
  participant User as "[Nutzer:in]"
  participant Helpdesk as "[Helpdesk]"
  participant Manager as "[Manager]"
  participant System as "[Entra ID System]"
  User->>Helpdesk: "[Meldet Geräteverlust]"
  Helpdesk->>Manager: "[Bestätigung Identität]"
  Manager-->>Helpdesk: "[Identität bestätigt]"
  Helpdesk->>System: "[Stellt TAP aus]"
  System-->>User: "[TAP wird zugestellt]"
  User->>System: "[Registriert neue passwortlose Methode]"

Abbildung: Recovery-Prozess mit Temporary Access Pass und Bestätigung durch den Vorgesetzten

Ein zweiter Passkey verhindert die meisten Recovery-Fälle

In Projekten wird gern übersehen, dass ein zweiter passwortloser Faktor pro Person der beste Schutz vor Recovery-Notfällen ist. Wer seinen Passkey im Authenticator auf mehreren Geräten hat, etwa auf Smartphone und Laptop, oder zusätzlich einen FIDO2-Token nutzt, arbeitet nach einem Geräteverlust einfach mit dem verbleibenden Faktor weiter. Entra ID erlaubt inzwischen ohne Weiteres mehrere Passkeys pro Konto (Details und Anleitung). Trotzdem verwenden viele Nutzer:innen nur „das eine Gerät“. Schulungen und verständliche Anleitungen helfen viel, damit die Zahl der Recovery-Fälle gering bleibt.

Mein Praxistipp: Lassen Sie schon beim Onboarding zwei Geräte für die passwortlose Anmeldung registrieren. Das spart Helpdesk-Tickets und gibt den Nutzer:innen ein sicheres Gefühl.

SSPR hilft nur mit einer zusätzlichen Backup-Methode weiter

Für die passwortlose Recovery ist SSPR (Self-Service Password Reset) zweitrangig, auch wenn die Funktion im System weiterhin auftaucht. Sie greift nur, wenn mindestens ein alternatives Authentifizierungsverfahren aktiv ist, etwa eine weitere Authenticator-App oder eine hinterlegte und geprüfte Telefonnummer. Wer gar keine Backup-Methoden zulässt, wie ich es in Hochsicherheitsumgebungen häufig erlebe, muss den Anwender:innen deutlich sagen, dass im Verlustfall nur der Weg über den Helpdesk und einen TAP bleibt. Unsichere SSPR-Methoden wie E-Mail als Wiederherstellungsweg sind schon für sich ein Einfallstor und gehören abgeschaltet. Eine offene Kommunikation und eine gut gepflegte Dokumentation der Recovery-Prozesse ersparen allen Beteiligten Missverständnisse und Ärger. Passend dazu empfehle ich meinen Beitrag Authentifizierungsmethoden-Richtlinie in Entra ID: Migration.

Die Rolle Authentication Administrator gehört unter strenge Kontrolle

Auch bei der Governance gibt es einen heiklen Punkt, nämlich die Vergabe der Rolle Authentication Administrator. In produktiven Umgebungen sollte nie der gesamte Helpdesk diese Rolle dauerhaft besitzen. Besser ist es, sie gezielt zuzuweisen und am besten über Privileged Identity Management nur für begrenzte Zeit zu aktivieren. Recovery-Vorgänge lassen sich auditieren und sollten regelmäßig in Stichproben nach dem Vier-Augen-Prinzip geprüft werden. In sensiblen Tenants kann man den Ablauf zusätzlich mit Genehmigungsschritten und Protokollierung absichern.

Der Recovery-Prozess gehört von Anfang an ins Passwortlos-Konzept

Wer passwortlose Authentifizierung einführt, muss die Wiederherstellung mindestens so sorgfältig planen wie die Anmeldung selbst. Nach mehreren Einführungen sehe ich die Recovery als festen Baustein des Security- und Compliance-Konzepts und keineswegs als Randthema. TAP und Verified ID Face Check sind technisch ausgereift. Vor Missbrauch schützen sie allerdings erst, wenn die Abläufe sauber festgelegt sind, die Rollen eindeutig verteilt sind und die Organisation ausreichend sensibilisiert ist. Im Ernstfall soll schließlich die richtige Person schnell wieder ins Konto kommen und eben nicht der Angreifer.