Passkeys und phishingresistente MFA: Änderungen für die Anmeldung im Unternehmen

Ein Code aus SMS oder Authenticator-App ist besser als nur ein Kennwort, kann vom Benutzer aber weiterhin in eine betrügerische Seite eingegeben werden. Ein Passkey auf Basis von FIDO2 und WebAuthn funktioniert anders: Der Authentifikator erzeugt einen kryptografischen Nachweis, der an einen bestimmten Dienst gebunden ist. Der Benutzer bestätigt kein Geheimnis, das er einem Angreifer übergeben könnte.

Deshalb gelten Passkeys und Sicherheitsschlüssel als phishingresistente Authentifizierungsmethoden. Sie sind dennoch kein magischer Schutz für das gesamte Konto. Registrierung, Kontowiederherstellung, Endgerät, bestehende Sitzungen, privilegierte Konten und Altanwendungen müssen genauso konsequent abgesichert werden.

Was Phishingresistenz bedeutet

NIST definiert Phishingresistenz als Schutz davor, dass Authentifizierungsgeheimnisse oder gültige Ergebnisse einem betrügerischen Prüfer offengelegt werden, ohne sich auf die Aufmerksamkeit des Benutzers zu verlassen. Manuell eingegebene OTP sind nicht phishingresistent: Der Benutzer kann einen gültigen Code auf einer vom Angreifer kontrollierten Seite eintragen.

WebAuthn nutzt Verifier-Name-Binding und bindet die Authentifizierung praktisch an den korrekten Web-Ursprung oder Domänenkontext des Diensts. Für einen abweichenden Phishing-Ursprung erzeugt der Authentifikator keine gültige Antwort. Diese kryptografische Bindung – nicht nur der Komfort von Biometrie oder PIN – schützt vor gewöhnlichem Anmeldephishing.

So funktioniert ein Passkey

1. Bei der Registrierung erzeugt der Authentifikator ein Schlüsselpaar für einen bestimmten Dienst.
2. Öffentlicher Schlüssel und Kennung werden beim Dienst gespeichert; der private Schlüssel bleibt im Authentifikator geschützt.
3. Bei der Anmeldung sendet der Dienst eine einmalige Challenge.
4. Der Benutzer bestätigt sich lokal mit PIN, Biometrie oder einem anderen Gerätemechanismus.
5. Der Authentifikator signiert die Challenge nur im richtigen Dienstkontext, der Server prüft sie mit dem öffentlichen Schlüssel.

Eine biometrische Vorlage wird bei normaler Nutzung nicht wie ein Kennwort an den Webdienst gesendet. Sie entsperrt den Authentifikator lokal. Das genaue Verhalten hängt dennoch von Plattform und Richtlinie ab; unterstützte Geräte müssen getestet werden.

Gerätegebundene und synchronisierte Passkeys

Ein gerätegebundener Passkey bleibt an einen bestimmten Authentifikator wie Sicherheitsschlüssel oder Gerät gebunden. Ein synchronisierter Passkey kann das Credential innerhalb eines unterstützten Ökosystems auf mehreren Geräten verfügbar machen. NIST stellt zusätzliche Anforderungen an Schutz, Zugriff und Verwaltung synchronisierbarer Authentifikatoren.

Die Wahl ist nicht nur technisch. Gerätegebundene Credentials können Administratoren eine stärkere physische Kontrolle bieten, benötigen aber einen Ersatzschlüssel und einen Verlustprozess. Synchronisierte Passkeys reduzieren Reibung für Benutzer, während die Organisation Synchronisationskonto, unterstützte Plattformen, Wiederherstellung und Verwaltungsgrenze verstehen muss.

Aktueller Stand in Microsoft Entra ID

Microsoft dokumentiert FIDO2-Passkeys in zwei Profilen: gerätegebunden und synchronisiert. Die Kompatibilitätsdokumentation führt beide als allgemein verfügbar. Die Methode lässt sich in der Authentication methods policy auf Gruppen ausrichten; im Profil können erlaubte Typen oder AAGUIDs von Authentifikatoren eingeschränkt werden.

