Wer sich mit Break-Glass-Accounts beschäftigt, kennt die Theorie: Ein Notfallkonto mit höchsten Privilegien, isoliert vom regulären Zugriffspfad, streng überwacht und nur im Ernstfall aktiviert. Doch zwischen Konzept und Umsetzung liegen in der Praxis erhebliche Hürden. Es ist wichtig zu beachten, wie ein Break-Glass-Account in Microsoft Entra ID aufgesetzt, abgesichert und betriebsbereit gehalten wird.
Warum ein Cloud-only-Konto die Basis bildet
Der erste und wichtigste Grundsatz: Ein Break-Glass-Account darf niemals von On-Premises-Systemen abhängen. Wer ein synchronisiertes Konto verwendet, verliert den Notfallzugang genau dann, wenn die hybride Infrastruktur ausfällt – also im einzigen Szenario, für das der Account gedacht ist. Microsoft empfiehlt ausdrücklich, ausschließlich Cloud-only-Konten unter der *.onmicrosoft.com-Domäne zu verwenden. Damit ist sichergestellt, dass der Zugriff selbst bei einem vollständigen Ausfall von Active Directory Federation Services oder Pass-Through Authentication erhalten bleibt.
Ebenso entscheidend ist die Benennung. Der Accountname sollte keinen Rückschluss auf seine Funktion erlauben. Bezeichnungen wie „admin-notfall“ oder „break-glass“ sind ein Risiko, weil Angreifer bei Password-Spraying-Angriffen systematisch nach solchen Mustern suchen. Stattdessen empfiehlt sich ein unauffälliger, zufällig wirkender Name.
Authentifizierung: Warum FIDO2 der richtige Weg ist
Die Absicherung des Break-Glass-Accounts erfordert ein Gleichgewicht zwischen maximaler Sicherheit und garantierter Verfügbarkeit. Microsoft hat seine Empfehlungen in den letzten Jahren deutlich verschoben: Weg von langen Passwörtern ohne MFA, hin zu phishing-resistenten Verfahren auf Basis von FIDO2-Sicherheitsschlüsseln.
FIDO2-Token wie YubiKeys bieten dabei mehrere Vorteile. Sie binden die Authentifizierung kryptografisch an die Zieldomäne – ein Adversary-in-the-Middle-Angriff, wie ihn aktuelle Phishing-Plattformen ermöglichen, läuft damit ins Leere. Gleichzeitig sind die Schlüssel unabhängig von Netzwerkverbindungen, Mobilfunkempfang oder Cloud-Diensten. Sie benötigen keine Batterie, keinen Treiber und keine Software – ideale Voraussetzungen für ein Gerät, das möglicherweise jahrelang im Tresor liegt und im Ernstfall sofort funktionieren muss.
Die empfohlene Konfiguration: Zwei FIDO2-Schlüssel pro Break-Glass-Account, an zwei physisch getrennten Standorten verwahrt. Der erste Schlüssel liegt im Tresor der Geschäftsführung, die zugehörige PIN in einem versiegelten Umschlag beim Notar oder in einem Bankschließfach. Der zweite Schlüssel wird invers gelagert. Damit ist selbst bei Hardwaredefekt eines Schlüssels Redundanz gewährleistet, und der Zugriff erfordert stets Zugang zu zwei getrennten Aufbewahrungsorten.

Conditional Access: Die richtige Ausnahme konfigurieren
Break-Glass-Accounts müssen aus allen Conditional-Access-Richtlinien ausgenommen werden, die den Zugriff unter Umständen blockieren könnten. Das umfasst MFA-Richtlinien auf Basis von SMS oder Authenticator-App, Geräte-Compliance-Anforderungen, standortbasierte Einschränkungen und Richtlinien zur Anmelderisikobehandlung. Der sauberste Weg führt über eine dedizierte Sicherheitsgruppe, die ausschließlich die Break-Glass-Accounts enthält und in jeder Conditional-Access-Policy als Ausnahme definiert wird.
Gleichzeitig sollte eine eigene Conditional-Access-Richtlinie erstellt werden, die ausschließlich für die Break-Glass-Gruppe gilt und phishing-resistente MFA via FIDO2 erzwingt. Damit wird verhindert, dass jemand, der an das Passwort gelangt, sich ohne physischen Schlüssel anmelden kann.
Monitoring: Jede Aktivität muss einen Alarm auslösen
Ein Break-Glass-Account, der nicht überwacht wird, ist ein offenes Scheunentor. Jede Anmeldung, jeder fehlgeschlagene Versuch und jede administrative Aktion müssen in Echtzeit erfasst und alarmiert werden. In Microsoft Entra ID lässt sich dies über Azure Monitor und Log Analytics umsetzen. Eine Alert-Regel, die bei jeder Anmeldeaktivität des Notfallkontos eine Benachrichtigung per E-Mail und SMS auslöst, ist das Minimum.
Wer über ein SOC as a Service verfügt, sollte die Break-Glass-Accounts als hochpriorisierte Entitäten in das SIEM integrieren. Dedizierte Korrelationsregeln können dabei zwischen einem geplanten Test und einer ungewöhnlichen Anmeldung unterscheiden und das Incident-Response-Team direkt benachrichtigen.

Regelmäßige Validierung: Vertrauen ist gut, Testen ist Pflicht
Ein Break-Glass-Account, der im Ernstfall nicht funktioniert, ist wertlos. Deshalb empfiehlt sich eine vierteljährliche Validierung. Der Test sollte den vollständigen Zugriffsprozess abbilden: Öffnen des Tresors, Entnehmen des FIDO2-Schlüssels, Anmeldung am Entra-ID-Portal, Durchführen einer administrativen Aktion und anschließendes Zurücksetzen. Dabei wird gleichzeitig geprüft, ob die Monitoring-Alarme korrekt auslösen und die zuständigen Personen erreichen.
Nach jedem Test und nach jedem realen Einsatz müssen die Ergebnisse dokumentiert und das Passwort rotiert werden. Der Test selbst sollte als Vorgang im Ticketsystem erfasst sein, damit das SOC-Team die Anmeldung korrekt einordnen kann.
Brauchen Sie Unterstützung bei der Einrichtung und Überwachung Ihrer Break-Glass-Accounts? Unsere Cyber Security-Experten beraten Sie gerne.