MFA im Unternehmen einführen: Was Microsoft erzwingt und NIS2 verlangt

Die Multi-Faktor-Authentifizierung verlangt neben dem Passwort einen zweiten, unabhängigen Nachweis. Für Microsoft-365- und Azure-Administratoren ist sie keine Option mehr: Microsoft erzwingt sie seit Oktober 2024 stufenweise, die letzten Aufschubfenster liefen am 30. September 2025 und am 1. Juli 2026 aus. In Deutschland verlangt zusätzlich § 30 BSIG MFA von betroffenen Unternehmen.

Stand am 6. September 2026: Die Schonfrist ist vorbei. Phase 1 der erzwungenen MFA läuft seit Oktober 2024 (Microsoft-365-Admin-Center seit Februar 2025), Phase 2 seit dem 1. Oktober 2025. Die Möglichkeit, den Start zu verschieben, endete für Phase 1 am 30. September 2025 und für Phase 2 am 1. Juli 2026. Danach bleibt laut Microsoft-Dokumentation nur noch ein Antrag beim Support auf eine befristete Aussetzung, gestellt von einem globalen Administrator. Ein Opt-out gibt es nicht, auch nicht für Testmandanten. Quelle: Microsoft Learn, Mandatory multifactor authentication (Dokumentenstand 3. April 2026, zuletzt aktualisiert am 6. Juli 2026; öffnet in einem neuen Tab).

1. Was Microsoft heute erzwingt

Microsoft rollt die Pflicht in zwei Phasen aus. Phase 1 betrifft die Oberflächen, an denen Menschen klicken: Azure-Portal, Microsoft Entra Admin Center, Microsoft Intune Admin Center und, seit Februar 2025, das Microsoft-365-Admin-Center. Dort ist der zweite Faktor bei jeder Anmeldung fällig, auch für reines Nachschauen.

Phase 2 betrifft die Werkzeuge, mit denen Administratoren automatisieren: Azure CLI, Azure PowerShell, die Azure Mobile App, Infrastructure-as-Code-Werkzeuge und die REST-Schnittstelle der Steuerungsebene. Hier gilt eine wichtige Einschränkung: Nur schreibende Vorgänge verlangen MFA. Wer ausschließlich liest, kommt vorerst weiter durch.

Die Abgrenzung läuft technisch über die Zieladresse. Alles, was an management.azure.com geht, fällt unter die Durchsetzung. Microsoft Graph gehört ausdrücklich nicht dazu. Das ist relevant, weil viele Skripte in Mittelstandsumgebungen genau dort arbeiten — an Postfächern, Gruppen und Lizenzen, nicht an Azure-Ressourcen.

Zwei Randbedingungen werden regelmäßig übersehen. Erstens erzwingt Microsoft die Pflicht nur in der öffentlichen Azure-Cloud — in den souveränen Clouds und in Azure for US Government gilt sie derzeit nicht. Zweitens hilft die Option „Angemeldet bleiben" nicht: Der zweite Faktor wird trotzdem verlangt. Auch Gastkonten aus anderen Mandanten sind erfasst; der MFA-Nachweis muss dann entweder im Heimatmandanten erbracht und übergeben werden oder im Ressourcenmandanten stattfinden.

2. Die Aufschubfristen sind abgelaufen

Microsoft hat Unternehmen mit komplexen Umgebungen zweimal Zeit gegeben. Beide Fenster sind zu. Wer sie genutzt hat und seither nichts geändert hat, arbeitet jetzt gegen eine Durchsetzung, die schlicht anläuft.

Ob die Durchsetzung in Ihrem Mandanten bereits begonnen hat, sehen Sie an zwei Stellen im Azure-Portal: unter aka.ms/managemfaforazure für Phase 1 und unter aka.ms/postponePhase2MFA für Phase 2. Ein Banner zeigt jeweils an, ob der Mandant erfasst ist. Zusätzlich weisen die Anmeldeprotokolle in Entra ID aus, welche Anwendung die MFA-Anforderung ausgelöst hat.

Wer noch keine Conditional-Access-Lizenz hat, kann die Wirkung trotzdem vorher messen. Microsoft beschreibt dafür eine Richtlinie in Azure Policy, die sich zunächst im reinen Prüfmodus betreiben lässt: Sie meldet, welche Zugriffe künftig scheitern würden, ohne sie zu blockieren. Erst danach schaltet man auf Durchsetzung um. Das ist der ehrlichste Weg, eine gewachsene Automatisierung zu inventarisieren.

3. Was das für Skripte und Dienstkonten heißt

Der Punkt, an dem es in der Praxis knallt, ist nicht der Mensch am Portal. Es sind die Konten, hinter denen kein Mensch steht. In vielen gewachsenen Umgebungen läuft die nächtliche Auswertung, der Export in die Warenwirtschaft oder das Bereitstellungsskript unter einem normalen Benutzerkonto, dessen Kennwort in einer Konfigurationsdatei liegt.

