Phishing-resistente MFA: welche Methoden standhalten und wo Sie sie zuerst erzwingen

Was phishing-resistente MFA ist und welche Methoden dazu zählen

Phishing-resistente Multi-Faktor-Authentifizierung (MFA) ist eine Form der MFA, bei der eine gefälschte Anmeldeseite die Antwort nicht abfangen und wiederverwenden kann, weil der Authentifikator sie an den Domainnamen des legitimen Dienstes oder an den verschlüsselten Kanal bindet. FIDO2-Sicherheitsschlüssel, Passkeys und andere WebAuthn-Authentifikatoren zählen dazu, ebenso Smartcards, mit denen die Anmeldung über eine Public-Key-Infrastruktur (PKI) läuft. Einmalcodes per SMS, aus Apps oder von Hardware-Token zählen nicht dazu, Push-Bestätigungen ebenso wenig. Das CISA-Factsheet „Implementing Phishing-Resistant MFA“ (Oktober 2022) nennt phishing-resistente MFA „den Goldstandard für MFA“.

NIST SP 800-63B-4, seit Juli 2025 final, definiert Phishing-Resistenz als die Fähigkeit des Protokolls, zu verhindern, dass Geheimnisse und gültige Ausgaben eines Authentifikators zu einem falschen Verifizierer gelangen, „ohne sich auf die Wachsamkeit des Anmeldenden zu verlassen“. Abschnitt 3.2.5 lässt zwei Verfahren gelten: die Bindung an den Namen des Verifizierers, bei der der Authentifikator sein Geheimnis anhand des authentifizierten Domainnamens des Verifizierers wählt, wie es WebAuthn tut, und die Kanalbindung an die TLS-Sitzung, wie bei Smartcards mit TLS-Client-Authentifizierung. Authentifikatoren mit manueller Eingabe, etwa OTP- und Out-of-Band-Authentifikatoren, „DÜRFEN NICHT als phishing-resistent betrachtet werden“, weil ein eingetippter Code nicht an die Sitzung gebunden ist, die gerade authentifiziert wird. Bei der Registrierung erzeugt ein FIDO-Authentifikator ein Schlüsselpaar, das nur für dieses Konto bei diesem Dienst gilt, und behält den privaten Schlüssel; laut FIDO Alliance wird „ein Passkey nur der Website vorgelegt, bei der er registriert wurde“.

Wie Angreifer MFA umgehen, die nicht phishing-resistent ist

Der Bericht ENISA Threat Landscape 2025, veröffentlicht im Oktober 2025, nennt Phishing „den dominierenden Einfallsvektor (60 %)“. Er beschreibt außerdem Phishing-as-a-Service-Plattformen, die Anmeldeseiten klonen, darunter ein Adversary-in-the-Middle-Kit, das MFA umgeht. Ein solches Kit schaltet sich als Proxy vor die legitime Anmeldeseite, reicht das Passwort und jeden eingetippten Code weiter, wartet eine etwaige Push-Bestätigung ab und behält das Session-Cookie, das der Dienst ausstellt.

CISA, FBI und fünf Partnerbehörden beschreiben weitere Wege in ihrer Warnmeldung zu den als Scattered Spider bekannten Akteuren (AA23-320A, erstmals veröffentlicht am 16. November 2023 und aktualisiert am 29. Juli 2025), die Social Engineering, Push-Bombing und SIM-Swapping einsetzen, um an Zugangsdaten zu gelangen und MFA zu umgehen. Sie schickten wiederholt MFA-Anfragen, bis Beschäftigte auf Accept drückten, gaben sich als IT-Personal aus, um Einmalpasswörter zu erhalten, und brachten Mobilfunkanbieter dazu, die Rufnummer eines Nutzers auf eine SIM-Karte in ihrem Besitz zu übertragen. Als Beschäftigte getarnt, riefen sie außerdem bei Helpdesks an, um Passwörter zurücksetzen und MFA auf ein von ihnen kontrolliertes Gerät übertragen zu lassen.

Nach der Anmeldung erkennt der Dienst den Nutzer an einem Session-Cookie oder Token, das Malware auf dem Endgerät kopieren und ohne zweiten Faktor wiederverwenden kann. NIST SP 800-63B-4 zählt Device Bound Session Credentials, eine neu entstehende Spezifikation, zu den Technologien, die „das Risiko des Diebstahls von Sitzungsgeheimnissen mindern“. Bei AAL2 SOLLTEN die Zeitlimits bis zur erneuten Authentifizierung höchstens 24 Stunden insgesamt und 1 Stunde bei Inaktivität betragen. Bei AAL3 MUSS das Zeitlimit insgesamt höchstens 12 Stunden betragen, und das Zeitlimit bei Inaktivität SOLLTE höchstens 15 Minuten betragen.

