Seit dem 9. Februar 2026 erzwingt Microsoft MFA für alle Anmeldungen am Microsoft 365 Admin Center. Für Azure-Portal, Entra Admin Center und Intune Admin Center gilt die Pflicht seit 2024/2025, für Azure CLI, Azure PowerShell, IaC-Tools und die REST-API seit Phase 2 ab Oktober 2025. Ein Opt-out gibt es nicht. Ohne funktionierendes MFA für Global Administratoren oder mit falsch konfigurierten Break-Glass-Notfallkonten droht der vollständige Verlust des Tenant-Zugriffs. Hier richten Sie zwei Notfallkonten mit FIDO2 ein und stellen Automatisierung auf Workload Identities um.

Voraussetzungen

Microsoft 365 / Azure Tenant mit aktivem Global Administrator-Konto
Entra ID P1-Lizenz für Conditional Access (enthalten in M365 Business Premium, E3, E5), alternativ Security Defaults ohne CA
Entra ID P2 / M365 E5 für Privileged Identity Management (PIM); empfohlen, aber nicht zwingend
Mindestens zwei FIDO2-Sicherheitsschlüssel, idealerweise von zwei Herstellern, damit ein Firmware- oder Modellfehler nicht beide Notfallkonten trifft
Zwei physisch getrennte, gesicherte Aufbewahrungsorte für die Schlüssel (z. B. Tresor im Büro und zweiter Standort)
Ein Log Analytics Workspace in Azure Monitor für das Break-Glass-Alerting; die Weiterleitung der Anmeldeprotokolle setzt Entra ID P1 voraus
Azure CLI ab 2.76 und/oder Az PowerShell-Modul ab 14.3 auf allen Admin-Arbeitsplätzen, dazu das Modul Microsoft.Graph für die PowerShell-Beispiele
Dokumentierte Notfallprozesse; alle Personen mit Break-Glass-Zugriff sind eingewiesen

Hardware für diese Anleitung

Enthält Werbelinks

FIDO2-Sicherheitsschlüssel	Phishing-sicherer als Codes aus einer App. Immer zwei kaufen: einen für den Alltag, einen als Reserve an einem sicheren Ort.	Sicherheitsschlüssel bei Amazon (Werbelink)

Die Anleitung funktioniert mit jedem FIDO2-Schlüssel. * Werbelink

Schritt 1: Enforcement-Zeitplan und Scope verstehen

Microsoft hat die Pflicht-MFA in zwei Phasen ausgerollt:

Phase	Betroffene Dienste / App-IDs	Enforcement	Verschiebbar bis
Phase 1	Azure-Portal, Entra Admin Center, Intune Admin Center (`c44b4083-…`), M365 Admin Center (`admin.microsoft.com`, `admin.cloud.microsoft`, `portal.office.com/adminportal`)	Azure/Entra/Intune seit 2. Halbjahr 2024; M365 Admin Center seit 09.02.2026	Nicht mehr verschiebbar (Frist 30.09.2025 abgelaufen)
Phase 2	Azure CLI (`04b07795-…`), Azure PowerShell (`1950a258-…`), Azure Mobile App, IaC-Tools, Azure SDK, REST Control Plane (`management.azure.com`), nur Create/Update/Delete, keine Leseoperationen	schrittweise ab 01.10.2025	Höchstens 01.07.2026 (Frist abgelaufen)

Nicht betroffen: Workload Identities (Managed Identities, Service Principals), Entra Connect / Cloud Sync Dienstkonten, Microsoft Graph APIs, REST-Leseoperationen.

Betroffen, auch wenn selten angemeldet: alle Benutzerkonten mit Zugriff auf diese Apps, auch als Dienstkonto genutzte, und Test-Tenants.

Verifizieren: Im Azure-Portal zeigen die Seiten aka.ms/managemfaforazure (Phase 1) und aka.ms/postponePhase2MFA (Phase 2) jeweils ein Banner, dass die Durchsetzung für Ihren Tenant begonnen hat.

Schritt 2: Wenn Benutzer bereits ausgesperrt sind

