Notfallzugänge dürfen nicht erst im Ausfall erklärt werden

Ein Notfallzugang soll helfen, wenn normale Anmeldewege ausfallen oder ein kritisches System schnell administriert werden muss. Gefährlich wird er, wenn erst im Ernstfall geklärt wird, wer ihn benutzen darf, wie die Nutzung überwacht wird und wann der Zugang wieder geschlossen ist.

Notfallzugänge, oft auch Break-Glass-Konten genannt, sind besonders geschützte Konten für Ausnahmesituationen. Sie sollen Zugriff ermöglichen, wenn zentrale Anmeldung, Mehrfaktorverfahren, Identitätsdienste oder reguläre Administrationswege nicht verfügbar sind. Für ITSM-Generalisten ist das kein reines Security-Detail. Es betrifft Wiederanlauf, Verantwortlichkeit, Nachweisbarkeit und die Frage, wie viel Ausnahme ein Betrieb wirklich kontrollieren kann.

Der Zugang selbst ist noch kein Notfallplan

Ein Konto mit hohen Rechten kann im Ausfall wertvoll sein. Es kann aber auch zum größten blinden Fleck werden, wenn es dauerhaft unklar bleibt. Microsoft empfiehlt für Emergency-Access-Konten unter anderem klare Trennung von normalen Administrationskonten, Schutz vor alltäglicher Nutzung und regelmäßige Überprüfung. NIST beschreibt in seinen Digital-Identity-Leitlinien ebenfalls, dass Authentifizierung, Zugriff und Wiederherstellungswege so gestaltet sein müssen, dass sie nachvollziehbar und kontrollierbar bleiben.

Die operative Frage lautet deshalb nicht nur: Gibt es einen Notfallzugang? Sie lautet: Ist seine Nutzung so geregelt, dass im Stress niemand improvisieren muss? Wenn die Antwort fehlt, wird aus einer Sicherheitsreserve ein organisatorisches Risiko. Dann entscheidet im Ausfall nicht der vorbereitete Ablauf, sondern die Person, die gerade Zugriff, Mut oder Erinnerung an ein altes Passwort hat.

Drei Dinge müssen vor dem Ernstfall feststehen

Erstens braucht jeder Notfallzugang einen Zweck. Er darf nicht als bequemer Ersatz für reguläre Administration dienen. Ein Konto für Identitätsausfall hat eine andere Aufgabe als ein Zugang für Netzwerkgeräte, Backup-Systeme oder eine Cloud-Konsole. Je genauer der Zweck beschrieben ist, desto leichter lässt sich später prüfen, ob die Nutzung berechtigt war.

Zweitens braucht der Zugang eine Besitzerrolle. Das muss nicht eine einzelne Person sein. Sinnvoll ist oft eine klare Verantwortungsgruppe mit benannten Vertretungen. Wichtig ist, dass Service Desk, Security, Infrastruktur und Management wissen, wer im Ernstfall entscheiden darf, wer informiert wird und wer nach der Nutzung die Nachkontrolle übernimmt.

Drittens braucht der Zugang eine Rückkehrregel. Nach der Nutzung muss klar sein, welche Sitzungen beendet, welche Passwörter oder Schlüssel gewechselt, welche Protokolle geprüft und welche Tickets geschlossen werden. Ohne diesen Abschluss bleibt die Ausnahme im System hängen. Dann ist der technische Zugriff vielleicht beendet, aber der Sicherheitszustand nicht sauber wiederhergestellt.

Tests zeigen, ob die Regel wirklich funktioniert

Notfallzugänge dürfen nicht erst beim echten Ausfall zum ersten Mal praktisch geprüft werden. Ein kurzer Test im kontrollierten Fenster zeigt, ob Zugangsdaten auffindbar sind, ob die zuständigen Personen erreichbar sind, ob Protokollierung funktioniert und ob die Rückkehr in den Normalbetrieb dokumentiert wird. Der Test muss kein großes Krisenspiel sein. Er muss aber zeigen, dass der Ablauf nicht nur auf einer Wiki-Seite steht.

Gerade Mehrfaktorverfahren brauchen hier Aufmerksamkeit. Ein Notfallkonto, das im Ernstfall an genau demselben ausgefallenen Identitätsdienst hängt wie alle anderen Konten, hilft wenig. Gleichzeitig darf die Umgehung von Mehrfaktorregeln nicht zur Dauerausnahme werden. Der bessere Weg ist ein bewusstes Sonderverfahren mit sehr engem Zugriff, starker Ablagekontrolle, Alarmierung und Nachprüfung.

Der Service Desk braucht eine einfache Meldekette

Im Ausfall landet die erste Nachfrage häufig beim Service Desk. Dort muss nicht jedes technische Detail liegen, aber die Meldekette muss klar sein. Wer darf den Notfallzugang anfordern? Welche Mindestinformationen gehören ins Ticket? Welche Führungskraft oder Sicherheitsrolle wird informiert? Welche Zeitmarken werden dokumentiert?

Ein gutes Ticket enthält Auslöser, betroffenen Dienst, angefragten Zugriff, genehmigende Rolle, Startzeit, Endzeit, ausgeführte Maßnahmen und Folgeaufgaben. Das schützt nicht vor jeder Fehlentscheidung, aber es verhindert, dass der Zugriff im Nachhinein nur über Chatnachrichten und Erinnerung rekonstruiert werden kann.

Ausnahmezugriff ist ein Betriebsprozess

Notfallzugänge sind kein Zeichen von Misstrauen gegen Administratoren. Sie sind ein Zeichen dafür, dass der Betrieb auch unter Druck handlungsfähig bleiben will. Gerade deshalb müssen sie wie ein eigener kleiner Betriebsprozess behandelt werden: selten genutzt, klar begrenzt, regelmäßig getestet und nach jeder Nutzung nachbereitet.

Der entscheidende Satz gehört nicht ins Krisenmeeting, sondern in die Vorbereitung: Wer darf diesen Zugang nutzen, wofür genau, unter welcher Kontrolle und mit welchem Abschluss? Wenn diese vier Punkte beantwortet sind, wird der Notfallzugang vom riskanten Generalschlüssel zur kontrollierten Reserve.

Quellen und Einordnung: Microsoft Entra Emergency Access Accounts, NIST SP 800-63B Digital Identity Guidelines. Stand der Quellenprüfung: 13.07.2026. Bildquelle: Pexels, Foto-ID 101808.