MFA-Methoden im Vergleich: welche phishing-resistent sind

Das Factsheet der CISA ordnet die MFA-Formen von phishing-resistenter MFA bis hinunter zu SMS oder Sprachanruf und stellt Push mit Number Matching über Push ohne Number Matching. NIST SP 800-63B-4 legt Anforderungen je Authenticator Assurance Level (AAL) fest, und bei AAL2 MUSS ein Verifizierer „mindestens eine phishing-resistente Authentifizierungsoption anbieten“. Codes per SMS und Sprachanruf behandelt NIST als eingeschränkte Authentifikatoren, die eine uneingeschränkte Alternative, einen Hinweis auf die Risiken und einen Migrationsplan voraussetzen.

CISA-Factsheet zu phishing-resistenter MFA (Oktober 2022), Tabelle 1; NIST SP 800-63B-4 (Juli 2025), Abschnitte 2, 3.1.3, 3.2.5, 3.2.9 und Anhang B; Passkey-Seite der FIDO Alliance. Die letzte Spalte ist unsere Empfehlung.

Das Assessment unserer Leistung Cyber-Resilienz umfasst Infrastruktur, Zugriffe und Backups und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Nennen Sie uns, welche MFA-Methoden Ihre Systeme heute akzeptieren und wo jede davon eingesetzt wird.

MFA-Fatigue und Number Matching

Das CISA-Factsheet „Implementing Number Matching in MFA Applications“ (Oktober 2022) erklärt, dass MFA-Fatigue, auch Push-Bombing genannt, „auftritt, wenn ein Cyber-Bedrohungsakteur einen Nutzer mit Push-Benachrichtigungen einer mobilen Anwendung bombardiert“, bis der Nutzer aus Versehen oder aus Verärgerung bestätigt. Dagegen empfiehlt die CISA Number Matching, eine Einstellung, bei der der Nutzer eine Zahl von der Identitätsplattform in die App eingeben muss, bevor die Anfrage bestätigt wird. Die Zahl erscheint auf dem Bildschirm dessen, der die Anmeldung gestartet hat; ein Nutzer, der sie nicht gestartet hat, hat also nichts einzugeben. Die CISA stellt Number Matching als Übergangsmaßnahme dar, bis phishing-resistente MFA eingeführt ist, und rät, Nutzer darin zu schulen, unbekannte oder massenhafte Anfragen zu melden, und abgelehnte Push-Anfragen zu untersuchen.

Die Out-of-Band-Regeln von NIST SP 800-63B-4 verlangen, dass der Nutzer ein Geheimnis zwischen den beiden Kanälen überträgt, etwa indem er die Zahl von der Anmeldeseite in die App eintippt, und die ältere Methode, zwei Werte zu vergleichen und auf dem Telefon zu bestätigen, „gilt nicht mehr als akzeptabel“. Number Matching beruht weiterhin auf manueller Eingabe und unterbindet deshalb blinde Bestätigungen, aber kein Relay, weil eine über einen Proxy durchgereichte Anmeldeseite dem Nutzer die legitime Zahl anzeigt.

Passkeys im Unternehmen: synchronisiert oder gerätegebunden

Die FIDO Alliance beschreibt Passkeys als FIDO-Zugangsdaten, mit denen man sich bei Apps und Websites über die Biometrie-, PIN- oder Musterprüfung des eigenen Geräts anmeldet. Passkeys, die über einen Cloud-Dienst zwischen den Geräten eines Nutzers kopiert werden, nennt sie „synchronisierte Passkeys“ und solche, die ein einzelnes Gerät nie verlassen, auch die auf FIDO-Sicherheitsschlüsseln, „gerätegebundene Passkeys“. Beide Arten sind phishing-resistent, und der Anhang von NIST zu synchronisierbaren Authentifikatoren hält fest, dass die Beschränkung eines synchronisierten Schlüssels auf die Domain, in der er erzeugt wurde, „verhindert, dass eine gefälschte Webseite eine Ausgabe des Authentifikators abgreifen und wiederverwenden kann“.

NIST SP 800-63B-4 lässt synchronisierbare Authentifikatoren bei AAL2 zu, wenn die Schlüssel im Synchronisierungsdienst nur verschlüsselt gespeichert sind, nur der authentifizierte Nutzer sie erreichen kann und der Zugriff auf sie mit einer MFA geschützt ist, die AAL2 entspricht; weil ihre Schlüssel exportierbar sind, „DÜRFEN sie bei AAL3 NICHT verwendet werden“. Für Schlüssel in der US-Bundesverwaltung verlangt NIST außerdem behördlich verwaltete Synchronisierungskonten und eine Geräteverwaltung, die das Synchronisieren auf nicht autorisierte Geräte oder Synchronisierungsdienste verhindert, und empfiehlt Attestierung.

