Kein MFA aktiviert? Dann liegt der Haustürschlüssel unter dem Blumentopf

Es gibt wenige Sicherheitsmaßnahmen mit einem so klaren Kosten-Nutzen-Verhältnis wie die Multi-Faktor-Authentifizierung. Nach Daten von Microsoft Entra blockiert MFA mehr als 99,2 Prozent der Angriffe auf Konten (ältere Microsoft-Veröffentlichungen nennen 99,9 Prozent). Gestohlene und erratene Zugangsdaten gehören seit Jahren zu den häufigsten Einstiegspunkten überhaupt – der Verizon Data Breach Investigations Report bestätigt das Jahr für Jahr. Ein zweiter Faktor ist die wirksamste einzelne Maßnahme, um aus einem geklauten Passwort keinen Sicherheitsvorfall werden zu lassen.

Trotzdem ist MFA in vielen Microsoft-Tenants nicht flächendeckend aktiv. Und dort, wo sie aktiv ist, schützt sie 2026 nicht mehr automatisch gegen die Angriffe, die heute tatsächlich gefahren werden.

In diesem Beitrag ordnen wir beides ein: warum MFA nicht mehr verhandelbar ist – und warum die eigentliche Frage nicht lautet „MFA ja oder nein", sondern „welche MFA, und ist sie überall".

Warum MFA nicht mehr verhandelbar ist

Drei Entwicklungen haben MFA von der Empfehlung zur Pflicht gemacht:

• Die Regulierung. Das deutsche NIS-2-Umsetzungsgesetz verlangt in § 30 BSIG von wichtigen und besonders wichtigen Einrichtungen ausdrücklich „Lösungen zur Multi-Faktor-Authentisierung oder kontinuierlichen Authentisierung". MFA ist damit nicht länger Kür, sondern eine benannte Risikomanagement-Maßnahme. Das BSI nennt Passkeys als besonders sichere Variante, schreibt aber – wichtig zu wissen – keine bestimmte Methode und kein konkretes Vertrauensniveau vor. Die Technische Richtlinie BSI TR-03107 dient als Orientierung, nicht als Pflicht. Die Entscheidung über das „Wie" bleibt eine risikobasierte – und damit eine Führungsentscheidung.


• Die Versicherer. Cyber-Versicherungen setzen MFA – insbesondere für administrative Zugänge und Fernzugriffe – inzwischen regelmäßig voraus. Wer sie nicht nachweisen kann, riskiert schlechtere Konditionen oder im Schadensfall die Leistungskürzung.


• Der Hersteller selbst. Microsoft erzwingt MFA mittlerweile aktiv: Für die Admin-Portale – Azure-Portal, Microsoft Entra Admin Center und Intune – gilt die Pflicht seit Oktober 2024, für das Microsoft 365 Admin Center seit Februar 2025. Eine zweite Phase für die Azure-Ressourcenverwaltung (CLI, PowerShell, SDKs, REST-API, Infrastructure-as-Code) wird seit Oktober 2025 durchgesetzt; ein Aufschub war nur noch bis zum heutigen 1. Juli 2026 möglich. Die Richtung ist also mehr als eindeutig und dies aus gutem Grund.

Der blinde Fleck: MFA, die nur halb da ist

In der Praxis sehen wir bei Tenant-Analysen immer wieder dasselbe Muster. MFA ist vorhanden – aber lückenhaft. Vier Schwachstellen tauchen besonders häufig auf:

• Privilegierte Konten sind ausgenommen. MFA gilt für die breite Belegschaft, aber ausgerechnet Administrator- und Dienstkonten – die lohnendsten Ziele – laufen „aus Bequemlichkeit" ohne. Das kehrt die Schutzlogik um.