Microsoft trennt hier klar: Workload Identities — also verwaltete Identitäten und Dienstprinzipale — sind von beiden Phasen nicht betroffen. Nutzerkonten, die als Dienstkonto verwendet werden, sind es sehr wohl. Sie müssen sich nach Beginn der Durchsetzung mit einem zweiten Faktor anmelden, was für einen unbeaufsichtigten Nachtlauf keine brauchbare Antwort ist. Die einzige tragfähige Lösung ist die Umstellung auf eine Workload Identity.

Damit hängt ein zweiter technischer Bruch zusammen. Der Anmeldefluss ROPC, bei dem eine Anwendung Benutzername und Kennwort direkt entgegennimmt und weiterreicht, ist mit MFA grundsätzlich unvereinbar. Anwendungen, die darauf setzen, laufen nach Aktivierung in Ausnahmen. Betroffen sind unter anderem die entsprechenden Aufrufe in den Microsoft-Authentifizierungsbibliotheken und die Anmeldung über die Umgebungsvariablen für Benutzername und Kennwort in den Azure-Identity-Bibliotheken.

Und drittens die Clientversionen: Microsoft nennt Azure CLI 2.76 und Azure PowerShell 14.3 als Mindeststand für ein sauberes Zusammenspiel. Ältere Versionen zeigen statt einer Aufforderung zum zweiten Faktor nur eine Fehlermeldung. Wenn Sie diesen Beitrag mit einer Aufgabe verlassen, dann mit dieser: Prüfen Sie zuerst, welche Konten in Ihrer Automatisierung Nutzerkonten sind. Die Liste ist meist länger als erwartet und lässt sich über die Anmeldeprotokolle sauber erheben.

Wie diese Konten in eine geordnete Anwendungslandschaft passen, haben wir im Beitrag zu Microsoft 365 im Unternehmen einführen beschrieben; die Frage, welches System welche Daten überhaupt ziehen darf, gehört in die Architektur und nicht in ein Skript.

4. Drei Kategorien, zwei Sicherheitsklassen

Das BSI beschreibt drei Kategorien von Faktoren: Wissen wie Passwort oder PIN, Besitz wie Chipkarte oder Token, und Biometrie wie der Fingerabdruck. Entscheidend ist, dass die verwendeten Faktoren aus verschiedenen Kategorien stammen. Zwei Passwörter hintereinander sind keine Zwei-Faktor-Anmeldung.

Für die Auswahl im Unternehmen reicht diese Einteilung aber nicht. Die praktisch wichtigere Grenze verläuft zwischen Verfahren, die sich abphishen lassen, und solchen, bei denen das nicht funktioniert. NIST definiert Phishing-Resistenz in der Ausgabe SP 800-63B-4 vom Juli 2025 als Eigenschaft des Protokolls, die nicht von der Wachsamkeit der anmeldenden Person abhängt. Anerkannt sind zwei Wege dorthin: die Bindung an den Kommunikationskanal und die Bindung an den Namen des Dienstes. WebAuthn, die Grundlage von FIDO2 und damit von Passkeys, geht den zweiten Weg; Chipkarten mit client-authentifiziertem TLS gehen den ersten.

Microsoft zieht dieselbe Linie und benennt für Entra ID sechs phishing-resistente Verfahren: Windows Hello for Business, Platform Credential für macOS, synchronisierte Passkeys, FIDO2-Sicherheitsschlüssel, Passkeys in Microsoft Authenticator und die zertifikatsbasierte Authentifizierung. Zu SMS, E-Mail-Codes und Authenticator-Apps schreibt die Dokumentation dagegen ausdrücklich, dass sie für Phishing aus der Ferne anfällig bleiben. Welche Passkey-Variante zu welcher Nutzergruppe passt und wie die Wiederherstellung organisiert wird, haben wir im Beitrag zu Passkeys im Unternehmen ausführlich beschrieben — hier bleibt es bei der Einordnung als oberste Stufe.

Ein Wort zu den Prozentzahlen, die in diesem Zusammenhang durch das Netz laufen. In Herstellerdokumenten, in Blogbeiträgen und inzwischen auch in KI-Antworten auf die Suchanfrage steht, MFA blockiere nahezu alle Angriffe auf Konten — jeweils untermauert mit einem sehr hohen Prozentwert. Wir geben diese Werte nicht wieder. Weder ist die Grundgesamtheit offengelegt noch die Methodik, und sie stammen vom Hersteller des jeweiligen Produkts. Belegbar ist die Rangfolge der Verfahren — und die reicht für jede Entscheidung, die Sie treffen müssen.

5. Notfallkonten: die Falle im Rollout

Fast jede saubere Microsoft-Umgebung hat zwei Notfallkonten, oft Break-Glass-Konten genannt: hoch privilegiert, keiner Person zugeordnet, für den Fall gedacht, dass sich alle regulären Administratoren aussperren. Genau bei diesen Konten kursiert ein gefährlicher Irrtum.

Notfallkonten sind von Microsofts erzwungener MFA nicht ausgenommen. Die Dokumentation nennt sie wörtlich als erfasst, gemeinsam mit Administratorkonten und allen sonstigen Ausnahmen, die im Mandanten gesetzt sein mögen. Ausgenommen werden sie nur von eigenen Conditional-Access-Richtlinien, und zwar aus einem anderen Grund: damit eine sperrende Regel nicht ausgerechnet im Notfall greift. Wer beides verwechselt und sein Notfallkonto ohne zweiten Faktor stehen lässt, hat kein Notfallkonto mehr, sondern ein Konto, das im Ernstfall an der Anmeldung scheitert.

