Bildquelle: extern
Wenn SSO oder MFA ausfällt: Welche 5 Notfallregeln IT-Leitungen 2026 für Admin-Zugänge festziehen sollten
Viele Unternehmen haben ihre Administrationszugänge in den vergangenen Jahren stark zentralisiert. Genau das ist im Normalbetrieb sinnvoll: Single Sign-on, zentrale Richtlinien, starke Mehrfaktor-Authentifizierung und möglichst wenig lokale Sonderkonten. Das Problem zeigt sich erst im Störfall. Wenn die Föderation ausfällt, ein Identity Provider hängt, ein Mobilfunknetz streikt oder ein Administratorgerät verloren geht, kann aus sauberer Zentralisierung in wenigen Minuten ein kompletter Verwaltungsstillstand werden. Dann hilft es wenig, dass Produktionssysteme noch laufen, wenn niemand mehr in Microsoft 365, Google Workspace, IAM, Backup-Konsole oder Ticketing-Plattform hineinkommt.
Microsoft beschreibt dieses Risiko in seiner Guidance zu Emergency Access Accounts ungewöhnlich klar. Organisationen können sich aussperren, wenn föderierte Sign-ins nicht mehr funktionieren, wenn registrierte MFA-Methoden gerade nicht verfügbar sind oder wenn unvorhergesehene Ereignisse wie Naturkatastrophen oder Netzstörungen eintreten. Google argumentiert ähnlich für Super-Admin-Konten: Es sollte mehrere getrennt verwaltete Konten geben, Super-Admin-Rechte gehören nicht in den Tagesbetrieb, und Wiederherstellungsinformationen müssen gepflegt sein. NIST ordnet das Thema noch grundsätzlicher ein. Gute Resilienz entsteht nicht durch improvisierte Rettungswege, sondern durch geplante Vorsorge, klare Prioritäten und geübte Abläufe.
Für IT-Leitungen heißt das 2026 vor allem eines: Notfallzugänge sind keine historische Altlast, sondern ein bewusst gesteuertes Resilienz-Instrument. Fünf Regeln machen den Unterschied zwischen kontrollierter Handlungsfähigkeit und hektischem Kontrollverlust.
1. Für jede kritische Administrationsdomäne müssen mindestens zwei getrennte Notfallkonten existieren
Der häufigste Fehler ist verblüffend simpel: Es gibt genau ein „Break-Glass“-Konto, dessen Zugang irgendwo in einem Tresor liegt, das seit Monaten niemand geprüft hat und das im Ernstfall trotzdem wieder von einer einzelnen Person abhängt. Genau das ist kein Resilienzkonzept.
Microsoft empfiehlt ausdrücklich zwei oder mehr Emergency Access Accounts. Google empfiehlt ebenfalls mehr als ein Super-Admin-Konto, jeweils getrennt verwaltet. Der operative Punkt dahinter ist wichtig: Notfallkonten dürfen kein symbolisches Backup sein, sondern müssen Mehrpersonenfähigkeit schaffen. Wenn eine Person nicht erreichbar ist, krank wird oder selbst vom Vorfall betroffen ist, darf der Verwaltungszugang nicht mit ausfallen.
Praktisch bedeutet das: Definieren Sie pro kritischer Plattform, welche zwei Personen im Ernstfall auf getrennte Notfallzugänge zugreifen dürfen, wie diese Personen benannt werden und wer die Stellvertretung trägt. Das betrifft nicht nur den zentralen IdP, sondern auch Cloud-Plattformen, E-Mail- und Kollaborationsdienste, Backup- und Recovery-Werkzeuge sowie andere Kontrollebenen, von denen im Krisenfall weitere Schritte abhängen.
2. Mindestens ein Notfallpfad muss den Ausfall der Föderation und des normalen SSO überleben
Viele Unternehmen sichern ihre Administratoren sauber ab, aber komplett innerhalb derselben Vertrauenskette. Alle Admin-Konten hängen am selben lokalen Active Directory, am selben externen IdP oder am selben bedingten Zugriffsmodell. Fällt diese Kette aus, ist zwar formal noch ein Konto vorhanden, operativ aber kein Zugang mehr möglich.
Genau deshalb verlangt Microsoft für Emergency Access Accounts cloud-only Konten, die nicht aus dem lokalen Verzeichnis synchronisiert und nicht von einer gestörten Föderation abhängig sind. Das ist der Kern der Regel: Ein Notfallkonto ist nur dann ein Notfallkonto, wenn es außerhalb der wahrscheinlichsten Fehlerkaskade liegt.
Für IT-Leitungen heißt das in der Praxis: Prüfen Sie pro Plattform explizit, ob der vorgesehene Rettungszugang noch funktioniert, wenn der IdP, die Synchronisation oder der Standard-SSO-Pfad ausfällt. Wer diese Frage nicht mit einem klaren Ja beantworten kann, besitzt keinen belastbaren Notfallpfad, sondern nur eine zweite Version desselben Risikos.
3. Notfallkonten brauchen starke Authentisierung, dürfen aber nicht im Tagesgeschäft genutzt werden
Ein weiterer Reifegradfehler ist die falsche Alternative zwischen Sicherheit und Nutzbarkeit. Manche Unternehmen schützen ihre Rettungskonten so kompliziert, dass sie im Ernstfall praktisch unbenutzbar sind. Andere lassen sie bequem erreichbar und machen sie damit selbst zum Hochrisikoobjekt. Beides ist gefährlich.
Google empfiehlt Sicherheitskeys als besonders widerstandsfähige 2-Step-Verification-Methode für Administratoren. Microsoft empfiehlt für Emergency Accounts passwortlose und phishing-resistente Verfahren wie FIDO2 oder zertifikatsbasierte Authentisierung. Gleichzeitig betonen beide Anbieter, dass hochprivilegierte Konten nicht für tägliche Aufgaben verwendet werden sollen.
Der richtige Mittelweg lautet daher: Notfallkonten werden mit starken, phishing-resistenten Verfahren abgesichert, ihre Zugangsmittel werden kontrolliert und getrennt aufbewahrt, und die Konten bleiben aus dem regulären Tagesgeschäft heraus. Wer dieselben Konten für Routinearbeiten benutzt, erhöht die Angriffsfläche, erzeugt Log-Rauschen und riskiert, dass gerade der letzte Rettungsweg durch eine alltägliche Kompromittierung verloren geht.
4. Wiederherstellung, Benachrichtigung und Kontaktwege dürfen nicht vollständig an derselben Plattform hängen
Ein SaaS- oder Identity-Vorfall scheitert oft nicht am ersten technischen Problem, sondern an der zweiten Welle. Niemand bekommt Warnmeldungen, weil die Admin-Benachrichtigungen im betroffenen E-Mail-System landen. Passwortrücksetzungen scheitern, weil Wiederherstellungsinformationen fehlen. DNS-Zugänge, Abrechnungsdaten oder alternative Kontaktadressen sind veraltet. Genau hier wird aus einem handhabbaren Problem ein Führungsvorfall.
Google empfiehlt sekundäre E-Mail-Kontakte für wichtige Admin-Ankündigungen und betont, dass für die Wiederherstellung von Super-Admin-Konten unter anderem Recovery-Daten und gegebenenfalls DNS-Zugänge verfügbar sein müssen. NIST ordnet solche Abhängigkeiten sauber in die Kontingenzplanung ein: Kritische Funktionen, Rollen und Ressourcen müssen vorab identifiziert werden, statt erst im Vorfall gesucht zu werden.
Für den Betriebsalltag heißt das: Legen Sie fest, wohin Notfallmeldungen außerhalb des Primärsystems gehen, wer Zugriff auf Domain- und Billing-Daten hat, wo Recovery-Informationen aktuell gehalten werden und welche Kontaktkette greift, wenn das zentrale Kollaborationstool selbst Teil des Problems ist. Ein Notfallzugang ohne funktionierenden Kommunikations- und Wiederherstellungsweg bleibt halbfertig.
5. Notfallzugänge müssen geübt, protokolliert und wieder sauber aus dem Ausnahmezustand zurückgeführt werden
Die vielleicht wichtigste Regel ist zugleich die unbeliebteste: Ein Notfallkonto, das nie getestet wird, ist nur eine Annahme. NIST beschreibt Resilienz als Ergebnis geplanter und bewerteter Vorsorge. Auch Microsoft empfiehlt das Monitoring von Sign-in- und Audit-Logs für Emergency Accounts. Das ist entscheidend, denn ein Rettungsweg ist nicht nur für den Ernstfall da, sondern selbst ein sensibles Steuerungsobjekt.
Deshalb sollten IT-Leitungen verbindlich festlegen, wie oft Notfallzugänge getestet werden, wer die Aktivierung freigibt, wie ein Einsatz protokolliert wird und welche Nacharbeiten zwingend folgen. Dazu gehören zum Beispiel das Zurücksetzen betroffener Zugangsmittel, die Prüfung aller vorgenommenen Änderungen, ein kurzer Management-Review und die Aktualisierung der Lessons Learned im Incident- oder BCM-Prozess.
Besonders wichtig ist die Rückführung in den Normalbetrieb. Sonst bleiben Rettungskonten nach einem Vorfall länger aktiv als nötig, Ausnahmeregeln werden stillschweigend normalisiert und die Organisation verliert schrittweise die Kontrolle über ihre privilegierten Zugänge.
Was IT-Leitungen in den nächsten 30 Tagen konkret anstoßen sollten
- Kritische Kontrollpunkte inventarisieren: IdP, M365, Google Workspace, Backup, Cloud-IAM, DNS, Ticketing und weitere Admin-Oberflächen priorisieren.
- Zwei belastbare Notfallkonten je Kernplattform prüfen: Getrennte Verantwortliche, kein Shared Account, dokumentierte Stellvertretung.
- SSO-Abhängigkeit testen: Für jeden Rettungszugang klären, ob er bei Föderations-, Sync- oder MFA-Störungen tatsächlich noch funktioniert.
- Recovery- und Kontaktpfade bereinigen: Sekundäre Mailadressen, DNS-Zugänge, Billing-Kontakte und sichere Aufbewahrung der Authentisierungsmittel aktualisieren.
- Tabletop und Log-Monitoring fest verankern: Quartalsweise Übung, Alarmierung bei Nutzung, definierte Nachbereitung.
2026 ist die Frage nicht mehr, ob Unternehmen starke zentrale Identitäts- und Zugriffsmodelle brauchen. Die brauchen sie. Die eigentliche Führungsfrage lautet, ob diese Modelle auch dann noch administrierbar bleiben, wenn ihre wichtigsten Annahmen gerade ausfallen. Notfallzugänge sind deshalb kein Rückschritt in alte Admin-Gewohnheiten, sondern ein professionell begrenzter Rettungsmechanismus für genau die Momente, in denen hochstandardisierte IT plötzlich wieder handlungsfähig werden muss.
