Bildquelle: Pexels / https://www.pexels.com/photo/black-and-white-padlock-60504/
Passwortfreie Logins brauchen den Service Desk als Sicherheitsnetz
Passwörter sind für den Betrieb ein Dauerproblem. Sie werden vergessen, wiederverwendet, phishbar gemacht, in Tickets diskutiert und bei Störungen oft unter Zeitdruck zurückgesetzt. Passkeys versprechen einen Ausweg, weil sich Nutzer damit ohne klassisches Passwort anmelden können. Der eigentliche Praxistest beginnt aber nicht beim ersten erfolgreichen Login. Er beginnt dann, wenn ein Handy verloren geht, ein Notebook ersetzt wird, ein Nutzer die Registrierung abbricht oder der Service Desk erklären muss, warum der alte Resetweg nicht mehr passt.
Für ITSM ist passwortfreie Anmeldung deshalb kein reines Sicherheitsthema. Sie verändert Supportprozesse, Rollen, Gerätewechsel, Onboarding, Offboarding und Notfallwege. Wer Passkeys nur als technische Funktion ausrollt, bekommt zwar modernere Anmeldung, aber noch keinen stabilen Betriebsprozess.
Der Sicherheitsgewinn braucht einen Betriebsplan
CISA beschreibt phishingresistente Mehrfaktor-Authentifizierung als Schutz gegen Angriffe, bei denen Nutzer zur Preisgabe von Zugangsdaten gebracht werden. Passkeys und FIDO2-basierte Verfahren passen in diese Richtung, weil sie nicht wie ein Passwort in eine falsche Webseite kopiert werden können. Auch NIST ordnet Authentifikatoren nach Eigenschaften wie Phishingresistenz und kontrollierter Nutzung ein. Für Entscheider klingt das überzeugend. Aus Betriebssicht stellt sich aber sofort die nächste Frage. Wie wird diese stärkere Anmeldung zuverlässig eingeführt, betreut und im Störungsfall abgesichert.
Der Service Desk ist dabei nicht die Reparaturstelle am Ende der Kette. Er ist die Stelle, an der Nutzerfrust, Sicherheitsanforderung und Arbeitsfähigkeit zusammentreffen. Wenn der Desk nicht weiß, welche Passkey-Arten erlaubt sind, wie ein Zweitgerät registriert wird und welche Ausnahmewege gesperrt sind, entsteht Druck zurück zum Passwort. Genau dieser Rückweg kann den Sicherheitsgewinn wieder schwächen.
Registrierung ist der erste Supportfall
Apple, Google und Microsoft erklären Passkeys aus Nutzersicht als einfache Anmeldung über Gerät, biometrische Freigabe oder PIN. Das ist hilfreich, weil es die Hürde senkt. Im Unternehmensalltag reicht die Produktbeschreibung aber nicht. Nutzer brauchen eine klare Anleitung, welche Geräte erlaubt sind, ob private Geräte genutzt werden dürfen, wie viele Schlüssel empfohlen werden und was bei gemeinsam genutzten Arbeitsplätzen gilt.
Ein guter Rollout beginnt deshalb mit einem Registrierungsprozess, der wie ein kleiner Service designt ist. Wer ist berechtigt. Welche Gruppen starten zuerst. Welche Mindestvoraussetzungen gelten für Betriebssystem, Browser, Identitätsplattform und Geräteschutz. Was passiert, wenn ein Nutzer nur ein Gerät besitzt. Welche Informationen sieht der Service Desk im Identitätssystem. Ohne diese Antworten wird die Einführung zum Experiment im laufenden Betrieb.
Gerätewechsel entscheidet über Akzeptanz
Passwortfreie Anmeldung wirkt nur dann alltagstauglich, wenn Gerätewechsel sauber funktionieren. Neue Smartphones, defekte Notebooks, verlorene Sicherheitsschlüssel oder Profilwechsel gehören zum normalen Arbeitsleben. Aus Nutzersicht ist entscheidend, ob der Zugriff schnell und sicher wiederhergestellt wird. Aus Sicherheitssicht ist entscheidend, dass genau dieser Wiederherstellungsweg nicht zum neuen schwachen Punkt wird.
Der Betrieb braucht darum abgestufte Prozesse. Ein registriertes Ersatzgerät kann einfacher sein als eine vollständige Identitätsprüfung nach Geräteverlust. Ein Administrator darf nicht unter Zuruf einen neuen Zugang freigeben. Der Service Desk braucht Prüfschritte, Eskalationsregeln und klare Grenzen. Besonders wichtig ist die Dokumentation. Wer hat wann welchen Authentifikator entfernt, ersetzt oder neu zugelassen. Ohne Nachweis wird aus einem Sicherheitsprojekt ein Auditproblem.
Ausnahmen dürfen nicht zum Standard werden
Jede starke Anmeldung braucht Ausnahmen. Es gibt Lieferanten, Altsysteme, geteilte Geräte, Produktionsumgebungen, Notfallkonten und Nutzergruppen mit besonderen Anforderungen. Der Fehler liegt nicht in der Ausnahme selbst. Der Fehler entsteht, wenn Ausnahmen dauerhaft unsichtbar bleiben. Dann wächst neben dem modernen Login ein alter Schattenprozess weiter.
ITSM kann hier helfen, weil es Ausnahmen als Service- und Risikofrage behandelt. Jede Ausnahme braucht Owner, Grund, Laufzeit, Ersatzplan und Reviewtermin. Ein Passwortfallback kann für eine Übergangsphase sinnvoll sein, darf aber nicht unbefristet ohne Kontrolle bestehen. Sonst wird aus passwortfrei in der Praxis passwortärmer, und das ist ein deutlich schwächeres Ziel.
Der Service Desk braucht andere Skripte
Ein klassisches Passwortproblem lässt sich oft mit bekannten Fragen lösen. Konto gesperrt, Passwort vergessen, Resetlink senden, neues Passwort setzen. Bei Passkeys verschiebt sich das Gespräch. Der Nutzer versteht vielleicht nicht, ob der Schlüssel auf dem Gerät, im Browserprofil, im Cloudkonto oder auf einem externen Sicherheitsschlüssel liegt. Der Desk muss deshalb nicht kryptografische Details erklären, aber er muss die Alltagssituation sauber sortieren.
Hilfreich sind Gesprächsleitfäden mit einfachen Fragen. Auf welchem Gerät funktioniert die Anmeldung noch. Wurde ein neues Gerät eingerichtet. Ist der alte Authentifikator verloren, verkauft oder nur gerade nicht verfügbar. Geht es um die Erstregistrierung oder um Wiederherstellung. Welche Anwendung ist betroffen. Diese Fragen verhindern, dass Tickets vorschnell als Loginfehler behandelt werden, obwohl eigentlich ein Geräte- oder Kontowechsel dahintersteht.
Was vor dem Rollout geklärt sein sollte
Vor der breiten Einführung sollte das Team eine kleine Betriebscheckliste abarbeiten. Erstens braucht es eine klare Policy für erlaubte Authentifikatoren und Plattformen. Zweitens braucht es einen Registrierungsprozess mit verständlicher Nutzerkommunikation. Drittens braucht es einen Wiederherstellungsprozess für Geräteverlust und Gerätewechsel. Viertens müssen privilegierte Konten, Notfallkonten und externe Nutzer gesondert betrachtet werden. Fünftens sollte der Service Desk in einer Pilotphase echte Fälle sammeln, bevor der Rollout skaliert.
Auch Monitoring gehört dazu. Nicht im Sinne einer Überwachung einzelner Nutzer, sondern als Betriebsbild. Wie viele Nutzer haben mindestens zwei belastbare Anmeldewege. Wie viele Tickets entstehen durch Registrierung. Wo treten Wiederherstellungsfälle auf. Welche Altanwendungen erzwingen noch Passwörter. Solche Kennzahlen machen sichtbar, ob passwortfreie Anmeldung wirklich stabiler wird oder nur neue Reibung erzeugt.
Fazit
Passkeys können einen wichtigen Sicherheitsgewinn bringen, weil sie klassische Passwortangriffe erschweren. Der Nutzen entsteht aber erst, wenn die Organisation den Betrieb mitdenkt. Registrierung, Ersatzgeräte, Sperrung, Wiederherstellung, Ausnahmen und Desk-Skripte sind keine Nebenthemen. Sie entscheiden darüber, ob Nutzer die neue Anmeldung akzeptieren und ob Sicherheitsziele im Alltag halten. Passwortfrei wird nicht durch eine Funktion erfolgreich, sondern durch einen Supportprozess, der den Ernstfall schon kennt.