Microsofts Antwort darauf ist eindeutig: Diese Konten bekommen einen Passkey nach FIDO2 oder ein Zertifikat. Beides erfüllt die MFA-Anforderung, ohne dass ein Telefon im Spiel ist. Die weiteren Vorgaben aus der Microsoft-Checkliste lauten:

• Mindestens zwei Konten für Redundanz, ausschließlich in der Cloud und auf der Domäne onmicrosoft.com, ohne Abhängigkeit von einem föderierten Identitätsanbieter.
• Andere Methoden als bei den regulären Administratorkonten — damit ein Problem mit einem Verfahren nicht beide Wege gleichzeitig schließt.
• Zugangsdaten und Geräte laufen nicht ab und fallen nicht in automatische Aufräumroutinen.
• In der Rollenverwaltung wird die Rolle als dauerhaft aktiv zugewiesen, nicht als aktivierbar.
• Getrennte, feuerfeste Aufbewahrung an verschiedenen Orten, zugänglich nur für einen benannten Personenkreis.
• Alle Anmeldungen und Protokolleinträge werden überwacht, mit Alarm bei jeder Nutzung.
• Funktionstest mindestens alle 90 Tage, einschließlich Prüfung, wer aktuell zugriffsberechtigt ist.

Der 90-Tage-Test ist der Punkt, an dem die meisten Organisationen abbrechen. Er kostet eine halbe Stunde im Quartal und ist der einzige Beweis dafür, dass der Notausgang noch existiert. Setzen Sie ihn als wiederkehrenden Termin an, nicht als Vorsatz.

6. Ausnahmen, die keine mehr sind

In jedem MFA-Projekt kommt die Liste der Sonderfälle. Früher ließ sich vieles davon mit einem App-Passwort oder einer Ausnahme im Postfach lösen. Diese Wege sind zugegangen — teils vor Jahren, teils gerade jetzt. Die folgende Tabelle sortiert die Fälle, die uns in Projekten am häufigsten begegnen.

Die Zeile zu SMTP AUTH verdient eine Einordnung, weil sie sich zuletzt bewegt hat. Die Basisauthentifizierung ist in Exchange Online für ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Autodiscover und die klassischen Outlook-Clients abgeschaltet und lässt sich nach Microsofts eigener Aussage weder von Kunden noch vom Support wieder einschalten. Übrig geblieben ist der Versandweg SMTP AUTH. Für ihn hat das Exchange-Team im Januar 2026 einen neuen Zeitplan veröffentlicht: bis Dezember 2026 unverändert, Ende Dezember 2026 standardmäßig deaktiviert in bestehenden Mandanten mit weiterhin möglicher Aktivierung durch Administratoren, für neue Mandanten danach gar nicht mehr verfügbar. Das endgültige Abschaltdatum will Microsoft in der zweiten Jahreshälfte 2027 nennen. Ein konkretes Enddatum gibt es also noch nicht — und wir erfinden hier keines.

Praktisch heißt das: Jedes Multifunktionsgerät, jede Kassensoftware und jede Eigenentwicklung, die Benachrichtigungen über ein Postfach verschickt, gehört jetzt auf eine Liste. Wer viele solcher Geräte betreibt, fährt in aller Regel besser mit einem internen Mailrelay, das genau einmal sauber gegen Exchange Online authentifiziert, statt mit zwanzig Geräten, die es einzeln versuchen. Warum saubere Absenderkonfiguration darüber hinaus zählt, steht im Beitrag zu DMARC, SPF und DKIM.

Ein letzter Punkt, der leicht untergeht: Seit dem 30. September 2025 lassen sich Anmeldemethoden nicht mehr über die alte MFA- und Kennwortrücksetzungs-Richtlinie verwalten. Wer noch dort konfiguriert, findet seine Einstellungen in der Richtlinie für Authentifizierungsmethoden wieder und sollte die Migration abschließen, bevor er den Rollout startet.

7. Der Rollout in sieben Schritten

Die Reihenfolge entscheidet darüber, ob am Stichtag der Betrieb weiterläuft. Wir arbeiten in Projekten mit dieser Abfolge:

1. Notfallkonten zuerst. Zwei reine Cloud-Konten anlegen oder prüfen, mit Passkey oder Zertifikat ausstatten, Zugangsdaten getrennt hinterlegen, Funktionstest dokumentieren. Alles Weitere hängt davon ab, dass dieser Ausgang funktioniert.
2. Bestand erheben. Über die Anmeldeprotokolle in Entra ID auswerten, welche Konten sich an den betroffenen Anwendungen anmelden, welche davon Menschen sind und welche Automatisierung. Parallel alle Geräte und Anwendungen erfassen, die per Kennwort Mails versenden oder abrufen.
3. Dienstkonten umstellen. Nutzerkonten in der Automatisierung auf verwaltete Identitäten oder Dienstprinzipale migrieren. Dieser Schritt dauert am längsten und lässt sich am wenigsten beschleunigen, weil dabei Skripte angefasst werden.
4. Methoden festlegen. Entscheiden, welche Verfahren erlaubt sind, und die Entscheidung begründen. Für Administratoren empfehlen wir phishing-resistente Verfahren, für die Breite mindestens Push mit Nummernabgleich statt SMS.
5. Pilotgruppe fahren. Zwanzig bis dreißig Personen aus verschiedenen Abteilungen, ausdrücklich mit Außendienst und Produktion, nicht nur mit der IT. Zwei Wochen laufen lassen, Rückmeldungen einsammeln, Anleitung nachschärfen.
6. Stufenweise ausrollen. Nach Abteilungen, nicht nach Alphabet, und nie am Freitagnachmittag. Zwischen den Stufen mindestens eine Arbeitswoche Abstand, damit der Support Luft behält.
7. Nachfassen und dokumentieren. Nicht registrierte Konten aktiv ansprechen, alte Protokolle abschalten, den Stand schriftlich festhalten. Der letzte Punkt ist keine Bürokratie: § 30 Abs. 1 BSIG verlangt für betroffene Unternehmen ausdrücklich die Dokumentation der Maßnahmen.

Wenn Sie ohnehin an der Anmeldung arbeiten, lohnt der Blick auf die Nachbarthemen. Ein zentraler Anmeldedienst reduziert die Zahl der Stellen, an denen ein zweiter Faktor überhaupt abgefragt werden muss; welche Standards dabei ins Spiel kommen und warum ein solcher Dienst ohne MFA das Risiko sogar vergrößert, steht im Beitrag zu Single Sign-On im Mittelstand. Und ob ein Gerät überhaupt in einem vertretbaren Zustand ist, beantwortet die Geräteverwaltung — dazu haben wir Microsoft Intune im Mittelstand beschrieben.

8. Was Sie den Beschäftigten vorher sagen

Technisch ist ein MFA-Rollout überschaubar. Was Projekte kippen lässt, ist die Kommunikation. Menschen, die am Montagmorgen unangekündigt einen neuen Bildschirm sehen, rufen im Support an — alle gleichzeitig. Vier Etappen reichen aus:

1. Vier Wochen vorher Ankündigung mit Datum, Grund und Bild des Anmeldebildschirms. Nennen Sie den zuständigen Kontakt namentlich und sagen Sie, wie lange die Einrichtung dauert.
2. Eine Woche vorher Erinnerung mit Link zur Selbstregistrierung. Bieten Sie eine offene Sprechstunde an, damit niemand am Stichtag zum ersten Mal auf den Bildschirm schaut.
3. Am Stichtag Erhöhte Erreichbarkeit im Support, ein Ersatzverfahren für vergessene Telefone und eine kurze Notiz im Intranet. Rechnen Sie mit Rückfragen aus dem Außendienst.
4. Zwei Wochen danach Auswertung der Anmeldeprotokolle: Wer hat sich noch nicht registriert, welche Methode dominiert, welche Konten hängen an alten Protokollen.

Zwei Formulierungen haben sich bewährt. Erstens: Nennen Sie den Grund konkret. „Weil Microsoft es verlangt und weil es im Gesetz steht" ist ehrlicher und wirksamer als ein allgemeiner Appell an Sicherheitsbewusstsein. Zweitens: Sagen Sie vorher, was passiert, wenn das Telefon fehlt. Das BSI empfiehlt ausdrücklich, mehrere zweite Faktoren zu hinterlegen. Wer bei der Registrierung gleich zwei Wege einrichtet, spart sich später die Hälfte aller Supportfälle.

Rechnen Sie mit einer Gruppe, die kein Diensttelefon hat und das private nicht nutzen möchte. Das ist ein legitimer Standpunkt und hat eine technische Antwort: ein kleiner Hardware-Sicherheitsschlüssel am Schlüsselbund. Er kostet einmalig, funktioniert ohne Netz und gehört zu den phishing-resistenten Verfahren. Klären Sie diese Frage vor dem Rollout und nicht am Stichtag.

Beim Austritt kehrt sich die Registrierung um. Hardware-Schlüssel gehören zurück und auf die Rückgabeliste. Geteilte Zugänge, etwa ein Marktplatz- oder Bankkonto, brauchen einen Blick auf ihren zweiten Faktor: Hängt er am Telefon der ausscheidenden Person, stellen Sie ihn vor dem letzten Arbeitstag auf ein Firmengerät um und ändern das Passwort. Welche Schritte noch in diesen Tag gehören, zeigt unsere Offboarding-Checkliste mit Rollen und Fristen.

9. NIS2 und BSIG: MFA steht im Gesetz

Für einen Teil der Unternehmen ist MFA seit dem 6. Dezember 2025 nicht mehr Empfehlung, sondern Pflicht. An diesem Tag ist das neue BSI-Gesetz in Kraft getreten, mit dem Deutschland die NIS-2-Richtlinie umgesetzt hat. Die Richtlinie selbst nennt in Artikel 21 Absatz 2 Buchstabe j die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung" als Risikomanagementmaßnahme; das deutsche Gesetz übernimmt diesen Wortlaut in § 30 Absatz 2 Nummer 10 BSIG.