• Legacy-Protokolle umgehen MFA vollständig. Ältere Anmeldeverfahren über POP3, IMAP oder SMTP AUTH kennen keinen zweiten Faktor. Solange sie aktiv sind, gibt es einen Seiteneingang, der die Haustür irrelevant macht. Microsoft hat die Basic Authentication in Exchange Online schrittweise abgeschaltet; für SMTP AUTH kann sie in bestehenden Tenants aber noch bis Ende 2026 aktiv sein. Verlassen sollte man sich auf nichts, ohne es im eigenen Tenant zu prüfen.


• Conditional Access fehlt oder ist zu schwach. Ohne saubere Richtlinien in Entra ID lässt sich weder steuern, wer wann MFA braucht, noch Legacy-Authentifizierung gezielt blockieren.


• Break-Glass-Konten sind ungeschützt. Notfallzugänge sind nötig – aber wenn sie schwach abgesichert sind, werden sie vom Sicherheitsnetz zum Generalschlüssel.

Jede dieser Lücken hebelt den 99-Prozent-Schutz lokal wieder aus. MFA wirkt nur dort, wo sie tatsächlich greift.

Nicht jede MFA ist gleich – und 2026 ist genau das der wichtige Punkt

Hier beginnt der Teil, der in vielen Diskussionen noch fehlt. Die Annahme „Wir haben MFA, also sind wir geschützt" stimmt nicht mehr uneingeschränkt. Denn Angreifer versuchen längst nicht mehr, MFA zu „brechen". Sie umgehen sie.

Die dominierende Phishing-Technik gegen Microsoft 365 ist 2025 und 2026 der Adversary-in-the-Middle-Angriff (AiTM). Das Prinzip: Der Angreifer schaltet eine Proxy-Seite zwischen den Nutzer und die echte Anmeldemaske. Die Anmeldung läuft völlig normal ab – inklusive Passwort und MFA-Bestätigung. Im Moment des Erfolgs greift der Angreifer aber das ausgestellte Session-Token ab, also den Berechtigungsnachweis, den der Identitätsdienst nach erfolgreicher Anmeldung vergibt. Mit diesem Token ist er angemeldet – ohne je einen zweiten Faktor selbst beantworten zu müssen. Fertige Werkzeuge wie Evilginx haben diese Methode zur Massenware gemacht.

Gegen AiTM hilft klassische MFA per Push-Benachrichtigung oder Einmalcode nicht. Sie wird ja korrekt durchlaufen. Ähnliches gilt für MFA-Fatigue: Hier wird der Nutzer so lange mit Push-Anfragen bombardiert, bis er entnervt bestätigt – die Methode hinter dem bekannten Uber-Vorfall 2022. Das Number-Matching im Microsoft Authenticator entschärft diesen Trick, gegen den Token-Diebstahl per AiTM hilft es nicht.

Was hilft, ist phishing-resistente MFA. FIDO2-Sicherheitsschlüssel, Passkeys, zertifikatsbasierte Authentifizierung und Windows Hello for Business binden den Anmeldevorgang kryptografisch an die echte Domain. Eine gefälschte Proxy-Seite bekommt schlicht keine gültige Signatur – der Angriff läuft ins Leere. Die US-Sicherheitsbehörde CISA bezeichnet phishing-resistente MFA deshalb als „Gold Standard".

Die Konsequenz ist nicht „MFA war umsonst". Sie lautet: MFA ist die Grundlinie, phishing-resistente MFA ist das Ziel – und für privilegierte Konten ist sie keine Option mehr, sondern der Maßstab.

Welche Methode für wen

Daraus folgt kein Entweder-oder, sondern ein abgestufter Mix. Drei Methoden decken die meisten Mittelstandsumgebungen ab:

• Microsoft Authenticator ist die einfachste Lösung für den breiten Rollout: App aufs Smartphone, Bestätigung per Number-Matching, keine zusätzliche Hardware, keine Lizenzkosten. Sie hebt das Sicherheitsniveau gegenüber „nur Passwort" massiv – ist aber, ehrlich gesagt, gegen AiTM nicht resistent. Für die breite Belegschaft ist sie vertretbar, sollte aber durch Conditional Access flankiert werden.


