Ausgesperrt aus dem eigenen Tenant: MFA-Lockouts Ihrer Global Admins vermeiden

Es ist eines der unangenehmsten Szenarien im Microsoft-365-Alltag: Der Global Administrator eines Tenants steht vor der Anmeldemaske, gibt sein Passwort ein – und scheitert am zweiten Faktor. Das Smartphone ist verloren, gestohlen oder wurde beim Gerätewechsel zurückgesetzt, ohne dass der Authenticator vorher migriert wurde. Der Zugang zum Tenant ist damit blockiert, und zwar nicht nur zu einem einzelnen Postfach, sondern zur gesamten Administration: Benutzerverwaltung, Lizenzen, Sicherheitsrichtlinien, Exchange – alles.

Alle zwei bis drei Wochen bittet uns ein Kunde genau deshalb um Hilfe. Dieser Artikel zeigt, wie Sie verhindern, dass Sie sich als Global Admin selbst aussperren.

Warum das Problem heute größer ist

Microsoft hat die MFA-Pflicht seit 2024 schrittweise verbindlich gemacht. In Phase 1 wurde MFA ab Oktober 2024 für die Administrationsoberflächen erzwungen: Azure-Portal, Microsoft Entra Admin Center und Intune Admin Center; für das Microsoft 365 Admin Center begann die Durchsetzung ab Februar 2025 und gilt seit dem 9. Februar 2026 verbindlich. Phase 2 weitet die Pflicht seit dem 1. Oktober 2025 auf die Azure-Resource-Manager-Ebene aus – also auf Azure CLI, Azure PowerShell, die Azure Mobile App, IaC-Werkzeuge und REST-APIs. Betroffen sind dort schreibende Operationen (Create, Update, Delete); reine Lesevorgänge lösen keine MFA-Anforderung aus. Exchange Online PowerShell und Microsoft Graph fallen nicht unter Phase 2 – ob dort MFA verlangt wird, entscheiden Ihre eigenen Conditional-Access-Richtlinien beziehungsweise die Security Defaults.

Wer mehr Zeit brauchte, konnte die Durchsetzung von Phase 2 für seinen Tenant aufschieben – längstens bis zum 1. Juli 2026. Dieses Fenster ist inzwischen geschlossen. Eine Möglichkeit, die MFA-Pflicht auszusetzen, gibt es damit nicht mehr.

Für die Praxis heißt das seit Juli 2026 endgültig: MFA ist keine Option mehr, die man im Notfall abschalten kann. Wer sich aussperrt und keinen alternativen Anmeldeweg vorbereitet hat, hat kein Sicherheitsnetz – außer einem Microsoft-Supportfall mit Identitätsnachweis, der Tage dauern kann und absolut keinen Spaß macht.

Die typischen Ursachen einer Aussperrung

Fast alle Lockouts, die uns begegnen, lassen sich auf eine überschaubare Zahl von Ursachen zurückführen:

Verlorenes oder defektes Smartphone. Das Gerät mit der Authenticator-App geht verloren oder gibt den Geist auf. Ist es die einzige registrierte MFA-Methode, ist der Zugang futsch.

Gerätewechsel ohne Migration. Ein neues Smartphone wird eingerichtet, das alte zurückgesetzt – und die Authenticator-Konten wurden vorher weder per Cloud-Backup gesichert noch über die Migrationsfunktion übertragen. Anders als bei WhatsApp oder Passwortmanagern reisen die Authenticator-Einträge nicht automatisch mit dem Google- oder Apple-Konto mit.

Nur eine einzige MFA-Methode. Viele Administratoren registrieren ausschließlich die Authenticator-App. Fällt diese eine Methode aus, gibt es keinen zweiten Weg.

Geänderte Telefonnummer. Wer auf SMS oder Anruf als zweiten Faktor setzt (ohnehin nicht mehr empfohlen), verliert bei einem Nummernwechsel den Zugang – und SMS ist zusätzlich anfällig für SIM-Swapping.

Fehlkonfigurierte Conditional-Access-Richtlinie. Eine zu scharf gesetzte Richtlinie – etwa eine Länder- oder Gerätecompliance-Anforderung – kann sämtliche Administratoren gleichzeitig aussperren. Das trifft dann nicht eine Person, sondern den ganzen Tenant.

Nur ein einziger Global Admin. Gibt es im Tenant nur ein Konto mit voller Berechtigung, ist dessen Ausfall gleichbedeutend mit dem Verlust jeder administrativen Handlungsfähigkeit.

Die Folgen

Ein Lockout fällt selten sofort auf – das Global-Admin-Konto wird im Tagesgeschäft kaum benutzt. Bemerkt wird er meist genau dann, wenn er am teuersten ist.

Am Montag fängt eine neue Kollegin an: kein Konto, kein Postfach, keine Lizenz. Ein Mitarbeiter hat sein Passwort vergessen, und niemand kann es zurücksetzen. Jemand verlässt das Unternehmen im Streit, und sein Zugang lässt sich nicht deaktivieren. Und im unangenehmsten Fall wird ein Konto kompromittiert: Es gibt niemanden, der es sperrt, die aktiven Sitzungen widerruft oder die Anmeldeprotokolle auswertet. Aus einem Verwaltungsproblem wird dann ein Sicherheitsvorfall, bei dem man zum Zuschauen verurteilt ist.

Die Wiederherstellung über den Microsoft-Support erfordert einen Identitätsnachweis und kostet Zeit und Nerven.

Vorbeugung: Best Practices

Ein Lockout ist mit überschaubarem Aufwand nahezu vollständig vermeidbar. Die folgenden Maßnahmen bauen aufeinander auf – die ersten beiden sind Pflicht.