Die Verschiebungsfristen beider Phasen sind abgelaufen. Bei akuten Problemen kann ein Global Administrator für Phase 2 über den Microsoft-Support eine vorübergehende Aufhebung beantragen; dauerhaft helfen nur Workload Identities (Schritt 7) und MFA-fähige Konten.

Prüfen Sie, welche Konten betroffen sind: Entra Admin Center → Anmeldeprotokolle, Filter auf Fehlercode 50076 bzw. auf die App-IDs aus der Tabelle.
Für Änderungen auf den Azure-Seiten zur MFA-Durchsetzung braucht der Global Administrator erhöhten Zugriff (Entra ID → Eigenschaften → Zugriffsverwaltung für Azure-Ressourcen). Deaktivieren Sie ihn danach wieder.

Verifizieren: In den Anmeldeprotokollen der letzten sieben Tage tauchen für Admin-Konten keine Fehler 50076 mehr auf, und alle Global Administrators haben unter Benutzer → Authentifizierungsmethoden mindestens eine starke Methode registriert.

Schritt 3: Break-Glass-Konten anlegen

Zwei Break-Glass-Global-Admins sichern den Tenant-Zugriff, wenn alle regulären Anmeldewege ausfallen (Geräteausfall, IdP-Ausfall, versehentlich sperrende CA-Richtlinien). Legen Sie reine Cloud-Konten in der *.onmicrosoft.com-Domäne an, ohne Verbund und Synchronisation, mit dauerhaft aktiver Global-Admin-Rolle (nicht „berechtigt“/Eligible in PIM). Ersetzen Sie contoso durch Ihren Tenant-Namen.

# Break-Glass-Konto anlegen (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes 'User.ReadWrite.All', 'RoleManagement.ReadWrite.Directory'

$PasswordProfile = @{
  Password = 'SEHR-LANGES-ZUFALLSPASSWORT-128-ZEICHEN'
  ForceChangePasswordNextSignIn = $false
}

New-MgUser -DisplayName 'Break Glass 01' `
  -UserPrincipalName 'breakglass01@contoso.onmicrosoft.com' `
  -AccountEnabled `
  -PasswordProfile $PasswordProfile `
  -MailNickname 'breakglass01'

# Global Administrator Rolle permanent (Active, nicht Eligible) zuweisen
$UserId = (Get-MgUser -UserId 'breakglass01@contoso.onmicrosoft.com').Id
$RoleId = (Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq 'Global Administrator' }).Id

