Du hast MFA aktiviert — und fühlst Dich sicher. Genau dieses Gefühl nutzen Angreifer 2026 gnadenlos aus. Denn die klassische MFA, die in den meisten Tenants läuft (SMS-Code, App-Bestätigung per Push), ist längst kein verlässlicher Schutz mehr. Adversary-in-the-Middle-Kits wie Evilginx fangen Session-Token in Echtzeit ab, MFA-Fatigue-Angriffe bombardieren Deine Nutzer so lange mit Push-Anfragen, bis einer aus Versehen „Genehmigen" tippt, und SIM-Swapping hebelt SMS-Codes komplett aus.
Die Antwort heißt phishing-resistente MFA (englisch: phishing resistant MFA) — also Authentifizierungsmethoden, die sich technisch nicht abfangen oder weiterleiten lassen: Passkeys (FIDO2), Windows Hello for Business und zertifikatsbasierte Authentifizierung. In diesem Guide zeige ich Dir, wie Du diese Methoden in Microsoft Entra ID aktivierst, sie per Conditional Access verbindlich erzwingst und den Rollout in einem KMU sauber durchziehst — inklusive Break-Glass, Admin-Priorisierung und externen Gästen. Phishing-resistente MFA ist einer der wirkungsvollsten Bausteine der Entra ID Best Practices, den jeder Tenant umsetzen sollte.
Alles Wichtige auf einen Blick
Warum klassische MFA 2026 nicht mehr reicht
MFA war jahrelang die wichtigste Einzelmaßnahme gegen Kontoübernahmen — und sie ist immer noch besser als gar nichts. Aber „MFA an" ist nicht gleich „MFA sicher". Die Methoden, die in den meisten Tenants als zweiter Faktor laufen, haben drei konkrete Schwachstellen, die heute aktiv ausgenutzt werden.
Adversary-in-the-Middle (AiTM)
Das ist die gefährlichste Klasse. Der Angreifer schickt einen Phishing-Link, der nicht auf eine plumpe Fake-Seite führt, sondern auf einen Reverse-Proxy, der die echte Microsoft-Anmeldeseite live durchreicht. Der Nutzer gibt Passwort und MFA-Code ein, der Proxy leitet beides an Microsoft weiter — und greift im Gegenzug das fertig authentifizierte Session-Cookie ab. Damit ist der zweite Faktor wertlos: Der Angreifer braucht weder Passwort noch Code erneut, er übernimmt einfach die laufende Sitzung. SMS-Code, OTP aus der Authenticator-App und Standard-Push schützen hier nicht, weil sie alle vom Nutzer übertragen und damit abfangbar sind.
MFA-Fatigue (Push Bombing)
Hat ein Angreifer das Passwort (etwa aus einem Leak), löst er im Sekundentakt Push-Benachrichtigungen aus. Irgendwann genehmigt der genervte oder unaufmerksame Nutzer eine davon — oft nachts. Microsoft hat mit Number Matching gegengesteuert, und das hilft spürbar. Es ist aber eine Schadensbegrenzung, kein struktureller Schutz: Die Methode bleibt eine Bestätigung, die der Mensch aktiv erteilen muss.
SIM-Swapping und SS7
SMS und Telefonanruf als zweiter Faktor hängen an der Mobilfunknummer. Per Social Engineering beim Mobilfunkanbieter (SIM-Swap) oder über Schwächen im SS7-Protokoll lassen sich diese Codes umleiten. Microsoft selbst empfiehlt SMS seit Jahren explizit nur noch als Notlösung. Wer Microsoft MFA-Bypass verhindern will, kommt an einem Wechsel weg von Telefon-basierten Methoden nicht vorbei.
Die Liability dahinter ist konkret: Eine kompromittierte Admin-Identität bedeutet im schlimmsten Fall einen Tenant-Totalschaden — der Angreifer legt neue Global Admins an, deaktiviert Sicherheitsrichtlinien und exfiltriert Daten. Bei einem meldepflichtigen Vorfall steht die Geschäftsführung nach DSGVO Art. 32 und im NIS2-Kontext in der Verantwortung, „angemessene" technische Maßnahmen nachzuweisen. „Wir hatten doch MFA" reicht einem Auditor nicht, wenn diese MFA nachweislich umgehbar war.
Was phishing-resistente MFA technisch bedeutet
Der entscheidende Unterschied: Phishing-resistente Methoden binden die Authentifizierung kryptografisch an die echte Domain und übertragen nie ein Geheimnis, das abgefangen werden könnte. Das schließt AiTM-Proxys, Fatigue und SIM-Swap konstruktionsbedingt aus. Microsoft fasst diese Methoden unter passwortloser und phishing-resistenter Authentifizierung zusammen.
Nicht phishing-resistent sind dagegen: SMS, Sprachanruf, OTP-Codes, Standard-Push und auch Push mit Number Matching. Letzteres ist ein guter Zwischenschritt, fällt aber in der Microsoft-Klassifikation nicht unter „phishing-resistant".
Technisch stehen hinter all dem zwei offene Standards: FIDO2 und WebAuthn — herstellerübergreifend von der FIDO Alliance und dem W3C getragen. Genau deshalb funktionieren Passkeys plattformübergreifend, egal ob die Anmeldeinformationen in einem Hardware-Security-Key, im Apple- oder Google-Ökosystem oder im TPM eines Windows-Geräts liegen. Für Admins ist eine Unterscheidung wichtig: gerätegebundene Passkeys (device-bound, z. B. auf einem FIDO2-Hardware-Key) verlassen das Gerät nie und gelten als die stärkste Variante — ideal für Admin-Konten. Synchronisierte Passkeys dagegen werden über die Cloud des Anbieters (Apple, Google, Microsoft) zwischen den Geräten eines Nutzers geteilt; das ist komfortabler und gut für die Breite, weil der Nutzer beim Gerätewechsel nicht ausgesperrt wird. In beiden Fällen ist und bleibt die Signatur an die echte Domain gebunden — der entscheidende Phishing-Schutz geht nicht verloren. Welche Hardware Du zulässt, steuerst Du über die AAGUID-basierten Key Restrictions in der Richtlinie.
Eine Einordnung, wie diese Methoden in das größere Bild aus Risikobewertung und adaptiven Richtlinien passen, findest Du in unserem Beitrag zu risikobasierten Zugriffsrichtlinien und bei Entra ID Identity Protection.
Passkeys in Microsoft Entra ID aktivieren
Passkeys aktivierst Du zentral in der Authentifizierungsmethoden-Richtlinie. Die Schritte:
Damit Nutzer einen Passkey registrieren können, sollten zwei Dinge stehen: Erstens die kombinierte Registrierung für Sicherheitsinformationen (Standard in modernen Tenants), zweitens idealerweise eine geführte Registrierung über einen Temporary Access Pass (TAP) — gerade für den Erst-Rollout, wenn der Nutzer noch keine starke Methode hat. Die offizielle Schritt-für-Schritt-Anleitung steht bei Microsoft Learn: Passkeys (FIDO2) aktivieren.
Für Windows-Geräte läuft Windows Hello for Business parallel — auf Entra-joined-Geräten oft schon per Standardrichtlinie aktiv. Details zur Architektur findest Du in der Microsoft-Learn-Dokumentation zu Windows Hello for Business.
Phishing-resistente MFA per Conditional Access erzwingen
Das eigentliche Durchsetzen passiert über Conditional Access in Kombination mit Authentication Strengths. Authentication Strengths sind benannte Stärke-Stufen, die festlegen, welche Methoden eine Anmeldung erfüllen muss. Microsoft liefert drei eingebaute Stufen — die für uns relevante heißt „Phishing-resistant MFA" und akzeptiert ausschließlich Passkey/FIDO2, Windows Hello for Business und CBA. Hintergrund dazu im Microsoft-Learn-Artikel zu Authentifizierungsstärken.
So baust Du die Richtlinie:
Die Mechanik der Grant-Controls ist im Microsoft-Learn-Artikel zu Conditional-Access-Gewährungssteuerungen beschrieben. Wenn Du tiefer in das Richtlinien-Design einsteigen willst, lohnt der Blick in unsere Conditional Access Best Practices und in den Grundlagenbeitrag Conditional Access für Deine Microsoft-365-Umgebung. Für fortgeschrittene Szenarien — etwa Stärke nach Risiko staffeln — siehe erweiterte Conditional-Access-Richtlinien.
Ein häufig übersehener Effekt: Authentication Strengths greifen auch gegen Token-Diebstahl, weil eine erneut erzwungene starke Authentifizierung gestohlene Sessions entwertet. Wie Du das gezielt kombinierst, zeigt der Beitrag Token-Diebstahl mit Conditional Access verhindern.
Sonderfälle: Admins, Break-Glass und externe Gäste
Admin-Konten zuerst
Privilegierte Konten sind das lohnendste Ziel und der größte Hebel. Erzwinge phishing-resistente MFA zuerst für alle administrativen Rollen — Global Administrator, Security Administrator, Exchange Administrator und Co. Das ist technisch derselbe CA-Schritt wie oben, nur mit der Zielgruppe „Verzeichnisrollen". Idealerweise koppelst Du das mit Privileged Identity Management, sodass die Rolle nur Just-in-Time und nur nach phishing-resistenter Anmeldung aktivierbar ist. Diese Reihenfolge ist auch deshalb klug, weil die Admin-Gruppe klein ist: Du sammelst Erfahrung mit dem Rollout an wenigen, technisch versierten Nutzern, bevor Du in die Breite gehst.
Break-Glass sauber lösen
Das ist der Punkt, an dem die meisten Rollouts scheitern oder gefährlich werden. Du brauchst mindestens zwei Notfall-Zugangskonten (Break-Glass), die von Deinen CA-Richtlinien ausgenommen sind — sonst sperrst Du Dich bei einem Fehler komplett aus Deinem eigenen Tenant aus. Aber „ausgenommen von CA" darf nicht „ungeschützt" heißen.
Meine Empfehlung für Break-Glass im Zeitalter phishing-resistenter MFA: Statte die Notfallkonten mit eigenen FIDO2-Hardware-Keys aus, die physisch im Safe liegen. So bleiben sie phishing-resistent, ohne von der erzwingenden Richtlinie abzuhängen. Überwache jede Anmeldung dieser Konten per Alert. Die vollständige Einrichtung beschreibt unser Guide zur Break-Glass-Access-Application.
Externe und B2B-Gäste
Gäste bringen ihre eigene Identität mit — Du kannst ihnen keine Methode in Deinem Tenant aufzwingen. Hier hilft die Cross-Tenant Access-Einstellung „MFA von externen Organisationen vertrauen" in Kombination mit einer Authentication-Strength-Richtlinie, die auch für Gäste gilt. Akzeptiert der Heimat-Tenant des Gastes phishing-resistente Methoden, wird die Stärke durchgereicht. Andernfalls fällt der Gast auf eine im Gast-Tenant registrierte Methode zurück. Für die saubere Konfiguration externer Zusammenarbeit siehe Entra ID Gastzugriff.
Migrationsfahrplan für KMU (50–500 Mitarbeitende)
Ein Big-Bang-Rollout produziert volle Helpdesks und Frust. In meinen Projekten fahre ich vier Phasen:
Typische Stolperfallen, die ich immer wieder sehe:
Wer den Reifegrad seiner Identitätsabsicherung insgesamt heben will, findet ergänzende Maßnahmen in unseren Härtungs-Tipps im Identity-Management. Phishing-resistente MFA zahlt außerdem direkt auf Deinen Microsoft Secure Score ein, weil sie gleich mehrere Identitäts-Empfehlungen abdeckt — und sie ist ein zentraler Baustein der allgemeinen Multi-Faktor-Authentifizierung in Microsoft 365, nur eben in ihrer stärksten Ausprägung.
Ein Hinweis zur Vollständigkeit: Phishing-resistente MFA schützt die Anmeldung. Sie ersetzt nicht die Absicherung der E-Mail-Schicht gegen Betrug — wie ein Angreifer trotz starker Identitäten über CEO-Fraud und Business Email Compromise Schaden anrichtet und wie Du das technisch unterbindest, liest Du im Schwester-Beitrag Microsoft 365 gegen BEC & CEO-Fraud härten.
Self-Check: Ist Deine MFA phishing-resistent?
Drei Fragen, die Du in fünf Minuten beantworten können solltest:
Konntest Du nicht jede Frage mit einem klaren „Ja" beantworten, hat Dein Tenant eine umgehbare Stelle — und genau die suchen Angreifer.
Häufige Fragen zu phishing-resistenter MFA
Was ist der Unterschied zwischen phishing-resistenter MFA und normaler MFA?
Klassische MFA — SMS-Code, Authenticator-Push oder TOTP — belegt einen zweiten Faktor, lässt sich aber über eine gefälschte Anmeldeseite in Echtzeit weiterreichen (Adversary-in-the-Middle) oder unter Push-Bombing versehentlich bestätigen. Phishing-resistente Methoden wie FIDO2/Passkeys, Windows Hello for Business oder zertifikatsbasierte Anmeldung binden den Login kryptografisch an die echte Domain. Eine nachgebaute Login-Seite hat damit nichts in der Hand, das sie weiterspielen könnte.
Brauche ich für Passkeys und FIDO2 eine bestimmte Microsoft-365-Lizenz?
Die Methode selbst — Passkeys und FIDO2-Sicherheitsschlüssel in Entra ID zulassen — ist auch ohne Zusatzlizenz verfügbar. Um sie tenantweit per Conditional Access mit einer Authentifizierungsstärke zu erzwingen, brauchst Du Entra ID P1, das in Microsoft 365 Business Premium und in E3/E5 enthalten ist. Ohne P1 kannst Du die Methoden anbieten, aber nicht verbindlich durchsetzen.
Was passiert, wenn ein Mitarbeiter seinen Passkey oder Sicherheitsschlüssel verliert?
Den Wiederherstellungsweg planst Du vor dem Rollout, nicht danach. Registriere pro Person mindestens zwei Methoden — etwa einen Plattform-Passkey auf dem Smartphone plus einen Hardware-Schlüssel — und definiere einen Helpdesk-verifizierten Prozess zur Neuregistrierung. In Entra ID stellst Du dafür einen Temporary Access Pass aus: ein zeitlich begrenzter Code, mit dem sich ein neuer Passkey einrichten lässt, ohne auf eine phishbare Methode zurückzufallen.
Kann ich phishing-resistente MFA erst nur für Admins erzwingen und den Rest später migrieren?
Ja — und genau diese Reihenfolge ist empfehlenswert. Setze eine Conditional-Access-Richtlinie mit Authentifizierungsstärke zuerst auf die administrativen Rollen (höchstes Risiko, kleinste Gruppe), prüfe Deine Break-Glass-Konten und weite den Geltungsbereich dann Gruppe für Gruppe aus. Das ist der Migrationsfahrplan, den dieser Artikel weiter oben beschreibt.
Bereit, Deine MFA wirklich phishing-resistent zu machen?
Ich bin Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting. In meinen Projekten sehe ich immer wieder dasselbe Muster: MFA ist aktiv, aber die Methoden sind umgehbar — und niemand hat es geprüft, weil im Portal ja ein grüner Haken steht.
Genau hier setzt unser Microsoft 365 Hardening Check an: Wir prüfen Deinen Tenant gezielt auf den MFA-Reifegrad, decken umgehbare Methoden und ungeschützte Admin-Konten auf und zeigen Dir konkret, wo Du nachschärfen musst. Kein Folienvortrag, sondern eine fundierte Analyse Deiner echten Konfiguration.
In einem persönlichen Workshop gehen wir Deinen Tenant gemeinsam durch — Authentifizierungsmethoden, Conditional Access, Break-Glass und der Rollout-Plan für Deine Organisation. Hands-on an Deinem System, nicht an Folien. Wenn Du tiefer in die Materie einsteigen willst, hol Dir vorab unser Entra-ID-eBook mit den wichtigsten Identitäts-Härtungsmaßnahmen. Melde Dich bei mir — und wir machen aus „MFA ist an" ein „MFA hält".