1. Break-Glass-Konten (Notfallzugangskonten) einrichten

Das wichtigste Sicherheitsnetz. Ein Break-Glass-Konto ist ein hochprivilegiertes Konto, das ausschließlich für den Notfall existiert und nicht im Tagesgeschäft benutzt wird. Empfohlene Konfiguration:

• Mindestens zwei solcher Konten für Redundanz.

• Cloud-only auf der Standarddomäne `*.onmicrosoft.com`, ohne Abhängigkeit von föderierter Identität, On-Premises-Synchronisierung oder eigener Custom Domain.

• Phishing-resistente Authentifizierung über FIDO2-Hardwarekeys (z. B. YubiKey), und zwar eine andere Methode als bei den regulären Admin-Konten. Wenn der Alltag über die Authenticator-App läuft, sichert der Hardwarekey den Notfall unabhängig davon ab.

• Aus den blockierenden Conditional-Access-Richtlinien ausgenommen, damit genau die Richtlinie, die den Lockout verursacht, das Notfallkonto nicht ebenfalls aussperrt. Die phishing-resistente MFA bleibt dabei erhalten – ausgenommen wird von blockierenden Bedingungen, nicht von jeder Absicherung.

• Global-Administrator-Rolle permanent aktiv zugewiesen (nicht „eligible“ über PIM), damit das Konto auch dann funktioniert, wenn Aktivierungs-Workflows gerade nicht greifen.

• Zugangsdaten sicher und getrennt aufbewahren: langes, zufälliges Passwort und Hardwarekeys an physisch getrennten, gesicherten Orten (Tresor).

• Anmeldungen überwachen. Jede Anmeldung eines Break-Glass-Kontos ist ein Ereignis, das eine Warnung auslösen und einen bekannten Grund haben sollte.

2. Mehrere MFA-Methoden pro Administrator registrieren

Kein Admin-Konto sollte von einer einzigen Methode abhängen. Ideal ist die Kombination aus Authenticator-App und mindestens einem FIDO2-Hardwarekey. Fällt ein Faktor aus, bleibt der zweite. Diese eine Gewohnheit verhindert den mit Abstand häufigsten Lockout-Grund.

3. Auf phishing-resistente, passwortlose Verfahren setzen

FIDO2-Keys und Passkeys sind nicht nur sicherer als App-Push oder SMS, sie sind auch unabhängiger: Ein Hardwarekey verliert seine Gültigkeit nicht beim Handywechsel. Zertifikatsbasierte Authentifizierung ist eine weitere Option – sie erfüllt die MFA-Anforderung allerdings nur, wenn sie in der Authentifizierungsrichtlinie als Multifaktor-Verfahren konfiguriert ist.

4. Conditional Access vor der Aktivierung testen

Neue oder verschärfte Richtlinien gehören zuerst in den Report-only-Modus und anschließend durch das „What If“-Werkzeug. Prüfen Sie dabei ausdrücklich, ob die Break-Glass-Konten von der Richtlinie erfasst werden – und rollen Sie Richtlinien schrittweise über Gruppen aus statt tenantweit.

5. Den Wiederherstellungsweg kennen, bevor er gebraucht wird

Solange ein zweiter handlungsfähiger Administrator existiert, ist ein Lockout kein Supportfall: Ein Konto mit der Rolle „Privileged Authentication Administrator“ kann die registrierten MFA-Methoden des betroffenen Kontos löschen und einen Temporary Access Pass (TAP) ausstellen, mit dem sich der Kollege neu registriert. Voraussetzung ist, dass TAP in der Authentifizierungsmethoden-Richtlinie überhaupt aktiviert ist. Das gehört einmal geprüft – nicht am Tag des Vorfalls.

6. Authenticator-Cloud-Backup und Migration bewusst handhaben

Jeder Administrator sollte wissen, dass die Authenticator-App ihre Konten nicht automatisch auf ein neues Gerät überträgt. Vor jedem Gerätewechsel gehört das Cloud-Backup aktiviert bzw. die Migrationsfunktion genutzt – oder besser noch: Ein zweiter Faktor sorgt dafür, dass ein vergessenes Backup gar nicht erst zum Problem wird.

7. Mindestens zwei Global Admins vorhalten

Ein einzelner Global Admin ist ein Single Point of Failure. Zwei bis maximal vier Konten mit dieser Rolle (inklusive der Break-Glass-Konten) sind ein guter Kompromiss aus Redundanz und Angriffsfläche. Für das Tagesgeschäft ist Global Administrator ohnehin selten die richtige Rolle – weniger privilegierte Rollen genügen meist.

8. Dokumentieren und regelmäßig testen

Ein Notfallzugang, der im Ernstfall nicht funktioniert, ist wertlos. Die Break-Glass-Konten, ihre Aufbewahrungsorte und der Wiederherstellungsprozess gehören in den Notfallplan – und sollten in festen Abständen tatsächlich getestet werden. Dabei prüft man auch, ob die Konten versehentlich in eine neue Conditional-Access-Richtlinie geraten sind.

Fazit

Ein Lockout aus dem eigenen Tenant ist selten ein technisches Problem, sondern ein Vorbereitungsproblem. Wer zwei Break-Glass-Konten mit FIDO2-Keys einrichtet, jedem Admin mehrere Anmeldemethoden gibt und den Wiederherstellungsprozess einmal dokumentiert und testet, vermeidet die Aussperrung praktisch vollständig. Der Aufwand dafür liegt bei wenigen Stunden. Der Aufwand für die Wiederherstellung nach einem echten Lockout – im laufenden Betrieb, über den Support, mit Identitätsnachweis – liegt deutlich höher.