Passkeys im Unternehmen einführen: Phishing-resistente Anmeldung mit Microsoft Entra ID

Ein Mitarbeitender meldet sich morgens an Microsoft 365 an, erhält eine täuschend echte Phishing-Mail und gibt sein Passwort auf einer gefälschten Anmeldeseite ein. Selbst wenn anschließend eine Einmalzahl abgefragt wird, kann ein Angreifer die Sitzung unter Umständen in Echtzeit übernehmen. Genau an dieser Stelle setzen Passkeys an: Sie bestätigen die Anmeldung kryptografisch und sind an die echte Website beziehungsweise den echten Identitätsanbieter gebunden. Eine nachgebaute Login-Seite kann diese Anmeldung nicht erfolgreich abfragen.

Für Unternehmen ist die Einführung von Passkeys mit Microsoft Entra ID jedoch kein reines Aktivieren einer Einstellung. Du veränderst Anmeldewege, Support-Prozesse und die Wiederherstellung von Zugängen. Wenn Geräte verloren gehen, Beschäftigte das Unternehmen verlassen oder ein neues Smartphone erhalten, muss dein Team sicher und nachvollziehbar handeln können. Wir zeigen dir, wie du Passkeys als phishing-resistente MFA praxistauglich einführst.

Infografik zu Passkeys im Unternehmen einführen: Phishing-resistente Anmeldung mit Microsoft Entra ID (KI-generiert).

Was Passkeys in Microsoft Entra ID leisten

Ein Passkey basiert auf dem FIDO2-Standard und arbeitet mit einem Schlüsselpaar. Der private Schlüssel verbleibt auf dem registrierten Gerät, in einem Sicherheitsschlüssel oder in einem geschützten Passkey-Speicher. Microsoft Entra ID erhält nur den öffentlichen Schlüssel. Bei der Anmeldung prüft der Dienst eine kryptografische Antwort statt eines wiederverwendbaren Kennworts.

Entscheidend für den Schutz vor Phishing ist die Bindung an die aufgerufene Website. Ein Passkey für die echte Microsoft-Anmeldung lässt sich nicht einfach auf einer Angreifer-Domain verwenden. Damit unterscheidet sich dieses Verfahren deutlich von SMS-Codes, Einmalpasswörtern oder Push-Bestätigungen, die Angreifer über Social Engineering oder einen Echtzeit-Proxy abfangen können.

Passkeys sind aber kein Freifahrtschein. Sie schützen nicht automatisch vor kompromittierten Endgeräten, gestohlenen Sitzungen, unsicheren Recovery-Prozessen oder einem Helpdesk, der Anrufer zu leicht als berechtigt einstuft. Die Einführung muss deshalb Identität, Gerät, Richtlinien und Support gemeinsam betrachten.

Voraussetzungen vor dem ersten Pilot

Prüfe zunächst, welche Anmeldemethoden im Mandanten bereits zugelassen sind. In Microsoft Entra ID steuerst du dies über die Richtlinien für Authentifizierungsmethoden. Dokumentiere dabei nicht nur die aktivierten Verfahren, sondern auch ihre Zielgruppen, Ausschlüsse und möglichen Abhängigkeiten.

Besonders wichtig sind diese Punkte:

• Prüfe die Lizenzierung und den Funktionsumfang deines Microsoft-Entra-ID-Mandanten.
• Ermittle, welche Betriebssysteme, Browser und mobilen Geräte im Unternehmen tatsächlich eingesetzt werden.
• Kläre, ob Mitarbeitende verwaltete Geräte nutzen oder ob private Geräte zugelassen sind.
• Prüfe, ob die vorhandenen Zugriffsrichtlinien moderne Authentifizierung voraussetzen.
• Identifiziere Altsysteme, Dienstkonten und Anwendungen, die noch Kennwörter, Legacy-Protokolle oder nicht interaktive Anmeldungen verwenden.
• Lege fest, welche Passkey-Varianten du zulassen willst: hardwaregebundene FIDO2-Sicherheitsschlüssel, Plattform-Passkeys oder beide.
• Stelle sicher, dass Protokollierung und Auswertung von Anmeldeereignissen eingerichtet sind.

Die letzte Entscheidung ist besonders wichtig. Hardware-Sicherheitsschlüssel sind in der Regel eindeutig einem physischen Gegenstand zugeordnet und eignen sich gut für privilegierte Rollen oder Bereiche mit hohen Anforderungen. Plattform-Passkeys nutzen die geschützte Anmeldung eines Geräts, etwa mit PIN, Biometrie oder Gerätesperre. Je nach Plattform und Konfiguration können Passkeys zwischen Geräten synchronisiert werden. Das verbessert die Nutzbarkeit, verändert aber deine Annahmen zur Gerätebindung und Wiederherstellung.

