Ab dem 9. Februar 2026 erzwingt Microsoft die Multi-Faktor-Authentifizierung für alle Anmeldungen am Microsoft 365 Admin Center, dem Entra Admin Center, dem Azure-Portal und dem Intune Admin Center – ohne Opt-out, ohne Ausnahme für bestimmte Konten. Wer als Global Administrator noch kein MFA eingerichtet hat oder falsch konfigurierte Break-Glass-Notfallkonten besitzt, riskiert den vollständigen Verlust des Tenant-Zugriffs. Diese Anleitung erklärt dir, was genau ab wann gilt, wie du zwei Notfallkonten (Break-Glass) mit phishing-resistenter FIDO2-Authentifizierung korrekt einrichtest, warum CA-Ausnahmen allein nicht mehr reichen und wie Automatisierungsskripte vor der Phase-2-Deadline migriert werden müssen.

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 (kostenlos, ohne CA)
Entra ID P2 / M365 E5 für Privileged Identity Management (PIM) und Restricted Management Administrative Units – empfohlen, aber nicht zwingend
Mindestens 2 FIDO2-Hardware-Security-Keys (z. B. YubiKey 5 NFC, empfohlen: zwei verschiedene Hersteller), ca. 50–80 EUR pro Stück
Zwei physisch getrennte, gesicherte Aufbewahrungsorte für die FIDO2-Keys (z. B. feuerfester Tresor im Büro + gesicherter Zweigstellenstandort)
Azure Monitor Log Analytics Workspace für Break-Glass-Alerting (Free Tier bis 5 GB/Monat)
Azure CLI >= 2.76 und/oder Az PowerShell-Modul >= 14.3 auf allen Admin-Workstations
PowerShell >= 7.4 als Laufzeitumgebung
Dokumentierte Notfallprozesse; alle Personen mit Break-Glass-Zugriff müssen geschult sein

Schritt 1: Enforcement-Zeitplan und Scope verstehen

Microsoft rollt die Pflicht-MFA in zwei Phasen aus. Die folgende Tabelle zeigt, was wann betroffen ist:

Phase	Betroffene Dienste / App-IDs	Enforcement	Verschiebbar bis
Phase 1	Azure-Portal (`c44b4083-…`), Entra Admin Center, Intune Admin Center, M365 Admin Center (`admin.microsoft.com`, `admin.cloud.microsoft`, `portal.office.com/adminportal`)	09.02.2026 (M365 AC); Azure/Entra/Intune bereits aktiv	Nicht mehr verschiebbar (Frist 30.09.2025 abgelaufen)
Phase 2	Azure CLI (`04b07795-…`), Azure PowerShell (`1950a258-…`), Azure Mobile App, IaC-Tools, REST Control Plane (`management.azure.com`) – nur Create/Update/Delete, keine Read-Operationen	01.10.2025	Max. 01.07.2026 per aka.ms/postponePhase2MFA

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

Betroffen – auch wenn selten angemeldet: alle User-Konten, B2B-Gäste (sofern kein Cross-Tenant-MFA-Claim), Test-Tenants.

Schritt 2: Phase-2-Verschiebung beantragen (falls nötig)

Falls Automatisierungsskripte noch nicht auf Workload Identities migriert sind, kannst du als Global Administrator den Phase-2-Start auf maximal 01.07.2026 verschieben:

Elevated Access im Azure-Portal aktivieren: PIM Elevated Access
Im Browser aufrufen: https://aka.ms/postponePhase2MFA
Neues Startdatum wählen (max. 01.07.2026), dann „Apply" klicken.

Wichtig: Die Verschiebung betrifft nur Phase 2 (CLI/PowerShell/IaC). Phase 1 (Admin-Portale) kann nicht mehr verschoben werden – der 09.02.2026 ist eine harte Deadline.

Schritt 3: Break-Glass-Konten anlegen