New-MgDirectoryRoleMember -DirectoryRoleId $RoleId `
  -OdataId "https://graph.microsoft.com/v1.0/users/$UserId"

Denselben Ablauf für breakglass02@contoso.onmicrosoft.com wiederholen. Keine Lizenzen und keine Postfächer zuweisen. Das Kennwort getrennt vom FIDO2-Schlüssel aufbewahren.

Verifizieren: Get-MgDirectoryRoleMember -DirectoryRoleId $RoleId | ForEach-Object { $_.AdditionalProperties.userPrincipalName } listet beide Break-Glass-Konten, und im Entra Admin Center steht bei der Rolle Global Administrator für beide die Zuweisung „Aktiv“ ohne Enddatum.

Schritt 4: FIDO2-Passkeys für Break-Glass einrichten

Break-Glass-Konten müssen die Pflicht-MFA ohne Abhängigkeit von Smartphones oder Mobilfunknetz erfüllen. Microsoft empfiehlt Passkeys (FIDO2) oder zertifikatbasierte Authentifizierung. Verwenden Sie für BG01 und BG02 Schlüssel unterschiedlicher Hersteller.

FIDO2-Richtlinie im Entra Admin Center aktivieren:

Entra Admin Center → Entra ID (je nach Portalstand Schutz) → Authentifizierungsmethoden → Passkey (FIDO2)
Aktivieren: Ja
Ziel: ausgewählte Gruppe → EmergencyAccess (wird in Schritt 5 erstellt) bzw. zusätzlich Ihre Admin-Gruppen
Self-Service-Einrichtung zulassen: Ja
Nachweis (Attestation) erzwingen: Ja, optional mit Beschränkung auf die AAGUIDs der zugelassenen Schlüsselmodelle

Danach melden sich die autorisierten Personen mit dem Break-Glass-Konto unter https://mysignins.microsoft.com/security-info an und registrieren den Schlüssel über Anmeldemethode hinzufügen → Passkey.

Verifizieren: Im Entra Admin Center zeigt Benutzer → breakglass01 → Authentifizierungsmethoden einen registrierten Passkey (FIDO2), und eine Testanmeldung in einem privaten Browserfenster am M365 Admin Center gelingt ausschließlich mit dem Schlüssel.

Schritt 5: Security-Gruppe und CA-Ausnahmen einrichten

CA-Ausnahmen schützen Break-Glass-Konten vor blockierenden Richtlinien (Gerätekonformität, Standortsperren, Risiko-Richtlinien), heben die systemseitige Pflicht-MFA aber nicht auf; deshalb ist FIDO2 aus Schritt 4 unverzichtbar.

# Security-Gruppe für CA-Ausnahme erstellen
New-MgGroup -DisplayName 'EmergencyAccess' `
  -MailEnabled:$false `
  -SecurityEnabled `
  -MailNickname 'EmergencyAccess' `
  -IsAssignableToRole:$true

# Beide Break-Glass-Konten zur Gruppe hinzufügen
Add-MgGroupMember -GroupId '<GroupObjectId>' -DirectoryObjectId '<BG01-ObjectId>'
Add-MgGroupMember -GroupId '<GroupObjectId>' -DirectoryObjectId '<BG02-ObjectId>'

Tragen Sie dann in jeder CA-Richtlinie, die Anmeldungen blockieren oder einschränken kann, die Gruppe EmergencyAccess unter excludeGroups ein. Beispiel-JSON-Ausschnitt:

{
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["<ObjectId-der-EmergencyAccess-Gruppe>"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Richtlinien im Nur-Bericht-Modus brauchen keine Ausnahme. Eine Richtlinie, die phishing-resistente MFA verlangt, dürfen Sie bewusst ohne Ausnahme anlegen, weil FIDO2 sie erfüllt. Break-Glass-Konten nutzen ohnehin kein Postfach und keine Legacy-Authentifizierung.

Verifizieren: Entra Admin Center → Bedingter Zugriff → What If. Benutzer: breakglass01@contoso.onmicrosoft.com, Ziel-App: Microsoft Azure Management bzw. Microsoft Admin Portals. Unter den angewendeten Richtlinien erscheint keine Richtlinie, die Gerätekonformität, Standort oder Blockierung erzwingt.

Schritt 6: Break-Glass-Anmeldungen überwachen (Critical Alert)

Jede Anmeldung eines Break-Glass-Kontos ist ein kritischer Vorfall, ob legitim oder nicht. Voraussetzung: Unter Entra Admin Center → Überwachung → Diagnoseeinstellungen gehen die SignInLogs an Ihren Log Analytics Workspace. Grundlage für eine Protokollsuche-Warnungsregel in Azure Monitor:

// KQL-Abfrage für Log Analytics Workspace
SigninLogs
| where UserId == "<ObjectId-BG01>" or UserId == "<ObjectId-BG02>"
| project TimeGenerated, UserPrincipalName, UserId, AppDisplayName,
          IPAddress, ResultType, ResultDescription

Einstellungen der Warnungsregel:

Schwellenwert: größer als 0
Auswertungshäufigkeit: 5 Minuten
Zeitraum: 5 Minuten
Schweregrad: 0 (Kritisch), mit Aktionsgruppe für E-Mail und SMS an mehrere Verantwortliche

Mit Microsoft Sentinel ist zusätzlich eine Analyseregel möglich. Testen Sie die Konten mindestens alle 90 Tage und nach Personalwechseln: Anmeldung mit dem Schlüssel, Protokollierung, Alert bestätigt.

Verifizieren: Nach einer Testanmeldung mit breakglass01 trifft innerhalb von etwa 10 bis 15 Minuten (Protokollverzögerung plus Auswertungsintervall) die Warnung bei allen Empfängern der Aktionsgruppe ein, und die Abfrage im Workspace zeigt die Anmeldung.

Schritt 7: Automatisierungsskripte auf Workload Identities migrieren

Skripte mit Benutzername und Kennwort (ROPC-Flow: AcquireTokenByUsernamePassword, UsernamePasswordCredential) scheitern seit Phase 2 bei Schreibzugriffen auf management.azure.com mit AADSTS50076: … you must use multi-factor authentication. Stellen Sie auf Service Principal oder Managed Identity um:

# ALT - bricht mit Phase 2 MFA (ROPC):
# Connect-AzAccount -Credential (Get-Credential)

# NEU - Service Principal mit Client Secret:
$AppId = '<AppId>'
$TenantId = '<TenantId>'
$Secret = ConvertTo-SecureString '<ClientSecret>' -AsPlainText -Force
$Credential = New-Object PSCredential($AppId, $Secret)
Connect-AzAccount -ServicePrincipal -Credential $Credential -Tenant $TenantId

# NEU - Managed Identity (bevorzugt, kein Secret nötig):
Connect-AzAccount -Identity

# Azure CLI - Login mit Service Principal (non-interactive)
az login --service-principal \
  --username <AppId> \
  --password <ClientSecret-or-CertPath> \
  --tenant <TenantId>

# Azure CLI - Login mit Managed Identity
az login --identity

# Azure CLI Version prüfen (ab 2.76)
az version

Azure SDK: UsernamePasswordCredential (auch über EnvironmentCredential mit AZURE_USERNAME/AZURE_PASSWORD) ist veraltet, u. a. ab Azure.Identity .NET 1.14.0-beta.2, @azure/identity 4.8.0, azure-identity Python 1.21.0 und azidentity Go 1.9.0. Stellen Sie auf AZURE_CLIENT_ID plus Zertifikat oder Secret (Service Principal) oder Managed Identity um. Client-Secrets gehören in einen Tresor wie Azure Key Vault, nicht in den Skripttext.

Verifizieren: Das umgestellte Skript läuft ohne Benutzerinteraktion durch, (Get-AzContext).Account.Type zeigt ServicePrincipal bzw. ManagedService, und in den Anmeldeprotokollen erscheinen die Anmeldungen unter Dienstprinzipal-Anmeldungen bzw. Anmeldungen verwalteter Identitäten.

Schritt 8: RMAU-Schutz für Break-Glass-Konten (empfohlen)

Eine Verwaltungseinheit mit eingeschränkter Verwaltung (Restricted Management Administrative Unit, RMAU) sorgt dafür, dass nur ausdrücklich berechtigte Admins die Break-Glass-Konten und die Gruppe EmergencyAccess ändern können (erfordert Entra ID P1).

Entra Admin Center → Rollen und Administratoren → Verwaltungseinheiten → Hinzufügen
Verwaltungseinheit mit eingeschränkter Verwaltung aktivieren
Beide Break-Glass-Benutzer und die Gruppe EmergencyAccess aufnehmen
Für die Einheit nur wenige, per PIM kontrollierte Administratoren berechtigen

Verifizieren: Ein Benutzeradministrator ohne Rolle in der Verwaltungseinheit erhält beim Versuch, das Kennwort von breakglass01 zurückzusetzen, eine Fehlermeldung wegen eingeschränkter Verwaltung.

Troubleshooting / Typische Fehler

AADSTS50076: … you must use multi-factor authentication: Das Skript verwendet noch ROPC. Umstellung auf Service Principal (Connect-AzAccount -ServicePrincipal) oder Managed Identity (Connect-AzAccount -Identity).
Unklare MFA-Fehler bei Azure CLI oder PowerShell: Werkzeugversion zu alt. Azure CLI ab 2.76 (az version), Az-Modul ab 14.3 (Get-Module Az -ListAvailable).
AADSTS50079 bzw. fehlender MFA-Claim bei Verbund: Der externe IdP (z. B. AD FS) sendet keinen multipleauthn-Claim. IdP anpassen oder Admin-Konten auf reine Cloud-Konten umstellen.
Break-Glass-Konto meldet sich trotz FIDO2-Schlüssel nicht an: Prüfen, ob EmergencyAccess Ziel der Passkey-Richtlinie ist, der Schlüssel registriert ist und keine AAGUID-Beschränkung das Modell ausschließt.
CA-Ausnahme gesetzt, MFA wird trotzdem verlangt: Gewollt (siehe Schritt 5); am Konto muss FIDO2 oder CBA registriert sein.
Break-Glass-Konto hat keine Admin-Rechte: Rolle „berechtigt“ statt „aktiv“ zugewiesen; die PIM-Aktivierung scheitert im Notfall. Auf dauerhaft aktiv ändern.
Alert auf Break-Glass-Anmeldung wird nicht ausgelöst: Prüfen, ob die SignInLogs an den richtigen Workspace gehen und die Object-IDs in der Abfrage stimmen.

Häufige Fragen

Kann ich die Pflicht-MFA komplett abschalten oder dauerhaft deaktivieren?

Nein. Die Verschiebungsmöglichkeiten für Phase 1 (bis 30.09.2025) und Phase 2 (bis 01.07.2026) sind abgelaufen. Für Phase 2 bleibt bei akuten Problemen nur eine vorübergehende Aufhebung über den Microsoft-Support.

Ich nutze Security Defaults statt Conditional Access, bin ich trotzdem betroffen?

Ja. Security Defaults erzwingen MFA für Admins; die systemseitige Pflicht-MFA gilt zusätzlich und unabhängig. Ohne Entra ID P1 nutzen Sie Security Defaults, Conditional Access erfordert mindestens P1.

Sind Managed Identities und Service Principals auch von der MFA-Pflicht betroffen?

Nein, Workload Identities sind ausgenommen. Betroffen sind nur Benutzerkonten, auch als Dienstkonto für Skripte genutzte.

Welche MFA-Methoden funktionieren für Break-Glass ohne Smartphone?

Passkey (FIDO2) auf Hardware-Schlüssel und zertifikatbasierte Authentifizierung (CBA): beide phishing-resistent, ohne Smartphone oder Mobilfunknetz. Microsoft Authenticator erfüllt die Pflicht ebenfalls, ist für Notfallkonten wegen Geräteverlust und Telefonabhängigkeit aber weniger geeignet.

Gilt die Pflicht-MFA auch für kleine Unternehmen ohne Entra ID P1?

Ja, jeder Azure- und M365-Tenant, unabhängig von Größe und Lizenz. Ohne P1 aktivieren Sie Security Defaults.

Müssen bestehende CA-Richtlinien mit Break-Glass-Ausnahmen angepasst werden?

Ja, sie schützen vor Gerätekonformitäts- und Standortrichtlinien. Die systemseitige Pflicht heben sie nicht auf; zusätzlich brauchen die Konten FIDO2 oder CBA.

Was ist mit Entra Connect / Cloud Sync Dienstkonten?

Laut Microsoft nicht, da sie sich nicht an den betroffenen Apps anmelden; keine Änderung nötig.

Fazit

CA-Ausnahmen allein sichern Break-Glass-Konten nicht ab. Die vier Säulen eines belastbaren Notfallzugangs: FIDO2-Schlüssel an zwei getrennten Orten, dauerhaft aktive Global-Admin-Rollen, regelmäßige Anmeldetests und ein kritischer Alert auf jede Anmeldung. Automatisierung gehört auf Managed Identities oder Service Principals. Siehe auch MFA und Conditional Access und Entra-ID-Benutzerverwaltung.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: Microsoft Learn: Plan for mandatory MFA (Entra ID) · Microsoft Learn: Emergency access admin accounts · Microsoft Tech Community: Mandatory MFA for M365 Admin Center · Microsoft Q&A: Mandatory MFA for break-glass vs. CA