Ein Unternehmen kann Beschäftigten Passkeys auf verwalteten Geräten geben, synchronisiert nur über Konten, die es selbst kontrolliert, und Administratoren und Break-Glass-Konten gerätegebundene Schlüssel zuweisen. Die WebAuthn-Flags Backup Eligible und Backup State zeigen dem Dienst, ob ein Schlüssel synchronisiert werden kann und ob er synchronisiert wurde, und die Attestierung weist das Schlüsselmodell aus, sodass der Dienst für diese Konten synchronisierte oder nicht freigegebene Schlüssel ablehnen kann.

Wo Sie phishing-resistente MFA zuerst erzwingen

Beginnen Sie dort, wo ein Konto Zugang zu vielen Systemen gibt. Die CISA schreibt, „wenn ein Cyber-Bedrohungsakteur das Konto eines Systemadministrators kompromittieren kann, kann er möglicherweise auf jedes System und alle Daten in der Organisation zugreifen“. Laut CISA nehmen Angreifer zudem oft E-Mail und Fernzugriff ins Visier, und gehostete E-Mail-Dienste und Single Sign-on, die meist FIDO unterstützen, sind gute Ausgangspunkte. Die folgende Reihenfolge passt zu einem Unternehmen mit 200 bis 2.000 Beschäftigten.

1. Administratorkonten, einschließlich der Admin-Rollen des Identity Providers und der Administratorkonten für Cloud und SaaS, getrennt von den Konten für die tägliche Arbeit und geschützt durch zwei gerätegebundene FIDO2-Sicherheitsschlüssel je Person.
2. Verwaltungskonsolen von Hypervisoren, Firewalls, Switches, Storage und Baseboard Management Controllern (BMCs), über föderierte Anmeldung, damit die MFA-Richtlinie des Identity Providers greift, oder andernfalls nur von einem Jump-Host aus, der phishing-resistente MFA verlangt; der Backup-Server behält eigene, MFA-geschützte Konten außerhalb des produktiven Verzeichnisdienstes.
3. Fernzugriff über VPN- und Remote-Desktop-Gateways, einschließlich der Zugangswege von Lieferanten.
4. E-Mail und jede Anwendung hinter Single Sign-on, für alle Beschäftigten, mit Passkeys oder Sicherheitsschlüsseln und mit Number Matching für alle, die noch nicht umgestellt sind.
5. Mit jedem Schritt die schwächeren Wege in dieselben Konten: SMS, Codes und Push entfernt, sobald eine Person Schlüssel oder Passkeys hat, weil eine Relay-Seite jede noch akzeptierte Methode anbieten kann, und Protokolle und Endpunkte, die nur ein Passwort verlangen, geschlossen oder auf benannte Systeme beschränkt.

Laut Broadcoms Dokumentation unterstützt vCenter seit vSphere 7.0 die föderierte Anmeldung über einen externen Identity Provider, und Mandiant riet am 23. Juli 2025, damit phishing-resistente MFA für alle Anmeldungen an vCenter zu erzwingen. Unser Leitfaden zur Härtung gegen ESXi-Ransomware zeigt, wie gestohlene Zugangsdaten aus dem Verzeichnisdienst bis zu vCenter und den Hosts reichen und warum vCenter-Rollen und Backup-Zugangsdaten außerhalb des Verzeichnisdienstes bleiben. Administratoridentitäten, Tresore und Just-in-Time-Rechte behandelt unser Leitfaden zu Privileged Access Management, den Platz der MFA unter den übrigen Kontrollen unser Zero-Trust-Leitfaden für den Mittelstand.

Im Rahmen unserer Leistung Cyber-Resilienz richtet unser Engineering-Partner Vixen.UNO Multi-Faktor-Authentifizierung als Teil einer Zero-Trust-Architektur ein, in vereinbarten Wartungsfenstern mit Rollback-Plan. Schreiben Sie uns, welche Konsolen und Gateways noch eine Anmeldung nur mit Passwort zulassen.

Registrierung, Kontowiederherstellung und Break-Glass-Konten