Zwei Break-Glass-Global-Admins sichern den Tenant-Zugriff für den Fall, dass alle regulären MFA-Methoden ausfallen (z. B. Geräteausfall, Identitätsprovider-Ausfall, versehentlich gesperrte CA-Richtlinien). Wichtig: Cloud-Only-Konten in der *.onmicrosoft.com-Domäne anlegen, kein Verbund, keine On-Premises-Synchronisation. Die Global-Admin-Rolle muss als Active Permanent (nicht „Eligible" in PIM) zugewiesen sein.

# 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 E-Mail-Postfächer für diese Konten aktivieren.

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

Break-Glass-Konten müssen die Pflicht-MFA erfüllen – und das ohne Abhängigkeit von Smartphones oder Mobilfunknetz. Die beste Methode ist ein FIDO2-Hardware-Security-Key (z. B. YubiKey 5 NFC). Für BG01 und BG02 unterschiedliche Hersteller wählen.

FIDO2-Policy im Entra Admin Center aktivieren:

Entra Admin Center → Protection → Authentication Methods → Passkeys (FIDO2)
Enable: Yes
Target: Specific Group → EmergencyAccess (wird in Schritt 5 erstellt)
Allow self-service setup: Yes
Enforce attestation: Yes (empfohlen, mit spezifischen AAGUIDs für zugelassene Key-Modelle)

Nach Aktivierung der Policy melden sich die autorisierten Personen mit dem jeweiligen Break-Glass-Konto am Entra-Portal an und registrieren den FIDO2-Key unter Mein Konto → Sicherheitsinformationen → Sicherheitsschlüssel hinzufügen.

Schritt 5: Security-Gruppe und CA-Ausnahmen einrichten

CA-Ausnahmen schützen Break-Glass-Konten vor blockierenden Richtlinien (Device-Compliance, Location-Blocks, Anmelderisiko-Policies). Sie heben die systemseitige Pflicht-MFA nicht auf – deshalb ist FIDO2 aus Schritt 4 unverzichtbar. Beide Maßnahmen müssen kombiniert werden.

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

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

Anschließend in jeder CA-Richtlinie, die Anmeldungen blockieren oder einschränken kann, die Gruppe EmergencyAccess als Ausnahme unter excludeGroups eintragen. Beispiel-JSON-Ausschnitt für eine bestehende Richtlinie:

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

Report-Only-Richtlinien benötigen keine Ausnahme. Legacy-Auth-Blockierungsrichtlinien dürfen Break-Glass-Konten nicht ausschließen – diese Konten sollten generell kein Exchange-Postfach und keine Legacy-Auth-Nutzung haben.

CA mit „What If" testen: Entra Admin Center → Protection → Conditional Access → What If. Benutzer: breakglass01@contoso.onmicrosoft.com, App: Microsoft Azure Management (c44b4083-3bb0-49c1-b47d-974e53cbdf3c). Erwartetes Ergebnis: Nur die zwei dedizierten BG-Richtlinien greifen, keine weitere Richtlinie erzwingt Device Compliance oder andere Blocker.

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

Jede Anmeldung eines Break-Glass-Kontos muss sofort als Critical-Incident behandelt werden – ob legitim oder nicht. Der folgende KQL-Alert in Azure Monitor / Log Analytics stellt sicher, dass du innerhalb von 5 Minuten benachrichtigt wirst:

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

Alert-Einstellungen:

Threshold: Greater than 0
Frequency: 5 Minuten
Period: 5 Minuten
Severity: 0 (Critical)

Wer Microsoft Sentinel einsetzt, kann zusätzlich eine Analytics Rule mit UEBA-Anreicherung erstellen. Quartalsweise Validierung (mindestens alle 90 Tage): vollständigen Anmeldetest mit dem jeweiligen FIDO2-Key durchführen, protokollieren und den Alert-Eingang bestätigen.

Schritt 7: Automatisierungsskripte auf Workload Identities migrieren

Skripte, die sich mit Benutzerkonten (ROPC-Flow: AcquireTokenByUsernamePassword, UsernamePasswordCredential) anmelden, funktionieren nach Phase-2-Enforcement nicht mehr. Fehlermeldung: AADSTS50076: … you must use multi-factor authentication. Die Migration auf Service Principal oder Managed Identity ist zwingend:

# 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 noetig):
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 pruefen (muss >= 2.76 sein)
az version

Azure SDK: DefaultAzureCredential und EnvironmentCredential mit AZURE_USERNAME / AZURE_PASSWORD sind in folgenden Versionen als deprecated markiert und werden nach Phase-2-Enforcement blockiert: Azure.Identity .NET ab v1.14.0-beta.2, @azure/identity Node.js ab v4.8.0, azure-identity Python ab v1.21.0, azidentity Go ab v1.9.0. Umstellung auf AZURE_CLIENT_ID + AZURE_CLIENT_SECRET (Service Principal) oder AZURE_CLIENT_ID allein (Managed Identity).

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

Eine Restricted Management Administrative Unit (RMAU) stellt sicher, dass nur hochprivilegierte Admins (mit PIM + phishing-resistenter MFA) die Break-Glass-Konten und die EmergencyAccess-Gruppe ändern können. Die Einrichtung erfordert Entra ID P2.

Entra Admin Center → Roles and admins → Admin units → Add
Typ: Restricted Management aktivieren
Beide Break-Glass-User-Objekte und die EmergencyAccess-Gruppe in die RMAU aufnehmen
Nur Admins mit PIM-aktivierter Privileged Role Administrator-Rolle können diese RMAU verwalten

Troubleshooting / Typische Fehler

AADSTS50076: … you must use multi-factor authentication: Das Skript verwendet noch ROPC. Migration auf Service Principal (Connect-AzAccount -ServicePrincipal) oder Managed Identity (Connect-AzAccount -Identity) ist erforderlich.
InteractionRequiredException oder MFA required bei Azure CLI/PowerShell: Werkzeugversion zu alt. Azure CLI muss >= 2.76 sein (az version), Az-Modul >= 14.3 (Get-Module Az -ListAvailable), PowerShell >= 7.4. Update erzwingen, dann erneut testen.
AADSTS50079 (MFA-Claim fehlt): Federated Identity Provider (AD FS oder externer IdP) sendet keinen multipleauthn-Claim. Der IdP muss konfiguriert werden, den korrekten MFA-Claim an Entra ID zu senden (Expected Inbound Assertions konfigurieren).
Break-Glass-Konto meldet sich nicht an trotz FIDO2-Key: FIDO2-Policy greift nur auf die korrekte Gruppe. Prüfen: Ist EmergencyAccess-Gruppe als Target der Passkey-Policy eingetragen? Ist der Key korrekt registriert und die Attestation-Konfiguration (AAGUID) korrekt?
CA-Ausnahme funktioniert, MFA wird trotzdem verlangt: Seit Phase-1-Enforcement erzwingt Microsoft MFA auf Applikationsebene unabhängig von CA. FIDO2 oder CBA muss am Konto registriert sein – CA-Ausnahme allein reicht nicht.
Break-Glass-Konto kann Global-Admin-Rolle nicht aktivieren (PIM): Die Rolle ist als „Eligible" statt „Active Permanent" konfiguriert. PIM-Aktivierung erfordert selbst MFA. Lösung: Rollenzuweisung auf „Active Permanent" ändern.
Alert auf Break-Glass-Anmeldung wird nicht ausgelöst: Prüfen ob der Log Analytics Workspace mit den Entra ID Diagnostic Settings (Sign-in logs) verbunden ist. Entra Admin Center → Monitoring → Diagnostic settings → Workspace auswählen.

Häufige Fragen

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

Nein. Microsoft hat bestätigt, dass es kein dauerhaftes Opt-out gibt. Die Maßnahme ist permanent. Lediglich für Phase 2 (Azure CLI/PowerShell/IaC) ist eine zeitliche Verschiebung auf maximal 01.07.2026 möglich, per aka.ms/postponePhase2MFA. Phase 1 (Admin-Portale inkl. M365 Admin Center) kann nicht mehr verschoben werden.

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

Ja. Security Defaults erzwingen bereits MFA für alle Admins. Die systemseitige MFA-Enforcement kommt zusätzlich und unabhängig von Security Defaults oder CA. Kunden ohne Entra ID P1-Lizenz können Security Defaults aktivieren; Conditional Access erfordert mindestens P1 (enthalten in M365 Business Premium, E3, E5).

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

Nein. Workload Identities (Managed Identities, Service Principals) sind explizit ausgenommen. Nur User-Konten, die sich interaktiv oder per ROPC anmelden, sind betroffen. Deshalb sollte Automation konsequent auf Workload Identities umgestellt werden – vor dem jeweiligen Enforcement-Datum.

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

FIDO2-Passkey (Hardware Security Key wie YubiKey 5 NFC) und Certificate-Based Authentication (CBA) erfüllen die Pflicht-MFA-Anforderung vollständig ohne Smartphone oder Mobilfunknetz. Beide Methoden sind phishing-resistent. Microsoft Authenticator gilt ebenfalls, ist aber bei MFA-Service-Ausfall oder Geräteverlust riskant – für Break-Glass daher nicht empfohlen.

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

Ja, jeder Azure- und M365-Tenant ist betroffen, unabhängig von Größe und Lizenz. Ohne P1/P2 lassen sich Security Defaults aktivieren oder Azure Policy zur MFA-Self-Enforcement einsetzen. Conditional Access erfordert mindestens Entra ID P1.

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

Die CA-Ausnahmen selbst bleiben wichtig und sollten beibehalten werden – sie schützen vor Device-Compliance- und Location-Richtlinien. Zusätzlich müssen Break-Glass-Konten nun aber auch MFA-fähig sein (FIDO2/CBA), da CA-Ausnahmen die systemseitige MFA-Erzwingung nicht aufheben. Beide Maßnahmen sind gleichzeitig notwendig.

Was ist mit Entra Connect / Cloud Sync Dienstkonten?

Microsoft Entra Connect und Cloud Sync Dienstkonten sind nicht betroffen, da sie sich nicht interaktiv in die betroffenen Apps anmelden. Sie benötigen keine Änderung.

Fazit

Die Pflicht-MFA für Microsoft-365-Admin-Portale ist keine optionale Härtungsmaßnahme mehr, sondern eine technische Erzwingung ohne Ausweg. Der wichtigste Erkenntnisgewinn aus dieser Anleitung: CA-Ausnahmen allein sichern Break-Glass-Konten nicht mehr ab. FIDO2-Hardware-Keys in zwei physisch getrennten Tresoren, permanent aktive Global-Admin-Rollen (nicht PIM-Eligible), quartalsweise Validierungstests und ein Critical-Alert auf jede Anmeldung sind die vier Säulen eines robusten Notfallzugangs. Parallel dazu muss die Migration von Automatisierungsskripten auf Managed Identities oder Service Principals vor dem eigenen Phase-2-Enforcement-Datum abgeschlossen sein. Wer beides rechtzeitig erledigt, ist auch nach dem 09.02.2026 handlungsfähig. Eine gute Ergänzung zu diesem Thema bieten die Anleitungen zu MFA und Conditional Access in Entra ID sowie zu Benutzern, Gruppen und Lizenzen in Entra ID verwalten.

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