Passkeys im Unternehmensbetrieb: Welche 5 Architekturentscheidungen IAM-Teams 2026 vor dem Rollout treffen sollten

Passkeys haben 2026 einen anderen Status als noch vor zwei Jahren. Sie sind nicht mehr nur ein interessantes Zukunftsthema für Consumer-Plattformen, sondern ein ernstzunehmender Baustein für den Unternehmenszugang. Der Grund ist fachlich klar: FIDO-basierte Passkeys sind phishing-resistent, vermeiden geteilte Geheimnisse wie klassische Passwörter und reduzieren den operativen Schaden durch Passwort-Resets, OTP-Müdigkeit und unsaubere MFA-Ausnahmen.

Genau deshalb reicht es aber nicht, Passkeys als nette Login-Option nebenher freizuschalten. Im Unternehmensbetrieb entscheidet nicht die Demo, sondern das Zielbild: Für welche Konten gelten Passkeys zuerst? Wo sind synchronisierte Passkeys vertretbar, wo braucht es gerätegebundene Schlüssel? Wie sieht Recovery aus, wenn ein Mitarbeiter sein Smartphone verliert? Und wie wird aus einer modernen Authentifizierung am Ende wirklich weniger Risiko im IAM-Betrieb?

FIDO beschreibt Passkeys als kryptografische Zugangsdaten, mit denen sich Nutzer per Biometrie, PIN oder Geräte-Entsperrung anmelden. Microsoft hat die Unternehmensseite inzwischen deutlich nachgeschärft, etwa mit gruppenbasierten Passkey-Profilen, Attestation, AAGUID-Restriktionen und der Möglichkeit, Passkeys über Authentication Strengths gezielt für sensible Ressourcen zu erzwingen. Für IAM- und Security-Teams heißt das: Die Technik ist da, aber der Rollout muss sauber modelliert werden.

Vor dem produktiven Start sollten vor allem diese fünf Architekturentscheidungen getroffen sein.

1. Zuerst Schutzklassen definieren, nicht zuerst eine breite Nutzerwelle starten

Viele Passkey-Initiativen beginnen mit einem generischen Pilot für „alle interessierten Nutzer“. Das wirkt niedrigschwellig, erzeugt aber oft wenig belastbare Erkenntnisse. Sinnvoller ist eine Schutzklassenlogik. Typische erste Gruppen sind privilegierte Admin-Konten, besonders schützenswerte Fachanwendungen, externe Zugriffe auf VPN oder VDI sowie SaaS-Dienste mit hoher Phishing-Exposition.

Der Vorteil liegt auf der Hand: Passkeys entfalten ihren größten Nutzen dort, wo Passwortdiebstahl, Session-Hijacking und MFA-Phishing heute reale Betriebsprobleme verursachen. NIST betont in SP 800-63B, dass für AAL2 eine phishing-resistente Option angeboten werden muss und AAL3 phishing-resistente Authenticatoren mit nicht exportierbaren Schlüsseln verlangt. Wer seine Konten und Anwendungen nach Risiko segmentiert, kann daraus direkt eine Rollout-Reihenfolge ableiten.

Praktisch heißt das: erst festlegen, welche Kontotypen und Zugriffswege wirklich priorisiert werden, dann Pilotgruppen bilden. Sonst endet der Rollout in einer netten User-Experience-Übung, ohne die kritischen Angriffsflächen zuerst zu entschärfen.

2. Synced und device-bound Passkeys bewusst trennen

Die wichtigste Architekturentscheidung ist nicht, ob Passkeys eingeführt werden, sondern welche Art von Passkeys für welche Nutzergruppen erlaubt ist. FIDO unterscheidet zwischen synchronisierten Passkeys, die über einen Passkey-Provider auf mehrere Geräte eines Nutzers verfügbar werden, und gerätegebundenen Passkeys, die ein Gerät oder einen Hardware-Schlüssel nicht verlassen.

Beides hat betriebliche Konsequenzen. Synchronisierte Passkeys sind im Alltag meist komfortabler und beschleunigen die Erstnutzung auf neuen Geräten. Gerade für breite Belegschaften kann das Adoption und Supportfähigkeit verbessern. Für hoch privilegierte Konten ist Komfort aber nicht das einzige Kriterium. Microsoft Entra unterstützt deshalb Passkey-Profile, mit denen sich Attestation erzwingen, Passkey-Typen festlegen und konkrete Authenticatoren über AAGUIDs erlauben oder blockieren lassen.

Eine praxistaugliche Leitlinie ist: Standardnutzer dürfen in klar definierten Szenarien synchronisierte Passkeys verwenden, privilegierte Rollen und Break-Glass-nahe Zugänge setzen auf gerätegebundene Authenticatoren, idealerweise Hardware-Keys mit nachvollziehbarer Attestation. Wer diese Trennung nicht von Anfang an plant, vermischt unterschiedliche Risikoklassen in einem einzigen Rollout und verliert später viel Zeit in Ausnahmediskussionen.

3. Recovery und Geräteverlust vor dem Go-live als Betriebsprozess festziehen

