Bildquelle: extern
Recovery entscheidet, ob Passkeys den Support entlasten oder neue Tickets erzeugen
Passkeys gelten zurecht als einer der sinnvollsten Schritte weg von Passwort-Müdigkeit, Phishing und endlosen Reset-Prozessen. Die FIDO Alliance verweist darauf, dass Organisationen mit wachsender Passkey-Nutzung deutlich weniger loginbezogene Helpdesk-Vorfälle sehen können. Gleichzeitig werben Plattformanbieter wie Microsoft damit, dass Passkeys schneller, phishing-resistenter und für Mitarbeitende einfacher nutzbar sind als Passwort plus Einmalcode.
Im Unternehmensalltag kippt dieser Vorteil aber schnell, wenn nur die Anmeldung modernisiert wird und der Recovery-Pfad alt bleibt. Denn die entscheidenden Supportfälle entstehen nicht beim idealen Login, sondern bei verlorenen Geräten, neu aufgesetzten Smartphones, Rollenwechseln, gesperrten Konten, abgelaufenen Registrierungen oder Mitarbeitenden, die zwar eine Passkey-Anmeldung eingerichtet haben, aber keinen zweiten belastbaren Weg mehr besitzen. Dann verschiebt sich das Problem nur: Statt Passwort-Reset-Tickets entstehen Passkey- und Identitäts-Tickets mit höherem Eskalationsaufwand.
Wer Passkeys im Unternehmen einführt, sollte das Thema deshalb nicht als UX-Feature, sondern als Betriebsprozess behandeln. Entscheidend ist die Frage, wie Nutzer wieder arbeitsfähig werden, wenn ihr primärer Passkey nicht verfügbar ist.
Recovery ist kein Randthema, sondern Teil des Sicherheitsmodells
Die Diskussion über Passkeys konzentriert sich oft auf den offensichtlichen Sicherheitsgewinn. Das ist nachvollziehbar. Nach Microsoft Learn sind Passkeys phishing-resistent, weil sie auf origin-gebundener Public-Key-Kryptografie beruhen und lokale Nutzerinteraktion verlangen. Genau das macht klassische Credential-Harvesting-Angriffe deutlich schwerer.
Für den Betrieb reicht diese Sicht aber nicht aus. NIST SP 800-63B beschreibt Authentifizierung ausdrücklich nicht nur als Anmeldung, sondern auch als Lebenszyklus mit Ausstellung, Pflege und Ungültigmachung von Authenticatoren bei Verlust oder Diebstahl. Genau an dieser Stelle hängt das operative Passkey-Modell. Wenn die Organisation nicht weiß, wie ein verlorener oder unbrauchbarer Authenticator ersetzt wird, ist die starke Anmeldung fachlich unvollständig.
Praktisch heißt das: Recovery darf nicht erst dann entworfen werden, wenn die ersten Vorstände oder Admins ausgesperrt sind. Der Recovery-Weg muss vor dem breiten Rollout feststehen, dokumentiert, getestet und im Service Desk trainiert sein.
Ohne zweite Registrierungsoption wird jeder Gerätewechsel zum Supportfall
Ein häufiger Fehler liegt in der zu knappen Ersteinrichtung. Mitarbeitende registrieren genau einen Passkey auf genau einem Gerät, oft auf dem gerade genutzten Smartphone. Solange alles funktioniert, wirkt das elegant. Beim Gerätewechsel, Defekt oder MDM-Reset entsteht dann aber sofort ein operativer Engpass.
Deshalb sollte die Erstanmeldung mindestens zwei belastbare Pfade hinterlassen. Das kann zum Beispiel eine Kombination aus synchronisiertem Passkey und zusätzlichem hardwaregebundenem Sicherheitsschlüssel sein. In Microsoft Entra lassen sich laut Dokumentation inzwischen Passkey-Profile mit Gruppenbezug definieren, inklusive Unterscheidung zwischen synchronisierten und device-bound Passkeys sowie Attestation- und Schlüsselfiltern. Genau diese Differenzierung ist operativ wertvoll: Standardanwender brauchen niedrige Reibung, privilegierte Konten brauchen strengere Wiederherstellungsregeln.
Für den Support bedeutet das eine einfache Leitfrage: Hat der Nutzer noch einen zweiten vertrauenswürdigen Anmeldepfad, der nicht vom gerade ausgefallenen Gerät abhängt? Wenn die Antwort regelmäßig nein lautet, ist nicht der einzelne Nutzer das Problem, sondern das Rollout-Design.
Unterschiedliche Nutzergruppen brauchen unterschiedliche Recovery-Regeln
Passkeys werden oft als universelle Lösung vermarktet. Im Betrieb sind sie das nicht. Ein Frontline-Mitarbeiter mit verwaltetem Smartphone, eine Entwicklerin mit mehreren Geräten und ein privilegierter Administrator haben nicht dieselben Anforderungen. Wer alle in dieselbe Passkey-Policy presst, produziert unnötige Sonderfälle.
Sinnvoller ist ein gruppiertes Modell. Für breite Nutzergruppen kann ein synchronisierter Passkey mit klaren Self-Service-Anleitungen reichen, solange Identitätsnachweise und Ersatzregistrierungen sauber geregelt sind. Für Admin-Konten oder besonders sensible Rollen sollte Recovery restriktiver sein: zweites Gerät, separater Sicherheitsschlüssel, definierter Break-Glass-Zugang und dokumentierte Freigabeschritte. Microsofts Passkey-Profile und Conditional-Access-Optionen unterstützen genau diese Trennung zwischen Komfort und Schutzbedarf.
Entscheidend ist, dass Recovery-Regeln nicht nur in IAM-Dokumenten stehen, sondern wirklich im Ticketbetrieb ankommen. Der Service Desk muss wissen, wann Self Service zulässig ist, wann eine manuelle Identitätsprüfung nötig wird und wann ein Fall direkt an Identity- oder Security-Verantwortliche eskaliert.
Service Desk, IAM und Security brauchen denselben Eskalationspfad
Viele Einführungen scheitern organisatorisch, nicht technisch. Der Service Desk sieht nur das gesperrte Konto, IAM verwaltet Richtlinien und Security bewertet Missbrauchsrisiken. Wenn diese drei Perspektiven getrennt laufen, werden Recovery-Fälle langsam und inkonsistent.
Ein belastbarer Passkey-Betrieb braucht deshalb ein kleines, aber klares Ablaufmodell. Dazu gehören mindestens: definierte Auslöser für Recovery, zugelassene Identitätsnachweise, erlaubte Ersatz-Authentikatoren, Fristen für Entzug verlorener Passkeys, Vier-Augen-Regeln für privilegierte Konten und ein nachvollziehbares Logging der Wiederherstellung. Besonders wichtig ist die Entscheidung, wann ein verlorenes Gerät nur ersetzt wird und wann zusätzlich ein mögliches Sicherheitsereignis vorliegt.
Gerade bei synchronisierten Passkeys unterschätzen Teams oft die Grenzfälle. Ein neues Telefon ist nicht automatisch ein Incident. Ein unerklärlicher Verlust des einzigen registrierten Authenticators kann aber sehr wohl einer sein. Diese Trennlinie muss der Betrieb vorher kennen.
Gute Kennzahlen messen nicht nur Adoption, sondern Wiederherstellbarkeit
Viele Programme betrachten lediglich die Zahl aktivierter Passkeys. Diese Kennzahl ist zu schwach. Ein sauberer Betrieb misst zusätzlich, wie gut Nutzer nach Störungen wieder arbeitsfähig werden. Relevante Kennzahlen sind etwa: Anteil der Nutzer mit mindestens zwei unabhängigen Registrierungen, Zahl der Recovery-Tickets pro 1.000 Nutzer, mittlere Wiederherstellungszeit, Anteil manuell eskalierter Fälle, Zahl entfernter verlorener Authenticatoren innerhalb definierter Fristen und Quote privilegierter Konten mit dokumentiertem Break-Glass-Pfad.
Erst mit solchen Kennzahlen wird sichtbar, ob Passkeys den Support wirklich entlasten oder nur die Ticketart verändern. Wenn die Passwort-Reset-Welle sinkt, gleichzeitig aber komplexe Identitätsfreigaben steigen, ist das Betriebsmodell noch nicht ausbalanciert.
Fazit
Passkeys sind fachlich stark, weil sie Sicherheit und Nutzerfreundlichkeit zusammenbringen können. Ihr betrieblicher Nutzen entsteht aber nicht automatisch mit der ersten erfolgreichen Anmeldung. Er entsteht erst dann, wenn Recovery als fester Teil des Identitätsbetriebs gestaltet wird: mit mindestens zwei belastbaren Registrierungswegen, unterschiedlichen Regeln für verschiedene Nutzergruppen, trainierten Eskalationspfaden und Kennzahlen für Wiederherstellbarkeit. Genau dann sinken nicht nur Phishing-Risiken, sondern auch die Supportkosten. Ohne dieses Fundament erzeugen Passkeys zwar modernere Logins, aber noch keinen stabileren Betrieb.
