Bildquelle: Pexels / Foto-ID 277574 / altes Schloss als Motiv für geschützten Notfallzugang, Zugriffskontrolle und Risiko einer Hintertür / https://www.pexels.com/photo/277574/
Ein Cyberangriff beginnt im Betrieb oft mit einer sehr einfachen Frage. Wer kann noch handeln, wenn zentrale Konten gesperrt sind, Mehrfaktor-Anmeldung ausfällt oder der Identitätsdienst selbst nicht erreichbar ist?
Ein Notfallzugang ist ein besonders geschützter Ersatzweg für administrative Arbeit in Ausnahmesituationen. Er soll nicht den normalen Login bequemer machen, sondern den Betrieb handlungsfähig halten, wenn die üblichen Identitäten, Geräte oder Freigabewege gestört sind. Für ITSM-Generalisten ist das wichtig, weil ein Identitätsausfall nicht nur ein Security-Thema ist. Er entscheidet darüber, ob Störungen eingegrenzt, Systeme isoliert und Wiederanlaufmaßnahmen überhaupt gestartet werden können.
Der letzte Zugang ist kein Komfortkonto
Notfallzugänge werden auch Break-Glass-Konten genannt. Das Bild passt, weil sie nur für echte Ausnahmen gedacht sind. Microsoft beschreibt für Entra ID eigene Emergency Access Accounts, die helfen sollen, den Zugriff auf eine Organisation zu behalten, falls normale Administratoren ausgesperrt sind. Gleichzeitig sollen diese Konten streng überwacht, getrennt von normalen Konten gehalten und regelmäßig getestet werden.
Der operative Fehler entsteht, wenn der letzte Zugang wie ein weiterer Admin-Login behandelt wird. Dann sammelt er zu viele Rechte, wird zu selten geprüft oder hängt an denselben Faktoren wie alle anderen Konten. Im Angriff wird daraus ein doppeltes Risiko. Entweder niemand kommt mehr hinein, oder Angreifer finden genau dieses Konto und nutzen es als Hintertür.
Identität ist ein Betriebsbaustein
Ein Ausfall der Anmeldung wirkt schnell wie ein technisches Einzelproblem. In Wirklichkeit blockiert er mehrere ITSM-Prozesse gleichzeitig. Der Service Desk kann keine Rollen prüfen, das Incident-Team kann keine Systeme isolieren, Change-Verantwortliche können keine Freigaben nachvollziehen und Provider können nicht sicher eingebunden werden. Wer dann erst Zuständigkeiten klärt, verliert Zeit.
Deshalb gehört der Notfallzugang nicht nur in eine Security-Richtlinie, sondern in den Betriebsplan kritischer Services. Der Plan muss beantworten, welche Systeme im Ernstfall zuerst erreichbar sein müssen, welche Rolle den Zugriff auslöst, wer die Nutzung genehmigt, wer sie protokolliert und wer danach die Rechte wieder zurücksetzt. Ohne diese Verbindung bleibt der Zugang zwar technisch vorhanden, aber organisatorisch unscharf.
Starke Authentisierung bleibt Pflicht
Ein Notfallzugang darf nicht schwach sein, nur weil er selten genutzt wird. CISA empfiehlt phishing-resistente Mehrfaktor-Authentisierung, also Verfahren, die nicht einfach durch gefälschte Login-Seiten abgefangen werden können. NIST SP 800-63B beschreibt Anforderungen an digitale Identitäten und Authentisierung und ordnet unter anderem ein, wie Authentifikatoren geschützt und wiederhergestellt werden sollen.
Für den Betrieb heißt das: Der Notfallzugang braucht eine eigene Schutzlogik. Er sollte nicht an dasselbe Smartphone, dieselbe Mailbox oder denselben Helpdesk-Prozess gebunden sein wie der normale Administratorzugang. Sonst kann eine kompromittierte Identität auch den Rettungsweg beschädigen. Sinnvoll sind getrennte Hardware-Schlüssel, sichere Aufbewahrung, dokumentierte Vertretung und ein klarer Nachweis, wann das Konto genutzt wurde.
Ein Test verhindert falsches Vertrauen
Ein Notfallkonto, das nie geprüft wird, ist nur eine Behauptung. Der Test muss nicht riskant sein. Er kann kontrolliert prüfen, ob Anmeldedaten vorhanden sind, ob der zweite Faktor funktioniert, ob die zuständigen Personen erreichbar sind und ob die Protokollierung sichtbar wird. Entscheidend ist, dass der Test nicht nur im Identitätsportal endet, sondern auch im ITSM-Prozess ankommt.
Nach jedem Test sollte sichtbar sein, ob ein Ticket erzeugt wurde, welche Genehmigung vorlag, wer beobachtet hat, welche Rechte aktiv waren und wann der Zugang wieder in den Normalzustand zurückging. So entsteht ein belastbarer Nachweis. Gleichzeitig sieht der Betrieb früh, ob Ansprechpartner gewechselt haben, Hardware-Schlüssel fehlen oder Dokumentationen veraltet sind.
Die Nutzung braucht einen engen Rahmen
Ein guter Notfallzugang hat weniger Alltag, nicht mehr. Er sollte im normalen Betrieb nicht für Routineänderungen verwendet werden. Seine Nutzung braucht eine klare Schwelle, zum Beispiel Ausfall des Identitätsdienstes, massenhafte Kontosperrung, bestätigte Kompromittierung privilegierter Konten oder notwendige Isolierung kritischer Systeme. Jede Nutzung muss später überprüft werden.
Auch die Rechte sollten begrenzt und nachvollziehbar sein. Der Zugang braucht genug Macht, um handlungsfähig zu bleiben, aber nicht unbegrenzte Bequemlichkeit. Wo möglich, sollten zusätzliche Freigaben, Vier-Augen-Prinzip, zeitlich begrenzte Rollen und nachgelagerte Kontrolle kombiniert werden. Das Ziel ist nicht ein geheimer Super-Admin, sondern ein kontrollierter Rettungsweg.
Prüffragen für ITSM und Betrieb
- Welche kritischen Services sind ohne Identitätsdienst nicht mehr steuerbar?
- Gibt es mindestens einen dokumentierten Notfallzugang für diese Lage?
- Ist der Zugang unabhängig von denselben Geräten, Mailboxen und Prozessen wie normale Admin-Konten?
- Wer darf die Nutzung auslösen und wer muss sie nachträglich prüfen?
- Wird jede Nutzung in Ticket, Log und Betriebsjournal sichtbar?
- Wann wurde der Zugang zuletzt getestet und wer hat das Ergebnis bestätigt?
Notfallzugänge sind ein kleines Detail mit großer Wirkung. Sie entscheiden nicht allein über Cyberresilienz, aber sie zeigen, ob Sicherheit und Betrieb zusammen gedacht wurden. Wer den letzten Zugang klar schützt, testet und in den ITSM-Ablauf einbettet, bleibt im Angriff handlungsfähig, ohne eine neue Hintertür zu schaffen.
Quellen und Einordnung: Microsoft Learn zu Emergency Access Accounts in Microsoft Entra ID, CISA Fact Sheet zu phishing-resistenter Mehrfaktor-Authentisierung, NIST SP 800-63B Digital Identity Guidelines. Bildquelle: Pexels, Foto-ID 277574. Stand der Quellenprüfung: 02.07.2026.