Microsoft nennt Passkey-Authentifizierung in allen Microsoft-Entra-ID-Editionen ohne separate Zusatzlizenz für diese Authentifizierungsmethode. Soll die Organisation Passkeys über Conditional Access Authentication Strengths erzwingen oder andere erweiterte Kontrollen nutzen, müssen die Lizenzbedingungen dieser Funktion getrennt geprüft werden. Verfügbarkeit der Methode und Lizenz der Richtlinie sind nicht dasselbe.

Was ein Passkey nicht löst

• Malware oder Fernzugriff auf einem bereits entsperrten, kompromittierten Endgerät;
• Diebstahl einer bestehenden Websitzung oder eines Tokens;
• Social Engineering beim Helpdesk und schwache Kontowiederherstellung;
• unsichere Registrierung eines neuen Authentifikators durch einen Angreifer mit aktiver Sitzung;
• eine Altanwendung ohne FIDO2 oder moderne Authentifizierung;
• einen fehlenden Prozess bei Geräteverlust, Mitarbeiteraustritt oder Telefonwechsel.

Praktischer Pilot im Unternehmen

1. Anmeldung erfassen. Identitäten, Geräte, Browser, Mobilplattformen, VPN und Altanwendungen ermitteln.
2. Pilotgruppe auswählen. Mit IT und einer kleinen Gruppe verschiedener Geräte beginnen; Administratorkonten in einem getrennten strengen Profil behandeln.
3. Authentication methods policy konfigurieren. Den gewählten Passkey-Typ nur für die Pilotgruppe aktivieren und den Änderungseigentümer dokumentieren.
4. Bootstrap vorbereiten. Die erste Registrierung sicher verifizieren und verhindern, dass ein Angreifer eine schwächere Anfangsmethode ausnutzt.
5. Wiederherstellung vorbereiten. Festlegen, wie der Helpdesk Identität prüft, das verlorene Gerät entfernt und einen neuen Authentifikator bereitstellt.
6. Negativszenarien testen. Phishing-Domäne in kontrollierter Schulung, Geräteverlust, Offline-Benutzer, neues Telefon und nicht unterstützte Anwendung testen.
7. Registrierungen und Anmeldungen überwachen. Unerwartete Methoden, Geräte, Fehler und schwächere Fallback-Pfade erkennen.
8. In Wellen erweitern. Die alte Methode erst nach bestätigter Abdeckung und funktionierender Wiederherstellung entfernen.

Privilegierte Konten brauchen eigene Regeln

Administratorkonten haben größere Auswirkungen. Für sie sind gerätegebundene Sicherheitsschlüssel, getrennte Arbeitsstationen, mindestens zwei registrierte Authentifizierungsoptionen und eingeschränkte Wiederherstellung zu erwägen. Der Ersatzschlüssel gehört nicht in dieselbe Hülle wie der primäre. Notfallkonten müssen nach dokumentiertem Prozess separat verwaltet, überwacht und getestet werden.

Eine phishingresistente Methode bietet den größten Wert, wenn ein schwächerer Fallback die gesamte Richtlinie nicht umgehen kann. Auditieren Sie deshalb erfolgreiche Passkey-Anmeldungen ebenso wie Registrierungen und alternative Methoden.

Checkliste vor der Erweiterung

• unterstützte Kombinationen aus Gerät, OS und Browser sind bekannt;
• der Pilot enthält gerätegebundene und synchronisierte Szenarien, falls beide geplant sind;
• die Registrierung eines neuen Passkeys erfordert angemessene Verifikation;
• der Helpdesk hat einen sicheren, geübten und auditierbaren Wiederherstellungsprozess;
• Administratoren besitzen einen getrennt aufbewahrten Ersatz-Authentifikator;
• Conditional-Access-Verhalten und Lizenzierung sind für die geplante Richtlinie geprüft;
• Legacy- und Notfallpfade sind begrenzt, überwacht und einem Eigentümer zugeordnet.

Wie Yenwa helfen kann

Unsere Cybersecurity-Leistungen prüfen Methoden, privilegierte Konten, Wiederherstellung und schwache Fallback-Pfade. Im Rahmen der Microsoft-Cloud-Dienste bereiten wir Entra-ID-Pilot, Gruppenzielsteuerung, Kompatibilitätstests und messbare Erweiterungskriterien vor.

Die stärkste Authentifizierungsmethode hilft nicht, wenn das gesamte Konto über einen schwächeren, unkontrollierten Prozess wiederhergestellt werden kann.