Microsoft 365

Break-Glass-Accounts in Microsoft 365 richtig absichern

Indeno GmbH

20 Juli 2026 — 9 Min. Lesezeit

Mit dem 9. Februar 2026 hat Microsoft die letzte große Lücke in seiner Mandatory-MFA-Enforcement geschlossen. Seit diesem Datum muss jeder Admin, der sich am Microsoft 365 Admin Center anmeldet, einen zweiten Faktor nachweisen. Für das Entra Admin Center, das Azure-Portal und das Intune Admin Center gilt das schon seit Anfang 2025. Damit ist der Kreis geschlossen: Wer heute noch mit Benutzername und Passwort an ein Admin-Portal kommt, hat entweder eine Ausnahme-Policy übersehen oder ein Audit-Risiko. [1][2]

Für Break-Glass-Accounts ist das mehr als ein Randthema. Microsoft stellt in der Dokumentation klar: Die MFA-Pflicht greift unabhängig von Rollenzuweisungen und unabhängig von Conditional-Access-Ausschlüssen. [2] Das klassische Notfallkonto (langes Passwort im Tresor, per Exclude-Gruppe an allen Policies vorbei) funktioniert so nicht mehr. Break-Glass-Accounts müssen heute ein phishing-resistentes MFA-Verfahren registriert haben, in der Regel Passkey (FIDO2) oder Certificate-Based Authentication (CBA). An dieser Stelle entscheidet sich, ob eine Organisation im Ernstfall in ihren Tenant zurückkommt oder ausgesperrt bleibt. [3]

Was ist ein Break-Glass-Account und wann braucht man ihn?

Ein Break-Glass-Account, in der Microsoft-Terminologie Emergency Access Account, ist ein Administrator-Konto mit permanenter Global-Administrator-Rolle, das ausschließlich für echte Ausnahmesituationen vorgesehen ist. Microsoft nennt in der Doku fünf typische Szenarien: [3]

Der Identity Provider (ADFS, ein externer IdP, eine föderierte Zone) ist nicht erreichbar, und reguläre Admins können sich nicht mehr anmelden.
Eine fehlerhaft ausgerollte Conditional-Access-Policy sperrt die Administrator-Rollen aus.
Der letzte Global Administrator hat das Unternehmen verlassen, und sein On-Prem-Konto wurde deaktiviert oder gelöscht, bevor der Cloud-Schatten bereinigt war.
Ein großflächiger MFA- oder Netzausfall verhindert die Nutzung registrierter zweiter Faktoren.
In Privileged Identity Management sind alle Rollen eligible konfiguriert, aber kein Approver mehr vorhanden.

In diesen Fällen ist der Break-Glass-Account der letzte Rettungsanker. Er muss von jeder externen Abhängigkeit unabhängig funktionieren. Deshalb gelten für seine Konfiguration strengere Regeln als für jedes andere Konto im Tenant.

Die 7-Punkte-Checkliste

Für den schnellen Selbstcheck die verdichtete Kurzform:

2 Cloud-only-Break-Glass-Accounts auf *.onmicrosoft.com, nicht synchronisiert, nicht föderiert.
Global Administrator permanent aktiv, nicht PIM-eligible.
Mindestens ein Account aus allen Conditional-Access-Policies ausgeschlossen, der zweite in gezielt ausgewählten Policies.
Passwort ≥ 32 Zeichen, zufällig generiert, ohne Ablaufdatum, physisch versiegelt an zwei Standorten hinterlegt.
Phishing-resistente MFA registriert, also FIDO2-Hardware-Token (z. B. Swissbit iShield Key 2, YubiKey 5 Serie) oder CBA mit PIV-Smartcard.
Sign-In-Monitoring und Alerting aktiv, Anmeldungen an den Break-Glass-Accounts triggern sofort eine Benachrichtigung an mehrere Administratoren.
Regelmäßiger Test- und Review-Zyklus, dokumentiert und mindestens alle 90 Tage durchlaufen.