Drei Konsequenzen ergeben sich daraus für betroffene Unternehmen. Erstens verlangt § 30 Absatz 1 Satz 3 ausdrücklich, dass die Einhaltung dokumentiert wird — ein aktivierter Schalter reicht als Nachweis nicht. Zweitens nimmt § 38 BSIG die Geschäftsleitung in die Pflicht: Sie muss die Maßnahmen umsetzen und ihre Umsetzung überwachen, haftet bei schuldhafter Verletzung nach den Regeln des jeweiligen Gesellschaftsrechts und muss regelmäßig an Schulungen teilnehmen. Drittens gibt es eine Registrierungspflicht beim Bundesamt, und zwar nach § 33 Absatz 1 spätestens drei Monate nach Eintritt der Betroffenheit; Änderungen sind binnen zwei Wochen nachzureichen. Ein festes Kalenderdatum steht dort nicht — wer eines liest, liest eine Sekundärquelle.

Betroffen ist längst nicht jeder Betrieb. § 28 BSIG knüpft an zwei Bedingungen gleichzeitig an: Das Unternehmen muss einer der in den Anlagen 1 und 2 aufgeführten Einrichtungsarten zuzuordnen sein und die Größenschwellen erreichen. Als wichtige Einrichtung gilt, wer mindestens 50 Beschäftigte hat oder Jahresumsatz und Jahresbilanzsumme von jeweils über 10 Millionen Euro aufweist; als besonders wichtige Einrichtung ab 250 Beschäftigten oder über 50 Millionen Euro Umsatz und über 43 Millionen Euro Bilanzsumme. Ein Onlinehändler mit 60 Beschäftigten fällt also nicht automatisch darunter — die Zuordnung zur Einrichtungsart entscheidet mit.

Was NIS2 darüber hinaus an Zugriffskontrolle verlangt, geht über den zweiten Faktor hinaus und ist ein eigenes Thema; wir haben es im Beitrag zu Single Sign-On im Mittelstand behandelt. Hier bleibt es bei der einen Zeile, die wörtlich von MFA spricht.

Und für alle, die nicht unter das Gesetz fallen: Der Grund für MFA ändert sich dadurch nicht. Zugangsdaten aus fremden Datenlecks werden automatisiert gegen Anmeldemasken durchprobiert — wie dieser Angriff im Onlinehandel aussieht, haben wir am Beispiel von Card Testing und Credential Stuffing beschrieben. Ein zweiter Faktor macht ein geleaktes Passwort für sich genommen wertlos.

10. Security Defaults oder Conditional Access

Conditional Access ist zugleich der zentrale technische Baustein des Zero-Trust-Modells: Es ist genau die Stelle, an der Identität, Gerätezustand und Kontext zu einer Zugriffsentscheidung zusammenlaufen. Was daraus als Architektur folgt und welche Pakete die nötige Lizenz bereits enthalten, ordnet der Beitrag zu Zero Trust und SASE ein.

Microsoft bietet zwei Wege, MFA im eigenen Mandanten durchzusetzen. Die Security Defaults sind ein Schalter: an oder aus. Ist er an, müssen sich alle Nutzer für MFA registrieren, sechzehn Administratorrollen leisten den zweiten Faktor bei jeder Anmeldung, Legacy-Authentifizierung wird blockiert und der Device-Code-Flow ebenfalls. Seit dem 1. Juli 2026 blockieren die Security Defaults den Device-Code-Flow zusätzlich in allen neu angelegten Mandanten.

Für kleine Umgebungen ohne Sonderfälle sind die Security Defaults eine vernünftige Grundlage. Ihre Grenze ist genau ihre Stärke: Sie lassen sich nicht anpassen. Es gibt keine Ausnahme für ein Kassensystem, keine Sonderregel für den Standort und keine Möglichkeit, für Administratoren strengere Verfahren zu verlangen als für die Breite. Wer das braucht, kommt an Conditional Access nicht vorbei — und dafür an mindestens Microsoft Entra ID P1.

Die gute Nachricht für den Mittelstand: Diese Lizenzstufe ist laut Microsoft in Microsoft 365 Business Premium, Microsoft 365 E3 und EMS E3 bereits enthalten. Viele Unternehmen haben also längst, was sie brauchen, und wissen es nicht. Prüfen Sie das, bevor Sie über eine Zusatzlizenz nachdenken. Wie Conditional-Access-Richtlinien aufgebaut werden, welche Ausschlüsse sinnvoll sind und wie man sie testet, behandeln wir in einem eigenen Beitrag — dieser hier bleibt bei der Lizenzgrenze stehen.

11. Unsere Rolle in solchen Projekten

Damit hier keine falsche Erwartung entsteht: Wir sind keine Zertifizierungsstelle und keine Rechtsberatung. Ob Ihr Unternehmen unter das BSIG fällt, ist eine juristische Bewertung, die in die Rechtsabteilung oder zu einer Kanzlei gehört. Wir prüfen keine Einrichtungsarten und stellen keine Nachweise aus.

