In vielen Tenants, die ich derzeit betreue, galt die Azure-MFA-Pflicht lange eher als Dauerwitz. Damit ist es vorbei. Seit dem 15. Oktober 2024 rollt Microsoft die erste Phase der verpflichtenden Multi-Faktor-Authentifizierung für Administratoranmeldungen in den Azure-Portalen aus. Wer sich am Azure-Portal, im Microsoft Entra Admin Center oder im Intune Admin Center anmeldet, kommt ohne MFA nicht mehr weit. Microsoft stellt schrittweise um, deshalb ist die Pflicht noch nicht in allen Tenants gleichzeitig aktiv. In mehreren Umgebungen sehe ich aber bereits die ersten erzwungenen MFA-Abfragen und abgelehnten Anmeldungen.

Die Pflicht greift vorerst nur bei interaktiven Anmeldungen von Benutzern

Die Azure-MFA-Pflicht betrifft derzeit nur interaktive Anmeldungen von Benutzerkonten an den genannten Admin-Portalen. Service Principals, Managed Identities und andere Workload-Identitäten bleiben in dieser Phase außen vor, an der Automatisierung ändert sich also nichts. Wer allerdings für automatisierte Deployments oder Skripte noch Benutzerkonten verwendet, sollte das dringend ändern. Wie der Wechsel sauber gelingt, beschreibe ich in meinem Beitrag Workload-Identitäten in Entra ID. Microsoft hat außerdem angekündigt, Anfang 2025 mit Phase 2 (CLI, PowerShell, IaC) nachzulegen. Hier wird sich also noch einiges bewegen.

Zum Start des Rollouts konnten globale Administratoren im Azure-Portal einen Aufschub der MFA-Pflicht für ihren Tenant beantragen. Die Option war nicht gerade prominent platziert, man fand sie eher im Infobereich. Ob man sie nutzt, sollte man sich ehrlich gesagt gut überlegen. In den meisten Tenants, die ich sehe, bringt ein weiterer Aufschub mehr Risiken als Vorteile. Die verbleibende Zeit reicht in der Regel, um die letzten Altlasten zu beseitigen.

Die Anmeldeprotokolle verraten, wer noch ohne MFA arbeitet

Besonders in größeren Umgebungen lohnt es sich jetzt, gezielt in die Anmeldeprotokolle zu schauen. Unter Microsoft Entra Admin Center → Überwachung → Anmeldungen lässt sich filtern, ob sich Benutzer ohne MFA am Azure-Portal oder im Entra Admin Center angemeldet haben. Am schnellsten kommt man mit einem eigenen Filter auf „Clientanwendung“ (z. B. „Browser“) und auf das Anmeldeergebnis ans Ziel. An der Spalte „Erforderliche MFA“ lässt sich eindeutig ablesen, ob MFA gefordert war und ob sie erfüllt wurde.

Mein Praxistipp: Setzt in den Anmeldeprotokollen die Filter „Clientanwendung: Browser“ und „Ressource: Azure Portal“. Damit findet ihr alle interaktiven Anmeldungen, die unter die neue MFA-Regel fallen. Fehlercodes wie „50076“ oder „50079“ deuten auf fehlende oder nicht erfüllte MFA hin.

Mit PowerShell ist der Überblick ebenfalls schnell gewonnen. Voraussetzung sind mindestens die Security-Administrator-Rolle und Zugriff auf das Entra Admin Center.

# PowerShell 7, Microsoft.Graph.SignIns Modul erforderlich
Connect-MgGraph -Scopes 'AuditLog.Read.All'
Get-MgAuditLogSignIn -Filter "ResourceDisplayName eq 'Azure Portal' and AuthenticationRequirement eq 'multiFactorAuthentication' and AuthenticationDetails/any(d:d/AuthenticationMethod eq null)" -Top 50

Der Befehl listet die letzten 50 Anmeldungen am Azure-Portal auf, bei denen MFA erforderlich war, aber kein Faktor erfüllt wurde. In der Praxis empfiehlt es sich, die Ergebnisse gezielt auf privilegierte Konten einzugrenzen.

Automatisierte Abläufe brauchen keine Benutzerkonten mehr

Ein Dauerbrenner bleibt die Automatisierung. Viele Teams arbeiten hier noch immer mit klassischen Benutzerkonten, häufig mit Service-Usern und statischen Passwörtern. Spätestens jetzt hat das ausgedient. Richtig ist der Umstieg auf Service Principals oder Managed Identities. Für Deployments, Skripte oder CI/CD gibt es heute keinen Grund mehr, interaktive Benutzerkonten einzusetzen, und mit der Azure-MFA-Pflicht drohen dadurch schnell Ausfälle in Pipelines. Wer noch Client-Secrets verwendet, sollte die Ablösung durch Workload-Identitäten in Angriff nehmen. Die modernen Alternativen sind sicherer, und MFA spielt bei ihnen keine Rolle.

Notfallkonten gehören mit FIDO2-Schlüsseln abgesichert

Break-Glass-Konten werden häufig unterschätzt. Wer sich auf ein Notfallkonto verlässt, das nur ein Passwort schützt, geht ein hohes Risiko ein – spätestens seit MFA erzwungen wird. Microsoft empfiehlt, mindestens zwei Notfallkonten mit FIDO2-Sicherheitsschlüsseln und ohne Conditional Access zu betreiben (Empfehlungen zum Notfallzugriff).

flowchart TD
    User["Admin-Benutzer"] --> Portal["Azure-Portal"]
    Portal --> MFA["MFA-Prüfung"]
    MFA -- "erfolgreich" --> Zugriff["Zugang gewährt"]
    MFA -- "nicht erfolgreich" --> Block["Anmeldung blockiert"]

Abbildung: MFA-Prüfung bei der Anmeldung im Azure-Portal

Das Diagramm zeigt vereinfacht, wie Azure jetzt bei jeder Anmeldung MFA prüft und den Zugriff verweigert, wenn die Prüfung scheitert. Solche abgelehnten Versuche tauchen inzwischen regelmäßig in den Protokollen auf. Höchste Zeit also, die letzten Ausnahmen aufzuspüren.

Für Ausreden gibt es jetzt keinen Platz mehr

Viele Organisationen haben MFA lange als „demnächst dringend“ behandelt. Mit der Azure-MFA-Pflicht in den Admin-Portalen gibt es kein Zurück mehr. Die meisten Umgebungen, die ich sehe, profitieren von der zentralen Durchsetzung, vor allem weil überfällige Altlasten und unsichere Automatisierungen endlich ans Licht kommen. Wer in den Admin-Portalen noch mit Benutzerkonten ohne MFA unterwegs ist, sollte spätestens heute handeln. Wer das Thema systematisch angehen möchte, dem empfehle ich außerdem meinen Beitrag zu Conditional Access in Entra ID.