Break-Glass-Konto
Ein bewusst reserviertes Notfall-Administratorkonto, das ausschließlich dann genutzt wird, wenn alle regulären privilegierten Zugänge versagen — etwa bei einer MFA-Störung oder einer fehlerhaften Zugriffsrichtlinie.
Ein Break-Glass-Konto (deutsch „Notfallzugang", vom englischen „break the glass" für den Griff zum Feuermelder hinter Glas) ist ein hochprivilegiertes Administratorkonto, das im Normalbetrieb ungenutzt bleibt und erst dann zum Einsatz kommt, wenn kein regulärer Administrator mehr Zugriff hat. Typische Auslöser sind eine ausgefallene MFA-Infrastruktur, eine fehlkonfigurierte Conditional-Access-Richtlinie, die alle Administratoren aussperrt, oder ein kompromittiertes bzw. gelöschtes Administratorkonto. Ohne funktionierende Break-Glass-Konten kann ein einziger Konfigurationsfehler einen kompletten Tenant-Lockout verursachen.
Warum Break-Glass-Konten notwendig sind
In modernen Cloud-Identitätsplattformen wie Entra ID werden Zugriffe über zentrale Richtlinien gesteuert. Genau diese Zentralisierung erzeugt ein Risiko: Eine einzige zu weit gefasste Zugriffsrichtlinie — etwa eine MFA-Erzwingung ohne Ausnahme — kann sämtliche Administratoren gleichzeitig aussperren. Auch der Ausfall eines externen Authentifizierungsdienstes oder eines Identity Providers führt dazu, dass sich niemand mehr anmelden kann. Break-Glass-Konten sind die Antwort auf dieses Szenario: Sie sind von den üblichen Abhängigkeiten entkoppelt und funktionieren auch dann, wenn der reguläre Anmeldeweg blockiert ist. In der Praxis finden wir in Assessments regelmäßig Tenants ganz ohne Notfallzugang — ein blinder Fleck, der im Ernstfall zu tagelangen Wiederherstellungsprozessen über den Hersteller-Support führt.
Konfiguration nach Best Practice
Ein belastbares Break-Glass-Konzept folgt einigen klaren Grundsätzen. Diese sind bewusst so gewählt, dass das Notfallkonto keine der Abhängigkeiten teilt, die reguläre Konten aussperren könnten.
| Anforderung | Begründung |
|---|---|
Cloud-only, *.onmicrosoft.com-Domäne |
Unabhängig von On-Prem-Synchronisierung und föderierter Anmeldung |
| Nicht an eine einzelne Person oder deren Gerät gebunden | Verfügbarkeit auch bei Personalwechsel oder Geräteverlust |
| Permanente Global-Administrator-Rolle | Kein Just-in-Time-Aktivierungsprozess, der selbst ausfallen kann |
| Von allen blockierenden Conditional-Access-Richtlinien ausgenommen | Verhindert die Selbst-Aussperrung durch eine fehlerhafte Richtlinie |
| Anmeldung löst einen sofortigen Alarm aus | Jede Nutzung muss auffallen, da sie ein Ausnahmefall ist |
Wichtig ist, dass mindestens zwei Break-Glass-Konten existieren, damit ein einzelnes gesperrtes oder defektes Konto nicht den letzten Zugang blockiert. Die dauerhafte, aktive Rollenzuweisung ist hier eine bewusste Ausnahme vom Least-Privilege-Prinzip: Der Notfallzugang darf nicht von einem Aktivierungsworkflow abhängen, der im Krisenfall ebenfalls nicht erreichbar sein könnte.
Absicherung: warum nicht SMS
Ein verbreiteter Irrtum ist, Break-Glass-Konten über SMS oder Anruf als zweiten Faktor abzusichern. Diese Verfahren sind nicht phishing-resistent und hängen von Mobilfunknetz, Rufnummer und einem externen Zustelldienst ab — allesamt Abhängigkeiten, die genau dann ausfallen können, wenn der Notfallzugang gebraucht wird. Microsoft empfiehlt für Notfallkonten ausdrücklich phishing-resistente Verfahren wie FIDO2-Sicherheitsschlüssel oder zertifikatsbasierte Authentifizierung — und zwar mit einer anderen Methode als die regulären Administratorkonten, damit ein Angriff auf die eine Methode nicht automatisch beide betrifft. Ein langes, sicher verwahrtes Passwort (in der Praxis 32 Zeichen oder mehr) ergänzt den physischen Schlüssel, wird aber getrennt von diesem aufbewahrt. Mit der Abschaltung der Microsoft-eigenen SMS- und Voice-MFA in Entra ID zum Februar 2027 wird ein rein SMS-gebundener Notfallzugang ohnehin zum Ausfallrisiko.
Test und Betrieb
Der am häufigsten vernachlässigte Punkt ist der regelmäßige Test. Ein Notfallkonto, das nie unter realistischen Bedingungen angemeldet wurde, ist keine Sicherheitsmaßnahme, sondern eine Annahme. Der Test muss die vollständige Anmeldung umfassen — nicht nur die Existenz des Kontos bestätigen. In der Praxis scheitern Break-Glass-Tests häufig an abgelaufenen FIDO2-Schlüsseln, an nachträglich ohne Ausnahme erstellten Conditional-Access-Richtlinien oder an nicht dokumentierten Passwörtern. Jeder fehlgeschlagene Test deckt eine reale Schwachstelle auf. Break-Glass-Konten sind zudem eng mit dem Incident-Response-Prozess und dem IT-Notfallplan verzahnt: Wer im Krisenfall darauf zugreifen darf, wo die Zugangsdaten verwahrt sind und wie die Nutzung protokolliert wird, gehört verbindlich dokumentiert.
Break-Glass in On-Prem und Cloud
Das Konzept existiert in beiden Welten. Im lokalen Active Directory übernimmt das DSRM-Passwort (Directory Services Restore Mode) auf dem Domänencontroller eine vergleichbare Funktion als Offline-Notfallzugang. In der Cloud sind Break-Glass-Konten eigenständige, cloud-only angelegte Identitäten. Wer eine hybride Infrastruktur betreibt, braucht für beide Ebenen einen definierten Notfallzugang — ein reines On-Prem-DSRM-Passwort hilft bei einem Entra-ID-Lockout nicht weiter, und umgekehrt.
Relevanz für KMUs
Gerade im Mittelstand, wo oft nur wenige Personen administrative Verantwortung tragen, ist der Notfallzugang existenziell: Fällt der einzige Administrator aus oder sperrt sich versehentlich selbst aus, steht ohne Break-Glass-Konto der gesamte Zugriff auf Microsoft 365 und Azure still. Die Einrichtung ist mit Bordmitteln und ohne Zusatzkosten möglich und gehört zu den ersten Maßnahmen einer soliden Entra-ID-Härtung. Entscheidend ist, den Notfallzugang nicht nur anzulegen, sondern ihn als Teil eines Zero-Trust-Konzepts sauber abzusichern, regelmäßig zu testen und die Nutzung zu überwachen.