Was wir tun, liegt daneben und davor. Wir erheben, welche Konten sich in Ihrem Mandanten tatsächlich anmelden und welche davon Automatisierung sind — die Liste ist regelmäßig überraschend. Wir sortieren die Sonderfälle: Multifunktionsgeräte, Kassensysteme, Warenwirtschaft, Eigenentwicklungen mit fest hinterlegtem Kennwort. Und wir bauen den Rollout so, dass am Stichtag niemand vor verschlossener Tür steht, weil Notfallkonten, Pilotgruppe und Kommunikation vorher stehen.

Der technische Rahmen dafür entsteht in unserer Arbeit rund um Microsoft 365, Migration und Lizenzen; die Einordnung in eine größere Digitalisierungsplanung läuft über unsere Digitalisierungsberatung. Wo MFA in ein Gesamtbild aus Datensicherung, Endgeräten und Notfallplanung gehört, haben wir im Beitrag zur IT-Sicherheit im Mittelstand beschrieben. Wir arbeiten seit über 20 Jahren im E-Commerce und kennen den Zustand gewachsener Umgebungen — inklusive des Geräts im Lager, das seit 2014 unbemerkt Mails verschickt.

12. Fazit

MFA ist keine Zukunftsfrage mehr. Microsoft erzwingt sie für die eigenen Verwaltungswerkzeuge seit Oktober 2024 in zwei Phasen, beide Aufschubfenster sind geschlossen, ein Opt-out existiert nicht. Für Unternehmen im Anwendungsbereich des BSIG steht sie seit dem 6. Dezember 2025 zusätzlich im Gesetz — mit Dokumentationspflicht und einer Verantwortung, die bis in die Geschäftsleitung reicht.

Die drei Punkte, an denen Projekte tatsächlich hängen, sind nicht die Portale. Es sind erstens die Nutzerkonten in der Automatisierung, die auf Workload Identities umziehen müssen. Zweitens die Notfallkonten, die entgegen einem verbreiteten Irrtum nicht ausgenommen sind und deshalb einen Passkey oder ein Zertifikat brauchen. Und drittens die alten Versandwege über Basisauthentifizierung, deren letzter Rest bei SMTP AUTH Ende Dezember 2026 standardmäßig zugeht.

Wenn Sie nur eine Sache aus diesem Beitrag mitnehmen: Fangen Sie mit den Notfallkonten an und testen Sie sie. Alles andere lässt sich reparieren. Ein Mandant ohne funktionierenden Notausgang nicht.

Hinweis: Dieser Beitrag ist allgemeine Information und ersetzt keine Rechtsberatung. Ob Ihr Unternehmen als wichtige oder besonders wichtige Einrichtung unter das BSI-Gesetz fällt, ist eine Einzelfallbewertung; Yagemi nimmt sie nicht vor und stellt keine Nachweise aus. Alle Stichtage, Normen und Produktangaben entsprechen dem Stand vom 6. September 2026 und wurden an der Microsoft-Dokumentation, an NIST SP 800-63B-4, an der BSI-Seite zur Zwei-Faktor-Authentisierung, an der Richtlinie (EU) 2022/2555 und an den §§ 28, 30, 33 und 38 BSIG geprüft. Microsoft ändert Durchsetzungstermine kurzfristig; maßgeblich ist die jeweils aktuelle Fassung der verlinkten Quellen. Angaben ohne Gewähr.

13. Häufige Fragen zur Multi-Faktor-Authentifizierung

Sind MFA und 2FA das Gleiche?

Fast. Die Zwei-Faktor-Authentifizierung verlangt genau zwei Nachweise, die Multi-Faktor-Authentifizierung mindestens zwei. In der Praxis meinen beide Begriffe dasselbe Vorgehen: Passwort plus einen zweiten, unabhängigen Faktor. Wichtig ist nicht die Zahl, sondern dass die Faktoren aus verschiedenen Kategorien stammen. Das BSI nennt Wissen, Besitz und Biometrie.

Wann wird MFA verpflichtend?

Für Microsoft-Verwaltungswerkzeuge ist sie es bereits. Phase 1 läuft seit Oktober 2024 für die Portale, Phase 2 seit dem 1. Oktober 2025 für Azure CLI, Azure PowerShell und die Control-Plane-Schnittstelle. Die Aufschubfenster endeten am 30. September 2025 und am 1. Juli 2026. In Deutschland verlangt § 30 BSIG MFA seit dem 6. Dezember 2025.

Welche MFA-Methode ist die sicherste?

Phishing-resistente Verfahren: Passkeys nach FIDO2, Sicherheitsschlüssel, Windows Hello for Business und zertifikatsbasierte Anmeldung. NIST begründet das damit, dass der Nachweis kryptografisch an den echten Dienst gebunden ist und nicht von der Wachsamkeit der Person abhängt. Das BSI bevorzugt ebenfalls hardwaregestützte Verfahren.

Was ist der größte Nachteil der Zwei-Faktor-Authentifizierung?

Der Verlust des zweiten Faktors. Ist das Telefon weg oder der Schlüssel defekt, steht die Person vor verschlossener Tür und der Helpdesk vor einem Identitätsproblem. Das BSI empfiehlt deshalb, mehrere zweite Faktoren zu hinterlegen. Planen Sie den Wiederherstellungsweg, bevor Sie die Pflicht aktivieren.