• FIDO2-Sicherheitsschlüssel (etwa YubiKey) bieten das höchste Schutzniveau. Ein physischer Schlüssel per USB oder NFC, phishing-resistent by design. Für Administratoren und privilegierte Konten ist das die richtige Wahl – genau dort, wo ein kompromittierter Zugang am meisten anrichtet.


• Windows Hello for Business liefert die nahtloseste Erfahrung: Anmeldung per PIN, Fingerabdruck oder Gesichtserkennung direkt am Gerät, ebenfalls phishing-resistent, ohne zusätzliche App oder Token – dort, wo die Hardware es zulässt.

Der pragmatische Standard für die meisten Unternehmen: Authenticator für die Fläche, FIDO2 für Admins und privilegierte Nutzer:innen, Windows Hello for Business überall dort, wo die Geräte es hergeben. Dieser Mix bringt hohe Anwenderakzeptanz – weil jede Gruppe die für sie passende Methode bekommt – bei gleichzeitig hoher Schutzwirkung an den kritischen Stellen.

Vom Wissen zum Rollout

Die häufigste Frage, die wir von IT-Verantwortlichen hören, ist nicht „ob", sondern: „Wie führen wir das ein, ohne den Betrieb zu stören?" Ein strukturierter Rollout ist beherrschbar, wenn er in dieser Reihenfolge läuft:

1. Bestandsaufnahme. Welche Konten existieren, welche haben bereits MFA, welche Legacy-Protokolle sind noch aktiv? Ein klares Bild des Ist-Zustands ist die Voraussetzung für alles Weitere.


2. Methoden je Nutzergruppe festlegen. Welche Methode für welche Gruppe – auf Basis von Infrastruktur, Schutzbedarf und Nutzerverhalten.


3. Pilotgruppe. Erst mit einer kleinen, IT-affinen Gruppe testen. So werden Hürden sichtbar, bevor sie zum Flächenproblem werden.


4. Conditional Access konfigurieren. Regeln in Entra ID definieren: Wer braucht wann MFA, welche Ausnahmen gelten, wie wird Legacy-Authentifizierung blockiert.


5. Nutzer:innen mitnehmen. Ein technisch perfekter Rollout scheitert an unvorbereiteten Anwender:innen. Kommunikation, FAQ und kurze Anleitungen gehören zum Projekt, nicht ans Ende.


6. In Wellen ausrollen. Mit unkritischen Abteilungen beginnen, mit hoch privilegierten Konten abschließen. So bleibt Zeit, auf Feedback zu reagieren.


7. Monitoring und Auswertung. Nach dem Rollout die Abdeckung überwachen, verbleibende Lücken schließen, den Sicherheitsstatus dokumentieren – auch als Nachweis für Regulatorik und Versicherer.

Die Einordnung

MFA ist die wirksamste einzelne Maßnahme gegen die häufigste Angriffsart – und sie ist regulatorisch wie versicherungstechnisch nicht mehr verhandelbar. Aber sie ist eine Grundlinie, keine Ziellinie. Wer 2026 ernsthaft über Identitätssicherheit spricht, spricht über zwei Dinge: über lückenlose Abdeckung – kein Admin-Konto, kein Legacy-Protokoll außen vor – und über phishing-resistente Verfahren dort, wo es zählt.

Die ehrliche Frage an den eigenen Tenant ist deshalb nicht „Haben wir MFA?". Sie lautet: Haben wir sie überall – und ist sie stark genug für die Angriffe, die heute tatsächlich laufen?

Wer darauf keine belastbare Antwort hat, hat seinen blinden Fleck noch vor sich.

Wie MFA-ready ist Ihr Tenant? enthus prüft im Rahmen eines MFA-Readiness-Checks, wo in Ihrem Microsoft-Tenant Lücken bestehen – ungeschützte Konten, aktive Legacy-Protokolle, schwache oder fehlende Conditional-Access-Richtlinien – und wie sich diese schließen lassen. Das Ergebnis: ein klares Bild des Ist-Zustands und ein konkreter Fahrplan.

Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.