1. Zwei Cloud-only-Accounts, nie nur einer

Microsoft empfiehlt ausdrücklich mindestens zwei Break-Glass-Accounts, und beide sollen cloud-only sein, also direkt in Entra ID angelegt, nicht aus einem On-Premises-Active-Directory synchronisiert und nicht föderiert. [3]

Warum zwei? Weil ein einzelner Notfallzugang an zu vielen Stellen verlorengehen kann: defekter Hardware-Token, versiegelter Umschlag im falschen Safe, versehentlich disabled, oder ein Fehler in genau der einen Policy, die den Account umgibt. In der Praxis hat sich bewährt, die beiden Accounts mit unterschiedlichen Token-Modellen oder Hardware-Herstellern auszustatten (z. B. einmal Swissbit iShield Key 2, einmal YubiKey 5), um eine gleichzeitige Kompromittierung durch ein Firmware-CVE auszuschließen. Microsoft selbst fordert in der Doku, dass die Auth-Methode der Emergency-Accounts sich von den regulären Admin-Accounts unterscheiden muss; getrennte Hersteller zwischen den beiden Break-Glass-Accounts ist eine darauf aufbauende, in der Community etablierte Empfehlung. [3][4]

Warum cloud-only? Jede Abhängigkeit von Synchronisation, Federation oder einem On-Premises-Directory ist im Notfallszenario ein Risiko. Fällt Entra Connect aus, bleibt ein synchronisierter Account möglicherweise im Drift oder lässt sich nicht mehr zurücksetzen. Ein cloud-only-Account mit *.onmicrosoft.com-UPN funktioniert auch dann, wenn die eigenen DNS-Einträge oder der Identity Provider weg sind. [3]

Naming-Konvention: Ein neutraler, anonymer Name ohne Personenbezug ([email protected], [email protected]). Kein Display-Name, der auf eine reale Person zeigt, und keine Rückfallmailadresse, die an einen persönlichen Zweitaccount hängt.

2. Global Administrator permanent aktiv, nicht PIM-eligible

In Privileged Identity Management lassen sich Rollen entweder eligible (auf Anforderung aktivierbar) oder permanent active zuweisen. Für reguläre Administratoren ist eligible die klar bessere Wahl, weil die privilegierte Sitzung zeitlich begrenzt ist und die Aktivierung ein zusätzliches Audit-Event erzeugt.

Für Break-Glass-Accounts ist permanent active die einzig richtige Option. [3]

Der Grund ist einfach: Wenn der Account zum Einsatz kommt, ist die Tenant-Umgebung bereits in einem gestörten Zustand. PIM selbst läuft zwar in der Regel weiter, aber jede zusätzliche Abhängigkeit (eine Approval-Kette, ein Self-Service-Activation-Workflow, das Ticket-System, das über PIM informiert werden soll) ist ein potenzieller Stolperstein. Der Account muss sich anmelden und handeln können, ohne dass vorher noch eine Aktivierungslogik durchlaufen wird.

Im PIM-Dashboard sollte die Rolle Global Administrator für beide Break-Glass-Accounts als Active · Permanent · Assigned directly erscheinen, nicht als Eligible und nicht über eine Gruppenmitgliedschaft vermittelt.

3. Conditional-Access-Ausschluss, aber gezielt

Die Empfehlung lautet: Mindestens einer der beiden Accounts muss aus allen Conditional-Access-Policies ausgeschlossen sein. Der zweite Account kann, und sollte, in ausgewählte Policies eingebunden sein, typischerweise in eine phishing-resistente MFA-Policy, damit im Alltagsfall zumindest ein harter Kryptografie-Faktor erzwungen wird. [4]

