Bildquelle: Pexels Foto von Jakub Zerdzicki
Passkeys im Unternehmenszugang: Was IT-Teams bei Pilot, Recovery und Richtlinien wirklich festziehen müssen
Passkeys gelten 2026 längst nicht mehr als nette Zukunftsoption für Consumer-Logins. Sie sind zu einem ernsthaften Baustein für Unternehmenszugänge geworden, weil sie ein altes Problem adressieren, an dem viele Sicherheitsprogramme noch immer hängen: Passwörter bleiben phishbar, Reset-Prozesse teuer und klassische MFA mit OTP oder Push-Freigaben operativ fehleranfällig. Genau deshalb wächst der Druck auf Identity- und Workplace-Teams, phishing-resistentere Verfahren nicht nur zu testen, sondern kontrolliert in den Regelbetrieb zu bringen.
Wer Passkeys nur als „Passwort abschaffen“-Projekt behandelt, läuft allerdings schnell in typische Sackgassen. In Unternehmen geht es nicht nur um den eigentlichen Login, sondern um Gerätestandards, Recovery, Helpdesk, Admin-Konten, Rollout-Gruppen und Fallback-Regeln. FIDO verweist in seinen Enterprise- und Rollout-Unterlagen ausdrücklich darauf, dass Passkeys im ersten Schritt als zusätzliche Anmeldeoption eingeführt werden sollten. Microsoft Entra zeigt zugleich, wie stark sich Passkey-Profile heute bereits gruppenbasiert steuern lassen. Für IT-Teams ist das die entscheidende Nachricht: Der Nutzen entsteht nicht durch einen großen Schalter, sondern durch saubere Betriebsarchitektur.
Fünf Punkte sind für einen brauchbaren Einstieg besonders wichtig.
1. Nicht von „dem einen Passkey“ sprechen, sondern den Risikotyp festlegen
Im Alltag werden Passkeys oft pauschal diskutiert, technisch und organisatorisch macht die Unterscheidung aber viel aus. Microsoft Entra unterstützt sowohl synchronisierte Passkeys als auch gerätegebundene Passkeys, etwa auf FIDO2-Sicherheitsschlüsseln oder im Microsoft Authenticator. NIST SP 800-63B zieht ebenfalls klare Linien zwischen verschiedenen Authenticator-Typen und verlangt für höhere Assurance-Niveaus stärkere Eigenschaften, etwa phishing-resistente Verfahren und bei AAL3 nicht exportierbare Schlüssel.
Für Unternehmen heißt das praktisch: Nicht jede Nutzergruppe braucht denselben Passkey-Typ. Für Standard-Workforce-Zugänge können synchronisierte Passkeys den Rollout beschleunigen, weil Mitarbeitende geräteübergreifend arbeiten und weniger Reibung im Onboarding entsteht. Für privilegierte Admin-Konten, Produktionszugänge oder regulierte Umgebungen kann ein gerätegebundener Ansatz mit Hardware-Key oder streng begrenztem Authenticator sinnvoller sein. Wer diese Trennung nicht früh zieht, produziert später unnötige Ausnahmen oder verwässert die eigene Sicherheitsargumentation.
2. Pilotgruppen und Richtlinien vor dem Massenrollout festzurren
Ein häufiger Fehler ist der Wunsch, Passkeys tenantweit sichtbar zu machen und dann auf organische Adoption zu hoffen. Das kann bei einfachen Umgebungen funktionieren, in heterogenen Unternehmenslandschaften ist es meist zu grob. Microsoft empfiehlt dafür inzwischen Passkey-Profile, die sich gezielt Gruppen zuweisen lassen. Dort lassen sich unter anderem Passkey-Typen, Attestation und Einschränkungen über AAGUIDs steuern.
Das ist operativ wertvoll, weil ein Pilot nicht nur nach Abteilung, sondern nach Gerätelage und Supportfähigkeit gebaut werden sollte. Eine sinnvolle erste Welle besteht oft aus technisch affinen Mitarbeitenden mit verwalteten Endgeräten, klarem MDM-Standard und engem Feedback-Kanal. Weniger geeignet sind zu Beginn Nutzergruppen mit gemischten privaten Geräten, gemeinsam genutzten Arbeitsplätzen oder geschäftskritischen Sonderanwendungen, die bereits bei kleinen Authentifizierungsabweichungen eskalieren.
FIDO beschreibt für Rollouts zwei Grundmuster, eine graduelle und eine schnelle Einführung. Für die meisten Unternehmen ist die graduelle Variante belastbarer, weil sie Kommunikation, Support und Metriken besser mitwachsen lässt. Ein Pilot ohne klare Austrittskriterien ist dagegen nur eine Demo mit Budget.
3. Recovery und Break-Glass vor dem ersten Go-live sauber definieren
Passkeys senken Passwortprobleme, sie beseitigen aber nicht die Notwendigkeit für Wiederanlaufpfade. Genau hier unterschätzen viele Teams den Betriebsaufwand. Passkey Central führt bei den typischen Problemfeldern ausdrücklich Themen wie verlorene oder gestohlene Geräte, mehrere Credential-Provider und Verwirrung über mehrere Passkeys pro Konto auf. Im Unternehmenskontext kommt dazu die Frage, wie ein gesperrter Mitarbeitender, ein neuer Laptop oder ein defektes Mobilgerät ohne Sicherheitsbruch behandelt wird.
Vor einem Live-Pilot sollten deshalb mindestens vier Entscheidungen dokumentiert sein: Erstens, welche Recovery-Methoden zugelassen sind. Zweitens, wie ein Geräteverlust verifiziert und administrativ verarbeitet wird. Drittens, welche Break-Glass-Konten bewusst außerhalb des Standardpfads betrieben werden. Viertens, welche Altverfahren nur temporär als Fallback geduldet werden und wann sie wieder verschwinden.
Besonders kritisch sind Administratorkonten. Wer dort Passkeys einführt, ohne einen streng kontrollierten Notfallpfad zu definieren, verlagert das Risiko nur. Gute Identity-Teams behandeln Recovery deshalb als Teil des Zielbilds und nicht als nachträgliche Supportnotiz.
4. Helpdesk und Endnutzerkommunikation als eigenes Arbeitspaket behandeln
Viele technische Pilotprojekte scheitern nicht an Kryptografie, sondern an missverständlichen Nutzererwartungen. FIDO betont in seinen Design- und Troubleshooting-Unterlagen, dass der Passkey-Betrieb vom Zusammenspiel mehrerer Ebenen abhängt: Betriebssystem, Browser, Credential Manager, Hardware, Zielanwendung und Endnutzer. Genau deshalb entstehen Störungen oft an Übergängen, etwa bei Cross-Device-Sign-in, bei unterschiedlichen Credential-Managern oder wenn Nutzer nicht verstehen, wo ihr Passkey eigentlich gespeichert ist.
Für den Helpdesk bedeutet das: Die Supportlogik muss vor dem Rollout neu zugeschnitten werden. Ein klassisches Skript wie „Passwort zurücksetzen und erneut testen“ greift hier nicht mehr. Stattdessen brauchen Service Desk und IAM-Support klare Entscheidungsbäume für Fälle wie neues Smartphone, verlorener Sicherheitsschlüssel, fehlgeschlagene WebAuthn-Zeremonie, blockierte Browserfunktion oder inkonsistente Geräte-Pop-ups. Ebenso wichtig ist eine knappe, verständliche Nutzerkommunikation, die nicht mit Sicherheitsjargon überlädt.
Gerade im Unternehmensumfeld lohnt es sich, zwei oder drei häufige Störbilder vorab in Knowledge-Artikel und interne Supportmakros zu übersetzen. Das spart Eskalationen in den ersten Wochen erheblich.
5. Passkeys erst dann erzwingen, wenn Metriken und Fallback-Abbau zusammenpassen
Der eigentliche Mehrwert entsteht nicht beim Pilot, sondern in der Phase danach. NIST fordert für AAL2 phishing-resistente Optionen, und Microsoft verweist auf Conditional-Access-Mechanismen beziehungsweise Authentication Strengths, um Passkeys für sensible Ressourcen gezielt zu verlangen. Genau das sollte aber erst passieren, wenn das Unternehmen belastbare Nutzungsdaten und einen klaren Rückbauplan für alte Verfahren hat.
Wichtige Steuerungsgrößen sind nicht nur Registrierungsquoten. Entscheidender sind erfolgreiche Sign-ins, Zeit bis zur erfolgreichen Anmeldung, Quote der Recovery-Fälle, Helpdesk-Tickets pro Nutzergruppe und die Anzahl der Zugänge, die weiterhin an Passwort plus OTP hängen. Erst wenn diese Werte stabil sind, ist es sinnvoll, Passkeys schrittweise für privilegierte Bereiche oder besonders sensible Anwendungen verbindlich zu machen.
Ebenso wichtig ist der kontrollierte Abbau von Altverfahren. Wenn Passwort, SMS-OTP, Push-MFA und Passkeys dauerhaft parallel laufen, bleibt die stärkere Methode operativ unterlaufen. FIDO empfiehlt ausdrücklich, Passkeys zunächst zusätzlich einzuführen, danach aber die nächste Ausbaustufe bewusst zu planen. Für IT-Teams heißt das: Fallback ist ein Übergangszustand, kein Zielbild.
Fazit
Passkeys sind im Unternehmenszugang kein UX-Gimmick mehr, sondern ein realer Architekturwechsel in der Authentifizierung. Der praktische Erfolg hängt jedoch weniger an der Technik selbst als an der Betriebsdisziplin rundherum. Wer Passkey-Typen nach Risiko trennt, Pilotgruppen sauber zuschneidet, Recovery und Break-Glass früh festlegt, den Helpdesk vorbereitet und den Fallback-Abbau über echte Metriken steuert, kann den Einstieg kontrolliert schaffen. Wer dagegen nur eine neue Login-Option sichtbar macht, wird zwar moderne Screens zeigen, aber noch kein belastbares Identitätsmodell betreiben.