Angreifer, die den Authentifikator nicht überwinden können, nehmen sich Registrierung und Wiederherstellung vor. NIST SP 800-63B-4 fordert die Anbieter auf, die Nutzer dazu anzuhalten, „mindestens zwei getrennte Authentifizierungsmittel“ vorzuhalten, den Nutzer über einen unabhängigen Kanal zu benachrichtigen, wenn ein Authentifikator hinzukommt, und nach jeder Kontowiederherstellung eine Benachrichtigung zu senden. Für Beschäftigte heißt das zwei Schlüssel oder Passkeys je Person, registriert nur von einem verwalteten Gerät aus oder nach einer Identitätsprüfung. Am Helpdesk sollte keine Zurücksetzung allein auf einen Anruf hin erfolgen. Rufen Sie unter der Nummer aus der Personalakte zurück oder lassen Sie die Führungskraft bestätigen, prüfen Sie die Identität persönlich oder per Video und stellen Sie einen einmaligen Registrierungscode aus, der innerhalb von Stunden abläuft. Lösen Sie für jeden neuen Authentifikator, der an einem Administratorkonto registriert wird, eine Warnung aus.

Break-Glass-Konten sind für den Tag gedacht, an dem der Identity Provider, der Föderationsdienst oder der MFA-Dienst ausfällt. Halten Sie für den Identity Provider zwei davon vor, jedes mit eigenen FIDO2-Sicherheitsschlüsseln in getrennten Safes und einem langen Zufallspasswort, das offline aufbewahrt wird, und behandeln Sie den eingebauten lokalen Administrator jeder Konsole als Break-Glass-Konto mit einem Offline-Passwort. Nehmen Sie diese Konten von Regeln aus, die von einem einzigen Netzwerkstandort oder System abhängen, lösen Sie bei jeder Anmeldung eine Warnung aus und testen Sie sie nach festem Plan.

NIS2-Anforderungen an MFA: Nummern 11.6 und 11.7 der Verordnung 2024/2690

Artikel 21 Absatz 2 Buchstabe j der NIS2-Richtlinie nennt unter den Mindestmaßnahmen die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“, in der englischen Fassung mit dem Zusatz „where appropriate“. Die Durchführungsverordnung (EU) 2024/2690 konkretisiert die Maßnahmen für die in ihrem Artikel 1 genannten Anbieter aus den Bereichen digitale Infrastruktur, IKT-Dienste und digitale Dienste. Für andere wesentliche und wichtige Einrichtungen ist sie eine Referenz, keine Pflicht, und ob ein Unternehmen in den Anwendungsbereich fällt, ist eine rechtliche Bewertung, die seine Rechtsabteilung erstellt.

Nummer 11.7.1 verlangt, dass die Nutzer, soweit angemessen, „durch mehrere Authentifizierungsfaktoren oder kontinuierliche Authentifizierungsmechanismen“ authentifiziert werden, im Einklang mit der Klassifizierung der Anlage bzw. des Werts, auf die zugegriffen werden soll, und Nummer 11.7.2, dass die Stärke der Authentifizierung für diese Klassifizierung angemessen ist. Nummer 11.6.2 ergänzt gesonderte Authentifizierungsdaten für den Zugriff auf privilegierte Konten oder Verwaltungskonten, das Beenden inaktiver Sitzungen und die Sperrung von Nutzern nach einer vorab festgelegten Anzahl erfolgloser Anmeldeversuche, und Nummer 11.3.2 Buchstabe a nennt „Multifaktor-Authentifizierung“ für privilegierte Konten und Systemverwaltungskonten. Weder Nummer 11.6 noch Nummer 11.7 nennt ein bestimmtes Verfahren wie FIDO2 oder erwähnt Phishing.

Hält eine Einrichtung eine Anforderung mit dem Vorbehalt „soweit angemessen“ für nicht angemessen, muss sie nach Artikel 2 Absatz 2 der Verordnung ihre Begründung „in verständlicher Weise dokumentieren“; ein Register der Systeme ohne MFA, jedes mit seiner Begründung und einem Termin für die Überprüfung, ist deshalb für jedes Unternehmen ein nützlicher Nachweis. Kunden im Anwendungsbereich stellen ihren IT-Lieferanten dieselben Fragen, wie unser Leitfaden zu den NIS2-Anforderungen an die Lieferkette zeigt, und alle zehn Maßnahmen von Artikel 21 stehen in unserem Leitfaden zu NIS2 Artikel 21.

Was wir tun

Im Rahmen unserer Leistung Cyber-Resilienz baut unser Engineering-Partner Vixen.UNO eine Zero-Trust-Architektur nach NIST CSF 2.0 auf, mit Multi-Faktor-Authentifizierung, Privileged Access Management, Netzwerksegmentierung und Mobile Device Management (MDM). Das technische Assessment umfasst Infrastruktur, Zugriffe, Backups und NIS2-Anforderungen und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Änderungen werden Schritt für Schritt in vereinbarten Wartungsfenstern mit Rollback-Plan ausgerollt, und der Support läuft unter einem vereinbarten SLA weiter. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest.

FAQ