Der Ausschluss erfolgt nie direkt am Benutzer, sondern immer über eine dedizierte Entra-ID-Security-Group (z. B. sg-breakglass-exclude). Wer die Mitgliedschaft dieser Gruppe ändert, hat Zugriff auf den Tenant. Schreibrechte auf diese Gruppe gehören deshalb in das Protected-Actions-Szenario, nicht in die Standard-Role-Administration.

Konkret gegen die aktuelle Microsoft-Umsetzung abgeglichen:

Die Mandatory-MFA-Enforcement greift unabhängig von Conditional-Access-Ausschlüssen, sobald jemand eines der Verwaltungsportale aufruft. Ein bloßes "aus allen Policies ausschließen" reicht nicht. Der Account muss zwingend ein MFA-Verfahren registriert haben. [1][2]
Die empfohlene Kombination für den Alltag: Account 1 ist aus allen Policies ausgeschlossen, Account 2 unterliegt einer phishing-resistant MFA-Policy über Authentication Strengths. Die Policy erzwingt FIDO2 oder CBA und lehnt schwächere Verfahren ab. [5]
Sobald eine neue CA-Policy produktiv geht, sollte die Exclude-Group automatisch mitgeführt werden. Das lässt sich über eine dedizierte "Excluded Groups Policy Baseline" erreichen, die beide Break-Glass-Accounts und, wenn vorhanden, eine Service-Account-Gruppe gemeinsam verwaltet.

4. Passwort ≥ 32 Zeichen, kein Ablauf, physisch hinterlegt

Auch wenn FIDO2 das primäre Authentifizierungsverfahren ist, bleibt das Passwort der Fallback. Es muss so stark sein, dass es einem Brute-Force-Versuch und einem Leak aus einem kompromittierten System standhält:

Länge: Mindestens 32 Zeichen, besser 40+. Ein zufälliger Mix aus allen Zeichenklassen, generiert mit einem Passwortgenerator wie KeePassXC oder pwgen -s 40.
Kein Ablaufdatum: In Entra ID wird das über Update-MgUser -UserId <objectid> -PasswordPolicies "DisablePasswordExpiration" (Microsoft Graph PowerShell) bzw. direkt über das Attribut passwordPolicies gesetzt. Microsoft erwartet explizit, dass der Notfallzugang nicht durch eine automatische Policy ausläuft. [3]
Kein Passwort-Manager-Sync: Break-Glass-Credentials dürfen nicht in einem persönlichen Passwort-Manager liegen, nicht in 1Password, Bitwarden oder LastPass. Ein Team-Vault ist nur dann akzeptabel, wenn die Zugriffskontrolle darauf nicht selbst von Entra ID abhängt, was die wenigsten Team-Vaults erfüllen.
Physische Hinterlegung: Das Passwort kommt auf Papier in einen versiegelten Umschlag, und dieser in einen feuersicheren Safe. Microsoft verlangt ausdrücklich zwei räumlich getrennte Standorte für die Sicherungskopie ("fireproof safes that are in secure, separate locations"). [3]
Siegelbruch protokollieren: Jeder Zugriff auf den Umschlag wird dokumentiert, inklusive Datum, Uhrzeit, Grund und beteiligter Personen. Nach der Nutzung wird das Passwort rotiert und neu versiegelt.

5. Phishing-resistente MFA: FIDO2 oder CBA

Microsoft akzeptiert für Break-Glass-Accounts zwei phishing-resistente MFA-Verfahren: Passkey (FIDO2) über einen Hardware-Token und Certificate-Based Authentication (CBA), wenn die Organisation bereits eine PKI betreibt. [3][5]

Welches davon sinnvoller ist, hängt vom Umfeld ab:

FIDO2 / Passkey ist die schneller aufzusetzende, robustere Variante für die meisten Umgebungen. Der private Schlüssel verlässt das Hardware-Element nie, es gibt kein Zertifikats-Lifecycle-Problem, und die Registrierung läuft direkt über das Entra-Benutzerportal. Für Break-Glass ist die device-bound Variante Pflicht. Synced passkeys (iCloud Keychain, Google Password Manager) sind hier ausdrücklich ungeeignet, weil sie theoretisch klonbar sind und je nach Implementierung keine strikte Presence-Prüfung haben. [5]
CBA passt in Umgebungen, die ohnehin eine Enterprise-PKI betreiben und Smartcards oder PIV-Token bereits ausrollen. Der Vorteil: keine Abhängigkeit von einer externen FIDO-Server-Validierung. Der Nachteil: Das Lifecycle-Handling der Zertifikate muss sauber laufen, sonst läuft das Notfall-Zertifikat genau dann ab, wenn man es braucht.

Wahl des Hardware-Tokens

Für FIDO2-basierte Break-Glass-Accounts empfehlen wir ein dediziertes Paar Hardware-Token pro Account: einen primären und einen Backup-Token, beide identisch konfiguriert und physisch getrennt gelagert. Die beiden Break-Glass-Accounts sollten unterschiedliche Token-Modelle oder Hersteller verwenden, um eine gleichzeitige Kompromittierung durch ein Firmware-CVE oder einen fehlerhaften Hersteller-Rollout auszuschließen. [4]

Konkret im Einsatz bewähren sich:

Swissbit iShield Key 2 (bzw. iShield Key 2 Pro), produziert in Deutschland, FIDO2-zertifiziert, CTAP2, USB-A / USB-C / NFC, manipulationsgeschütztes Secure Element. Die Pro-Variante ergänzt PIV-Smartcard und OTP, was die gleiche Hardware auch für CBA-Szenarien nutzbar macht. [6]
YubiKey 5-Serie als etablierte Alternative.

Wichtig in der Entra-Konfiguration: AAGUID-Enforcement sollte für die Break-Glass-Gruppe aktiv sein. Nur die AAGUIDs der tatsächlich ausgegebenen Token-Modelle sind zugelassen, alles andere wird beim Registrierungsversuch abgelehnt. So lässt sich verhindern, dass ein bereits kompromittierter Admin-Account einen beliebigen, womöglich unzertifizierten Token registriert. Seit März 2026 ist zusätzlich der Rollout der neuen Passkey Profiles im Gange, die diese AAGUID-Logik granularer abbilden. [7][8]

Die AAGUIDs der Swissbit- und YubiKey-Modelle sind auf den Herstellerseiten dokumentiert und werden in Entra unter Authentication methods → Passkey (FIDO2) → Keys restrictions gepflegt.

Ein Break-Glass-Account meldet sich im Normalbetrieb nie an. Jede Anmeldung ist entweder ein geplanter Test oder ein echter Notfall, und in beiden Fällen muss die Administrator-Mannschaft das sofort mitbekommen, nicht erst morgen beim Durchsehen der Reports.

Microsoft dokumentiert das Monitoring-Setup explizit: Sign-In-Logs werden nach Azure Monitor bzw. Microsoft Sentinel gesendet, und eine Alert-Regel feuert auf Anmeldungen der beiden Break-Glass-Object-IDs. [3]

KQL-Beispielquery für zwei Accounts (anzupassen an die eigenen Object-IDs):

SigninLogs
| where UserId in (
    "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
    "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
)
| project TimeGenerated, UserPrincipalName, AppDisplayName,
          IPAddress, Location, ResultType, ResultDescription,
          ConditionalAccessStatus, AuthenticationRequirement

Die Alert-Regel im Log-Analytics-Workspace setzt auf Number of results > 0 mit einer Auswertungsfrequenz von 5 Minuten und einer Severity Sev 0 (Critical). Die Benachrichtigung geht an eine Action Group mit mindestens drei Administratoren über mindestens zwei unterschiedliche Kanäle (z. B. E-Mail und SMS). Das verhindert, dass ein Angreifer, der bereits Zugriff auf die Primärmailbox hat, das Alerting unbemerkt deaktivieren kann.