Wir empfehlen, nicht nur nach Komfort zu entscheiden. Definiere je Risikoklasse eine passende Methode. Administratoren, Finanzfreigaben und besonders schützenswerte Anwendungen benötigen häufig strengere Vorgaben als allgemeine Büroarbeitsplätze.

Pilotgruppe bewusst klein und repräsentativ wählen

Ein Pilot mit ausschließlich IT-affinen Freiwilligen liefert oft ein zu positives Bild. Wähle stattdessen eine Gruppe, die typische Arbeitsrealitäten abdeckt: Windows und macOS, mobile Nutzung, Büro und Homeoffice, unterschiedliche Browser sowie Mitarbeitende mit und ohne erhöhte Berechtigungen.

Für den Pilot eignen sich beispielsweise:

• Mitglieder des IT-Teams, die Fehlerbilder nachvollziehbar melden können.
• Mitarbeitende aus Fachbereichen mit unterschiedlichen Geräteprofilen.
• Einzelne Führungskräfte, sofern der Support für diese Gruppe vorbereitet ist.
• Eine begrenzte Gruppe privilegierter Konten mit separaten Sicherheitsvorgaben.

Trenne unbedingt Benutzerkonten von Administrationskonten. Wer administrative Tätigkeiten ausführt, sollte nicht dieselbe Passkey-Registrierung und dieselben Recovery-Wege wie für das alltägliche Benutzerkonto verwenden. Besonders privilegierte Konten benötigen zusätzlich klare Notfallkonten, strenge Überwachung und begrenzte Einsatzregeln.

Lege vor dem Pilot messbare Abnahmekriterien fest. Dazu zählen erfolgreiche Registrierungen, erfolgreiche Anmeldungen an typischen Arbeitsplätzen, Verhalten bei Gerätewechsel, Supportaufwand und die sichere Entfernung verlorener Passkeys. Sammle außerdem Rückmeldungen zu unklaren Dialogen, Browser-Unterschieden und mobilen Anmeldeabläufen.

Gerätebindung richtig verstehen und dokumentieren

Der Begriff „gerätegebunden“ wird häufig zu pauschal verwendet. Ein FIDO2-Sicherheitsschlüssel ist typischerweise ein separater physischer Authenticator. Er funktioniert an kompatiblen Geräten, bleibt aber als Schlüsselobjekt eigenständig. Ein Plattform-Passkey nutzt dagegen die Sicherheitsfunktionen des Endgeräts und dessen lokale Entsperrung.

Für deine Richtlinie musst du beantworten:

• Darf ein Passkey auf privaten Geräten registriert werden?
• Sind synchronisierte Passkeys für bestimmte Benutzergruppen zulässig?
• Muss für privilegierte Konten ein separater Hardware-Sicherheitsschlüssel eingesetzt werden?
• Wie viele Passkeys darf ein Konto registrieren?
• Wer genehmigt zusätzliche Registrierungen?
• Wann wird ein nicht mehr verwendeter Passkey entfernt?

Ein häufiger Rollout-Fehler besteht darin, nur eine einzige Registrierung zu erlauben. Verliert ein Mitarbeitender dann sein Smartphone oder seinen Sicherheitsschlüssel, entsteht sofort ein zeitkritischer Supportfall. Andererseits erhöht eine unbegrenzte Zahl registrierter Geräte die Angriffsfläche und erschwert die Kontrolle.

In der Praxis bewährt sich ein begrenztes, dokumentiertes Mehrgeräte-Prinzip. Beschäftigte registrieren einen primären Passkey und, sofern die Risikoanalyse es erlaubt, einen zweiten sicheren Passkey als Reserve. Für besonders kritische Rollen gelten strengere Freigaben. Wichtig ist nicht die gleiche Regel für alle, sondern eine nachvollziehbare und technisch überprüfbare Regel.

Recovery ist ein Sicherheitsprozess, kein Komfortfeature

Der kritischste Moment kommt, wenn der Passkey nicht mehr verfügbar ist. Ein verlorenes Telefon, ein defekter Laptop oder ein vergessener PIN dürfen nicht dazu führen, dass der Helpdesk unter Zeitdruck jede Identitätsbehauptung akzeptiert.

Definiere daher einen verbindlichen Recovery-Prozess. Er sollte mindestens diese Schritte enthalten:

1. Identität über einen zuvor festgelegten, unabhängigen Weg prüfen.
2. Verlust oder Gerätewechsel im Ticket dokumentieren.
3. Betroffene Passkeys und Sitzungen bewerten und bei Bedarf widerrufen.
4. Einen zeitlich und inhaltlich begrenzten Wiederzugang gewähren.
5. Neue Passkey-Registrierung unter kontrollierten Bedingungen durchführen.
6. Den temporären Zugang nach erfolgreicher Registrierung wieder entfernen.
7. Auffälligkeiten und wiederholte Recovery-Fälle an das Security-Team eskalieren.

