Bildquelle: Bildquelle: Pexels / Jakub Zerdzicki – https://www.pexels.com/photo/smartphone-nfc-access-control-in-modern-building-33335189/
Passkeys entlasten Passwort-Resets, erhöhen aber den Druck auf Gerätewechsel und Recovery
Viele IT-Teams verbinden Passkeys zuerst mit einem naheliegenden Vorteil: weniger Passwörter, weniger Phishing-Risiko, weniger Reset-Tickets. Das stimmt – aber nur zur Hälfte. Im operativen Alltag verschwindet der Supportaufwand nicht einfach, er wandert. Statt vergessener Kennwörter und MFA-Codes rücken Gerätebindung, Wiederherstellung, Ersatzgeräte und Ausnahmeregeln in den Mittelpunkt. Genau dort entscheidet sich, ob ein Passkey-Programm im Unternehmen wirklich stabil läuft.
Für Identity- und Workplace-Teams ist das wichtig, weil Passkeys nicht nur eine neue Anmeldemethode sind. Sie verändern den Supportpfad zwischen Benutzer, Gerät, Verzeichnisdienst, Recovery-Prozess und Sicherheitsrichtlinie. Wer nur auf die bessere Login-Erfahrung schaut, unterschätzt schnell die organisatorische Arbeit dahinter. Wer den Lebenszyklus sauber plant, bekommt dagegen tatsächlich weniger Reibung, bessere Phishing-Resistenz und klarere Betriebsmodelle.
Gerade diese Unterscheidung zwischen Sicherheitserfolg und Betriebsaufwand wird in vielen Projekten zu spät sauber besprochen. Ein Pilot mit modernen Notebooks und wenigen Admins sieht fast immer gut aus. Die eigentliche Bewährungsprobe beginnt erst, wenn Leihgeräte, Frontline-Nutzer, private Mobilgeräte, Hardwaredefekte, verlorene Telefone oder Rollenwechsel dazukommen.
Das Ende des Passwort-Resets ist nicht das Ende des Supportfalls
Die FIDO Alliance beschreibt Passkeys als stärkere und benutzerfreundlichere Alternative zu Passwörtern. Genau das ist im Alltag spürbar: weniger Tippfehler, weniger Wiederverwendung, weniger Passwort-Fatigue. Für den Service Desk kann das eine echte Entlastung sein, weil klassische Tickets wie „Passwort vergessen“, „Account gesperrt“ oder „MFA-Code kommt nicht an“ seltener werden.
Der Trugschluss beginnt dort, wo diese Einsparung als vollständiger Supportgewinn verbucht wird. Denn Passkeys lösen nicht das Grundproblem digitaler Identität, sondern verschieben den Schwerpunkt. Der kritische Moment ist nun seltener die Eingabe eines Geheimnisses, sondern häufiger die Frage, auf welchem Gerät ein Nutzer seinen Anmeldeweg besitzt, wie dieser auf ein Ersatzgerät kommt und welche sichere Rückfallroute bei Verlust oder Defekt verfügbar ist.
Für Support-Organisationen heißt das: Die Ticketarten ändern sich. Statt Kennwort-Reset und OTP-Problemen kommen Fälle wie „neues Firmenhandy“, „Laptop getauscht“, „Biometrie-Sensor defekt“, „Mitarbeiter im Ausland ohne Zweitgerät“ oder „Passkey auf privatem Gerät, aber Zugriff auf Firmenressource nötig“. Diese Fälle sind seltener banal als ein Passwort-Reset und greifen tiefer in Geräteverwaltung, Richtlinien und Sicherheitsfreigaben ein.
Gerätewechsel wird zur eigentlichen Sollbruchstelle
Microsoft macht in seiner Entra-Dokumentation deutlich, dass Unternehmen zwischen synchronisierten und gerätegebundenen Passkeys unterscheiden und dafür eigene Profile definieren können. Genau das ist keine Detailfrage, sondern die zentrale Betriebsentscheidung. Synchronisierte Passkeys reduzieren beim Gerätewechsel oft den Frust, weil Benutzer ihre Anmeldemethode leichter mitnehmen. Gerätegebundene Passkeys bieten dagegen in vielen Szenarien die strengere Kontrolle, erhöhen aber den Aufwand bei Defekt, Austausch oder Verlust.
In der Praxis sollte deshalb jede Organisation zuerst beantworten, welche Benutzergruppen welches Lebenszyklusmodell wirklich tragen. Für Wissensarbeiter mit verwalteten Smartphones, modernen Notebooks und gutem Self-Service kann ein synchronisierter Ansatz sinnvoll sein. Für privilegierte Rollen, getrennte Admin-Konten oder hochsensible Umgebungen ist ein gerätegebundener Ansatz oft nachvollziehbarer. Problematisch wird es, wenn dieselbe Policy pauschal über sehr unterschiedliche Nutzergruppen gelegt wird.
Vor allem Workplace-Teams brauchen an dieser Stelle ein ehrliches Bild der Gerätewirklichkeit. Wer viele Schichtmodelle, Pool-Geräte, externe Dienstleister oder gemeinsam genutzte Endpunkte hat, kann Passkeys nicht einfach wie ein reines Büro-Feature behandeln. Dann muss früh geklärt werden, welche Identitäten an persönliche Geräte gebunden werden dürfen, wo Hardware-Sicherheitsschlüssel sinnvoller sind und welche Gruppen bewusst bei alternativen Verfahren bleiben.
Recovery muss als Primärprozess geplant werden, nicht als Notnagel
NIST betont in SP 800-63B ausdrücklich, dass Authentikatoren nicht nur ausgegeben, sondern über ihren gesamten Lebenszyklus gepflegt und bei Verlust oder Diebstahl sauber invalidiert werden müssen. Genau das ist für Passkeys die operative Kernfrage. Ein Unternehmen ist nicht dann passkey-ready, wenn der Happy Path funktioniert, sondern wenn Recovery ohne Sicherheitsbruch und ohne Supportchaos läuft.
Viele Einführungen schwächeln hier, weil sie Recovery gedanklich an den Rand schieben. Im Alltag tritt der Randfall jedoch erstaunlich oft ein: Displaybruch, SIM-Wechsel, verlorenes Telefon, Remote-Mitarbeiter ohne physischen Support, versehentlich gelöschter Passkey, MDM-Reset oder Kontowechsel nach Rollenänderung. Wenn dann keine klare Wiederherstellungsroute dokumentiert ist, landet der Nutzer doch wieder in improvisierten Ausnahmen – häufig mit schlechterer Sicherheit als vorher.
Ein belastbares Modell braucht deshalb mindestens vier Dinge: einen registrierten Zweitfaktor oder Zweit-Passkey, klar definierte Helpdesk-Prüfschritte, einen kontrollierten Break-Glass-Pfad für echte Ausnahmefälle und saubere Sperrlogik für verlorene Geräte. Besonders wichtig ist, dass Recovery nicht auf stillen Insiderwissen beruht. Service Desk, IAM-Team und Sicherheitsverantwortliche müssen denselben Ablauf kennen und denselben Risikorahmen teilen.
Passkeys verschieben Verantwortung vom Verzeichnis stärker aufs Gerät
Bei klassischen Passwörtern lag ein großer Teil des Supportgeschehens direkt am Konto: Policy, Lockout, Reset, Ablauf, zweiter Faktor. Mit Passkeys rückt das Endgerät stärker ins Zentrum. Das ist sicherheitlich oft sinnvoll, operativ aber anspruchsvoller. Denn nun hängen Anmeldeprobleme häufiger an Hardwarezustand, lokalem Speicher, Biometrie-Konfiguration, Plattform-Sync oder Gerätezustand statt nur am Verzeichnisdienst.
Genau deshalb sollten Teams ihre Supportgrenzen neu schneiden. Ein Identity-Fall ist dann nicht mehr automatisch nur ein Verzeichnisfall. Oft braucht es die Zusammenarbeit zwischen IAM, Endpoint-Management und lokalem Support. Wenn diese Zuständigkeiten ungeklärt bleiben, entstehen Ping-Pong-Tickets: Der Service Desk verweist an Workplace, Workplace an Identity und Identity zurück an den Benutzer, obwohl der eigentliche Bruch im Zusammenspiel aller drei Ebenen liegt.
Hilfreich ist hier ein einfacher Supportbaum: Handelt es sich um Enrollment, um alltägliche Nutzung, um Recovery oder um Verlust? Liegt das Problem am Konto, am Gerät, an der Policy oder an einer fehlenden Ersatzmethode? Solche Leitfragen sparen im Betrieb mehr Zeit als jede Hochglanzankündigung zur passwordless Zukunft.
Privilegierte Konten und Frontline-Szenarien brauchen Sonderlogik
Besonders riskant wird es, wenn Organisationen Admin-Konten und Standardnutzer mit derselben Passkey-Erzählung behandeln. Privilegierte Rollen brauchen oft strengere Regeln für Gerätebindung, Attestation, Ersatzverfahren und Wiederherstellung. Ein verlorenes Standardgerät ist unangenehm. Ein blockiertes privilegiertes Administratorkonto mitten in einer Störung ist ein Betriebsrisiko.
Gleichzeitig dürfen Frontline- und Shared-Device-Umgebungen nicht aus dem Blick fallen. Dort sind persönliche Smartphone-Bindungen, geteilte Hardware oder unregelmäßige Schichten häufiger. Ein Passkey-Modell, das nur für den idealen Knowledge-Worker entworfen wurde, scheitert hier schnell an der Realität. Dann hilft kein zusätzlicher Slogan über Benutzerfreundlichkeit, sondern nur eine nüchterne Segmentierung nach Nutzertyp, Gerätelogik und Recovery-Fähigkeit.
Für viele Organisationen ist deshalb ein gestuftes Zielbild sinnvoller als eine Vollumstellung in einem Schritt. Zuerst gut standardisierte Gruppen, danach differenzierte Policies für sensible Konten, Sondergeräte und Shared-Use-Szenarien. Passkeys skalieren deutlich besser, wenn die Betriebssegmente von Anfang an sauber geschnitten sind.
Worauf IT- und Security-Teams jetzt konkret achten sollten
- Nicht nur die Anmeldung pilotieren: Gerätewechsel, Verlust, MDM-Reset und Rollenwechsel gehören in denselben Testplan wie der Happy Path.
- Synchronisierte und gerätegebundene Passkeys bewusst trennen: Die Wahl ist eine Betriebsentscheidung, nicht nur eine technische Option.
- Zweitwege verpflichtend machen: Zweitgerät, zweiter Passkey oder kontrollierter Recovery-Faktor sollten vor der breiten Einführung vorhanden sein.
- Supportzuständigkeiten neu definieren: Identity, Endpoint und lokaler Support brauchen eine gemeinsame Sicht auf Enrollment, Störung und Wiederherstellung.
- Privilegierte Konten separat behandeln: Break-Glass, Attestation und Ersatzlogik dürfen dort nicht identisch zum Standardnutzer sein.
- Erfolg an Lebenszyklus-Kennzahlen messen: Entscheidend sind nicht nur weniger Reset-Tickets, sondern auch saubere Recovery-Zeiten, geringe Ausfallquoten und kontrollierte Ausnahmewege.
Fazit
Passkeys verbessern die Anmeldung deutlich und können den Passwort-Support spürbar entlasten. Der eigentliche Reifegrad zeigt sich jedoch nicht am ersten Login, sondern beim ersten verlorenen Gerät, beim ersten Rollenwechsel und beim ersten Recovery unter Zeitdruck. Genau dort entscheidet sich, ob aus passwordless Sicherheit ein tragfähiges Betriebsmodell wird.
Für ITSM, IAM und Workplace heißt das: Weniger Passwort-Resets sind ein guter Anfang, aber nicht die ganze Rechnung. Wer Passkeys erfolgreich einführen will, muss Gerätebindung, Ersatzwege und Recovery als Kernprozess behandeln. Dann entsteht aus der neuen Anmeldemethode nicht nur ein Sicherheitsgewinn, sondern auch ein sauberer, belastbarer Supportpfad.