Ergänzend sinnvoll:

Audit-Log-Alerts auf Gruppenmitgliedschaftsänderungen der sg-breakglass-exclude-Gruppe.
Authentication-Methods-Alerts auf Änderungen an den registrierten FIDO2-Schlüsseln beider Accounts.
Password-Reset-Alerts auf die beiden Break-Glass-UPNs.

Alle drei Events sind frühe Indikatoren dafür, dass jemand versucht, den Notfallzugang zu übernehmen, noch bevor der erste Sign-In passiert.

7. Regelmäßiger Test und Review, dokumentiert

Ein Notfallzugang, den niemand getestet hat, ist kein Notfallzugang. Microsoft fordert einen regelmäßigen Validierungszyklus mit klar definierten Prüfpunkten: [3]

Mindestens alle 90 Tage durchläuft ein Admin den kompletten Anmeldeweg mit einem der Break-Glass-Accounts: Passwort aus dem Safe, FIDO2-Token-Authentifizierung, erfolgreiche Anmeldung am Entra-Admin-Center, Bestätigung der Global-Admin-Rolle.
Bei jedem Ausscheiden eines Mitarbeiters mit Zugriff auf die Safes, das Passwort oder einen der Token wird der Test außer der Reihe durchgeführt und die betroffenen Geheimnisse werden rotiert (Passwort neu, Tresor-Code neu).
Nach jeder Änderung am Lizenzmodell, an der Mandatskonfiguration oder an zentralen CA-Policies läuft der Test mit, um sicherzustellen, dass die Exclude-Gruppe noch greift.
Das Alerting wird im Rahmen jedes Tests aktiv validiert. Feuert der erwartete Alert? Kommt die Benachrichtigung bei allen vorgesehenen Empfängern an?

Die Ergebnisse dieser Tests gehören in ein Run-Book, das selbst nicht in einem Tenant liegt, der vom Ausfall betroffen sein könnte. Ein Confluence-Space im eigenen Atlassian-Tenant oder ein Wiki im Entra-ID-Tenant ist als Primärort ungeeignet. Eine Offline-Kopie in einem verschlossenen Ordnerschrank ist die richtige Redundanzstufe.

Häufige Fehler, die wir im Kundenumfeld sehen

Auch 2026 treffen wir noch auf dieselben Missverständnisse. Die Top 5:

Nur ein Break-Glass-Account. Weniger als zwei ist kein Break-Glass-Setup, sondern ein Single Point of Failure.
On-Premises-synchronisierter Notfall-Admin. Fällt Entra Connect oder das On-Prem-AD aus, ist der Account nicht erreichbar.
PIM-eligible statt permanent active. Im Störungsfall ist genau die Aktivierungs-Pipeline nicht nutzbar.
CA-Ausschluss nur über "exclude user" statt über eine Gruppe. Jede neue Policy muss manuell nachgezogen werden, das wird irgendwann vergessen.
Kein Alerting oder nur E-Mail-Alert an die eigene Admin-Mailbox. Ein kompromittierter Admin löscht den Alert, bevor der zweite Admin ihn sieht.

Seit Februar 2026 kommt ein sechster Klassiker dazu: Break-Glass-Account ohne registrierten FIDO2-Token, weil die Kollegen davon ausgegangen waren, der Conditional-Access-Ausschluss würde auch die Mandatory-MFA-Policy neutralisieren. Das tut er nicht. Ohne zweiten Faktor kommt der Account nicht mehr an den Admin-Portalen vorbei. [1][2]

Indeno Break-Glass-Paket mit Swissbit iShield Key 2

BGA mit Swissbit iShield Key 2

€ 999,‑ exkl. USt.

Alles inklusive

Komplette Einrichtung, vier Swissbit iShield Key 2, Konfiguration der Conditional-Access-Ausnahmen und Versand. Einsatzbereit in der gleichen Arbeitswoche.

Darin enthalten