Kann ich Notfallkonten von der MFA ausnehmen?

Von Microsofts erzwungener MFA nicht. Die Dokumentation nennt Break-Glass-Konten ausdrücklich als erfasst. Ausgenommen werden sie nur von eigenen Conditional-Access-Richtlinien, damit eine Sperrregel nicht genau im Notfall greift. Microsoft empfiehlt, diese Konten mit Passkey nach FIDO2 oder mit einem Zertifikat auszustatten.

Was passiert mit Skripten und Dienstkonten?

Workload Identities wie verwaltete Identitäten und Dienstprinzipale sind nicht betroffen. Nutzerkonten, die als Dienstkonto laufen, sehr wohl: Sie müssen sich nach Beginn der Durchsetzung mit MFA anmelden. Microsoft empfiehlt die Umstellung auf Workload Identities. Der ROPC-Anmeldefluss mit Benutzername und Kennwort ist mit MFA nicht vereinbar.

Brauchen Shared Mailboxes einen zweiten Faktor?

Nein, denn niemand sollte sich an ihnen anmelden. Microsoft schreibt, dass das zugehörige Benutzerkonto einer Shared Mailbox dauerhaft für die Anmeldung gesperrt bleiben soll. Der Zugriff läuft über Berechtigungen aus dem eigenen, lizenzierten Postfach. Ein gesperrtes Konto braucht keine Anmeldemethode.

Kostet MFA in Microsoft 365 extra?

Die Basisabsicherung nicht: Security Defaults sind ohne Zusatzlizenz in jedem Mandanten verfügbar. Wer feiner steuern will, braucht Conditional Access und dafür mindestens Microsoft Entra ID P1. Diese Stufe ist laut Microsoft in Microsoft 365 Business Premium, Microsoft 365 E3 und EMS E3 bereits enthalten.

Gilt die MFA-Pflicht auch für Testmandanten?

Ja. Microsoft beantwortet die Frage in der eigenen Dokumentation eindeutig: Jeder Azure-Mandant benötigt MFA, ohne Ausnahme für Testumgebungen. Ein Opt-out gibt es nicht. Auch Gastkonten aus anderen Mandanten sind erfasst, und die Option „Angemeldet bleiben" ändert an der Anforderung nichts.

14. Quellen & offizielle Informationen

Die Angaben in diesem Beitrag stützen sich auf die folgenden Quellen. Alle wurden am 6. September 2026 abgerufen und im Volltext gegengelesen — die Produktangaben in der englischsprachigen Originaldokumentation von Microsoft, die Normtexte in der amtlichen Fassung. Externe Quellen öffnen in einem neuen Tab.