Vermeide schwache Identitätsprüfungen wie die Abfrage leicht recherchierbarer Personendaten. Auch eine Bestätigung allein über eine bekannte E-Mail-Adresse reicht nicht aus, wenn genau dieses Postfach möglicherweise betroffen ist. Für sensible Rollen sollte die Wiederherstellung eine persönliche Prüfung, eine bestätigte Führungskraft oder einen zweiten, vorab vereinbarten Identitätsnachweis verlangen.

Notfallkonten sind ebenfalls notwendig, aber gefährlich. Sie dürfen nicht im Alltag verwendet werden, benötigen besonders starke Absicherung und müssen regelmäßig kontrolliert werden. Dokumentiere, wer sie nutzen darf, unter welchen Bedingungen sie eingesetzt werden und wie der Einsatz nachträglich geprüft wird.

Bestehende Methoden kontrolliert parallel betreiben

Du solltest Kennwörter und bisherige MFA-Verfahren nicht am ersten Tag für alle abschalten. Ein sicherer Parallelbetrieb ist nötig, darf aber nicht dauerhaft zur Umgehung des neuen Schutzes werden. Sonst wählen Beschäftigte im Zweifel weiterhin die bequemste, aber schwächere Methode.

Plane den Übergang in klaren Phasen:

Phase	Ziel	Wichtige Maßnahme
Vorbereitung	Voraussetzungen und Support klären	Richtlinien, Geräteprofile und Recovery testen
Pilot	Fehlerbilder erkennen	Kleine, repräsentative Gruppe begleiten
Ausweitung	Passkeys zum Standard machen	Kommunikation und gestaffelte Registrierung
Härtung	Schwache Ausweichwege reduzieren	Alte Methoden je Gruppe gezielt einschränken
Betrieb	Sicherheit dauerhaft erhalten	Logs, Registrierungen und Recovery-Fälle prüfen

Nutze bedingte Zugriffsrichtlinien, um Anforderungen schrittweise nach Benutzergruppe, Anwendung, Risiko und Gerätestatus durchzusetzen. Teste Ausschlüsse sorgfältig und dokumentiere jeden Ausnahmefall. Zu breite Ausnahmen für Administratoren oder externe Zugriffe sind eine typische Schwachstelle.

Wichtig ist auch die Kommunikation. Erkläre nicht nur, wie die Registrierung funktioniert, sondern warum der Passkey eingeführt wird, was bei einem Geräteverlust zu tun ist und welche Anmeldemethode künftig erwartet wird. Gute Anleitungen enthalten reale Bildschirmabläufe, eine kurze Fehlerhilfe und einen klaren Supportkontakt.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Typische Rollout-Fallen vermeiden

Die häufigsten Probleme entstehen nicht durch die Kryptografie, sondern durch unklare Zuständigkeiten. Wenn Identity-Team, Endpoint-Management, Helpdesk und Informationssicherheit getrennt planen, bleiben Lücken zwischen Registrierung, Geräteverwaltung und Recovery.

Achte insbesondere auf diese Warnsignale:

• Der Helpdesk kann Passkeys zurücksetzen, ohne die Identität belastbar zu prüfen.
• Privilegierte Konten nutzen dieselben Methoden wie normale Benutzerkonten.
• Alte MFA-Verfahren bleiben ohne Frist und ohne Kontrolle aktiv.
• Passkeys auf verlorenen oder ausgemusterten Geräten werden nicht entfernt.
• Externe Mitarbeitende und Dienstleister sind nicht in den Prozess einbezogen.
• Support-Mitarbeitende kennen den Unterschied zwischen Passkey-Registrierung, Passwort-Reset und Kontowiederherstellung nicht.
• Anmeldeprotokolle werden erst nach einem Vorfall ausgewertet.

Führe nach jeder Pilotphase eine kurze Sicherheitsbewertung durch. Prüfe, ob Nutzer auf schwächere Verfahren ausweichen, ob bestimmte Geräte wiederholt Probleme verursachen und ob Recovery-Fälle ungewöhnliche Muster zeigen. Daraus leitest du konkrete Anpassungen für Richtlinien und Support ab.

Passkeys als dauerhaften Sicherheitsstandard etablieren

Eine erfolgreiche Passkey-Einführung endet nicht mit der ersten Registrierung. Sie wird zum festen Bestandteil deines Identity-Lifecycle-Managements. Beim Eintritt neuer Mitarbeitender, bei Rollenwechseln, bei Gerätewechseln und beim Austritt müssen Passkey-Registrierungen berücksichtigt werden.

Wenn du den Rollout schrittweise aufbaust, Gerätebindung bewusst regelst und Recovery genauso streng wie die Anmeldung behandelst, erreichst du zwei Ziele gleichzeitig: Du senkst das Risiko erfolgreicher Phishing-Angriffe und vermeidest, dass die passwortlose Anmeldung zu einer neuen Belastung für Helpdesk und Fachbereiche wird.