Viele Passkey-Projekte scheitern nicht an der Registrierung, sondern an der Frage: Was passiert am Montagmorgen, wenn ein Mitarbeiter sein primäres Gerät verliert, das Telefon tauscht oder beim ersten Login auf einem neuen Notebook keinen Zugriff auf den alten Passkey hat? FIDO argumentiert zu Recht, dass Passkeys viele klassische Recovery-Probleme entschärfen können. Im Unternehmensbetrieb verschwindet Recovery damit aber nicht, es verlagert sich nur.

Deshalb braucht es vor dem Rollout einen klaren Prozess mit Rollen, Nachweisen und Freigaben. Welche alternativen Authentifizierungswege sind zulässig? Dürfen Helpdesks Passkeys zurücksetzen oder nur den Registrierungsstatus bereinigen? Welche Prüfung ist für Admin-Konten nötig? Und wie werden verlorene Hardware-Keys oder kompromittierte Geräte revisionssicher aus dem Bestand entfernt?

Besonders wichtig ist, Recovery nicht wieder mit schwächeren Faktoren zu unterlaufen. Wer phishing-resistente Anmeldung einführt, darf bei der Wiederherstellung nicht reflexhaft auf unsichere E-Mail-Links oder triviale Telefonprozesse zurückfallen. Genau hier entscheidet sich, ob Passkeys im Betrieb wirklich das Sicherheitsniveau heben oder nur an der Oberfläche moderner wirken.

4. Anwendungen, Policies und Authentication Strengths zusammen planen

Passkeys bringen wenig, wenn sie zwar im zentralen IdP aktiviert sind, die kritischen Anwendungen sie aber nicht konsequent verlangen oder bestehende Ausnahmen weiter offenlassen. Microsoft beschreibt den sauberen Weg recht deutlich: Passkey-Profile für Zielgruppen definieren und anschließend über Conditional Access beziehungsweise Authentication Strengths dort erzwingen, wo das höhere Vertrauensniveau tatsächlich gebraucht wird.

Für die Praxis bedeutet das eine Kopplung aus Anwendungsinventar, Zugriffspfaden und Policy-Design. IAM-Teams sollten vorab beantworten: Welche SaaS- und internen Anwendungen authentifizieren direkt gegen den zentralen IdP? Wo gibt es Altprotokolle oder Legacy-Fallbacks? Welche Workloads benötigen Step-up-Authentifizierung? Und welche Ausnahmen existieren heute für Service Desks, Notfallkonten oder externe Partner?

Ein sauberer Rollout startet deshalb nicht im Self-Service-Portal, sondern im Policy-Modell. Erst wenn klar ist, für welche Ressourcen Passkeys optional, bevorzugt oder verpflichtend sind, entsteht ein steuerbares Betriebsbild. Sonst werden Passkeys aktiviert, aber nie in der Fläche wirksam.

5. Client-Readiness und Supportmodell realistisch bewerten

Die technische Unterstützung für Passkeys ist 2026 deutlich besser, aber nicht homogen. Microsoft nennt Mindestvoraussetzungen für Windows-Geräte und differenziert je nach Join-Modell, Authenticator und Plattformstand. Dazu kommen Unterschiede bei Browsern, mobilen Betriebssystemen, Sicherheitsrichtlinien auf verwalteten Geräten und der Frage, welche Passkey-Provider im Unternehmen überhaupt zulässig sind.

Wer das ignoriert, produziert vermeidbare Reibung: Registrierungen schlagen nur auf bestimmten Geräten fehl, Mitarbeiter verstehen die Unterschiede zwischen lokalem Sicherheitsschlüssel und synchronisiertem Passkey nicht, und der Service Desk bekommt Tickets, die eigentlich Architekturfragen sind. Deshalb sollte jedes Rollout vorab mindestens vier Dinge messen: unterstützte Endgeräte, unterstützte Browser, zulässige Passkey-Provider und die Erfolgsquote der Registrierung pro Zielgruppe.

Ebenso wichtig ist ein angepasstes Supportmodell. Service Desks brauchen Entscheidungsbäume für Registrierung, Verlust, Gerätewechsel und Policy-Fehler. IAM-Teams brauchen Kennzahlen wie Erfolgsquote bei Erstregistrierung, Zahl der Recovery-Fälle, Anteil unsauberer Fallbacks und reduzierte Passwort-Reset-Last. Erst dann lässt sich zeigen, ob Passkeys nicht nur sicherer, sondern auch betriebswirtschaftlich sinnvoller sind.

Fazit

Passkeys sind 2026 kein Experiment mehr, sondern ein ernsthafter Architekturbaustein für Unternehmenszugänge. Ihr Nutzen entsteht aber nicht automatisch durch eine neue Login-Methode, sondern durch klare Entscheidungen zu Schutzklassen, Passkey-Typen, Recovery, Policy-Erzwingung und Supportfähigkeit. Wer diese fünf Punkte sauber modelliert, senkt Phishing-Risiken spürbar, reduziert Passwort-lastige Betriebsaufwände und schafft ein IAM-Zielbild, das moderner und kontrollierbarer ist. Wer Passkeys dagegen nur als Komfortfunktion einführt, verschiebt alte Schwächen in ein neues Interface.

Quellen

• FIDO Alliance: Passkeys overview and FAQ
• Microsoft Learn: How to enable passkeys (FIDO2) in Microsoft Entra ID
• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management