• Microsoft Learn — Mandatory multifactor authentication for Azure and admin portals — Die maßgebliche Quelle dieses Beitrags. Trägt Phase 1 und Phase 2 mit Stichtagen und Anwendungs-IDs, die abgelaufenen Aufschubfenster, die Aussage zu Break-Glass-Konten, die Ausnahme für Workload Identities und das Synchronisierungskonto, die Unverträglichkeit des ROPC-Anmeldeflusses, die Mindestversionen für Azure CLI und Azure PowerShell sowie die Beschränkung auf die öffentliche Azure-Cloud. Dokumentenstand 3. April 2026, zuletzt aktualisiert am 6. Juli 2026.
• Microsoft Learn — Security defaults in Microsoft Entra ID — Was die Security Defaults erzwingen, welche sechzehn Administratorrollen bei jeder Anmeldung einen zweiten Faktor brauchen, die Blockade von Legacy-Authentifizierung und Device-Code-Flow und die Vergleichstabelle zur Lizenz: keine Lizenz gegen mindestens Microsoft Entra ID P1.
• Microsoft Learn — Manage emergency access accounts in Microsoft Entra ID — Die Checkliste für Notfallkonten: mindestens zwei Konten, ausschließlich in der Cloud, phishing-resistente Methoden, dauerhaft aktive Rollenzuweisung, getrennte und feuerfeste Aufbewahrung, Ausnahme von sperrenden Conditional-Access-Richtlinien, Überwachung und ein Funktionstest mindestens alle 90 Tage.
• Microsoft Learn — Features and licenses for Microsoft Entra multifactor authentication — Belegt wörtlich, dass Microsoft 365 Business Premium, Microsoft 365 E3 und EMS E3 Microsoft Entra ID P1 enthalten und Microsoft 365 E5 sowie EMS E5 die Stufe P2. Grundlage der Lizenzaussage in diesem Beitrag.
• Microsoft Learn — Microsoft Entra authentication overview — Die Übersicht aller Anmeldemethoden in Entra ID und die Liste der phishing-resistenten Verfahren: Windows Hello for Business, Platform Credential für macOS, synchronisierte Passkeys, FIDO2-Sicherheitsschlüssel, Passkeys in Microsoft Authenticator und die zertifikatsbasierte Authentifizierung.
• Microsoft Learn — Deprecation of Basic authentication in Exchange Online — Die Basisauthentifizierung ist in allen Mandanten abgeschaltet und weder durch Kunden noch durch den Microsoft-Support reaktivierbar. Betroffen sind unter anderem ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Autodiscover und die klassischen Outlook-Clients. Mit der Abschaltung entfallen auch App-Passwörter.
• Exchange Team Blog — Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline — Beitrag vom 27. Januar 2026, zuletzt aktualisiert am 29. Januar 2026. Nennt den aktuellen Zeitplan: bis Dezember 2026 unverändert, Ende Dezember 2026 standardmäßige Deaktivierung in bestehenden Mandanten mit weiterhin möglicher Aktivierung, neue Mandanten danach ohne Basisauthentifizierung, das endgültige Abschaltdatum wird in der zweiten Jahreshälfte 2027 angekündigt.
• Microsoft Learn — About shared mailboxes — Belegt die Vorgabe, dass die Anmeldung am Benutzerkonto einer Shared Mailbox dauerhaft gesperrt bleiben soll und der Zugriff über Berechtigungen aus dem eigenen, lizenzierten Postfach erfolgt.
• NIST Special Publication 800-63B-4 — Digital Identity Guidelines (Volltext) — Definiert Phishing-Resistenz als Eigenschaft des Protokolls, die nicht von der Wachsamkeit der anmeldenden Person abhängt, und erkennt zwei Wege an: Channel Binding und Verifier Name Binding. WebAuthn und damit FIDO2 stehen als Beispiel für den zweiten Weg. Das öffentliche Telefonnetz ist der einzige eingeschränkte Authentifikator der Empfehlung.
• NIST — SP 800-63B-4, Veröffentlichungsdaten (CSRC) — Belegt Veröffentlichung im Juli 2025 und dass die Ausgabe die frühere SP 800-63B ablöst. Wichtig, weil im Netz weiterhin die alte Fassung zitiert wird.
• BSI — Zwei-Faktor-Authentisierung — Deutschsprachige Behördenquelle für die drei Faktorkategorien Wissen, Besitz und Biometrie, für den Vorrang hardwaregestützter Verfahren, für die Warnung vor der mTAN auf demselben Gerät und für die Empfehlung, mehrere zweite Faktoren zu hinterlegen. Die Seite richtet sich an Verbraucher; Unternehmensempfehlungen leiten wir daraus nicht ab.
• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), konsolidierter Volltext auf EUR-Lex — Artikel 21 Absatz 2 Buchstabe j nennt die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung ausdrücklich als Risikomanagementmaßnahme. Artikel 41 Absatz 1 setzte den Mitgliedstaaten den 17. Oktober 2024 als Umsetzungsfrist.
• § 30 BSIG — Risikomanagementmaßnahmen (gesetze-im-internet.de) — Absatz 2 Nummer 10 übernimmt die MFA-Vorgabe wörtlich in deutsches Recht. Absatz 1 Satz 1 verlangt geeignete, verhältnismäßige und wirksame Maßnahmen, Satz 3 deren Dokumentation durch die Einrichtung.
• § 28 BSIG — Besonders wichtige und wichtige Einrichtungen — Die Schwellenwerte: besonders wichtige Einrichtungen ab 250 Beschäftigten oder mehr als 50 Millionen Euro Umsatz und mehr als 43 Millionen Euro Bilanzsumme, wichtige Einrichtungen ab 50 Beschäftigten oder jeweils mehr als 10 Millionen Euro — jeweils nur innerhalb der Einrichtungsarten der Anlagen 1 und 2.
• § 33 BSIG — Registrierungspflicht — Betroffene Einrichtungen melden sich spätestens drei Monate nach Eintritt der Betroffenheit beim Bundesamt; Änderungen sind unverzüglich, spätestens binnen zwei Wochen nachzureichen. Ein absolutes Stichtagsdatum enthält die Norm nicht.
• § 38 BSIG — Pflichten der Geschäftsleitungen — Geschäftsleitungen müssen die Maßnahmen nach § 30 umsetzen und ihre Umsetzung überwachen, haften bei schuldhafter Verletzung nach den Regeln des jeweiligen Gesellschaftsrechts und müssen regelmäßig an Schulungen teilnehmen.
• BSI-Gesetz 2025 — Rahmenangaben und Inkrafttreten — Das Gesetz wurde als Artikel 1 des Gesetzes vom 2. Dezember 2025 beschlossen, im Bundesgesetzblatt 2025 Teil I Nummer 301 verkündet und ist am 6. Dezember 2025 in Kraft getreten.

Drei Angaben fehlen in diesem Beitrag bewusst. Erstens jede Prozentzahl zur Wirksamkeit von MFA: Die kursierenden Werte stammen vom Hersteller und nennen keine Methodik. Zweitens ein Endtermin für die Basisauthentifizierung bei SMTP AUTH — Microsoft kündigt ihn erst in der zweiten Jahreshälfte 2027 an. Drittens Euro-Preise für Microsoft Entra ID P1 und P2: Die Preisseiten von Microsoft bauen ihre Tabellen erst im Browser auf, wir haben sie für diesen Beitrag nicht belegt und geben deshalb nur die Lizenzstufe an.