Microsoft 365 richtig absichern: Conditional Access, MFA-Ausnahmen und Break-Glass-Accounts im Alltag

Wer Microsoft 365 richtig absichern will, kommt an Conditional Access (zugriffsabhängige Richtlinien in Entra ID, früher Azure AD) und Multi-Faktor-Authentifizierung (MFA, also Anmeldung mit mindestens zwei Faktoren) nicht vorbei. In vielen Unternehmen sind MFA und erste Conditional-Access-Regeln schnell aktiviert – und dann beginnt die Arbeit erst: Ausnahmen müssen begründet, Notfallzugänge sauber organisiert und Betriebsprozesse so gestaltet werden, dass Sicherheit nicht zur Supportlawine wird.

In der Praxis scheitert „M365 absichern“ selten an der grundsätzlichen Technik, sondern an Alltagsthemen: Servicekonten für Schnittstellen, Legacy-Protokolle, Außendienst ohne verlässliches Mobilnetz, Admins mit zu breiten Rechten, oder ein Incident, bei dem genau die Schutzmaßnahme den Zugriff der IT blockiert. Dieser Beitrag ordnet ein, wie Conditional Access, MFA-Ausnahmen und Break-Glass-Accounts zusammenwirken – und wie Sie das Ganze so betreiben, dass es auch nach dem Go-live verlässlich bleibt.

Warum Conditional Access der Hebel ist – und MFA allein nicht reicht

MFA reduziert das Risiko gestohlener Passwörter deutlich, aber MFA ist kein vollständiges Zugriffskonzept. Conditional Access (CA) entscheidet kontextabhängig, unter welchen Bedingungen ein Zugriff erlaubt ist: z. B. nur von verwalteten Geräten, nur aus bestimmten Ländern, nur mit risikobasierter Bewertung oder nur mit bestimmten Client-Apps. Das ist der entscheidende Schritt Richtung Zero Trust (Sicherheitsmodell, bei dem kein Zugriff per Default vertraut wird, sondern laufend geprüft).

Typische Gründe, warum MFA allein in Microsoft 365 nicht genügt:

• Token statt Passwort: Moderne Authentifizierung arbeitet mit Tokens (zeitlich begrenzte Zugriffstickets). Ein gestohlenes Token kann MFA umgehen, wenn CA keine zusätzlichen Bedingungen fordert (z. B. Gerätezustand oder Sitzungssteuerung).
• Admin-Risiko: Administrative Konten sind besonders attraktiv. Ohne CA-Regeln für Adminzugänge (z. B. nur von Admin-Workstations oder nur mit Phishing-resistentem MFA) bleibt die größte Angriffsfläche offen.
• „Erlaubt“ ist zu breit: Wenn CA nicht zwischen Apps, Datenklassen und Zugriffsarten unterscheidet, wird Sicherheit schnell entweder zu lasch oder zu restriktiv – beides erzeugt Probleme.

Der operative Kern ist daher: CA als Policy-Schicht, MFA als Baustein darin, plus ein sauberes Ausnahmemanagement und belastbare Notfallpfade.

Architekturüberblick: Was Conditional Access in Entra ID tatsächlich steuert

Für IT-Leitung und Betrieb ist wichtig, CA nicht als „eine Richtlinie“ zu verstehen, sondern als Entscheidungskette. Entra ID bewertet bei jeder Anmeldung Signale und wendet Policies an. Wichtige Signale sind:

• Identität: Nutzer, Gruppen, Rollen (z. B. privilegierte Rollen wie Global Administrator).
• Zielressource: Cloud-App (Exchange Online, SharePoint/OneDrive, Teams, aber auch Drittanbieter per Enterprise App).
• Client-Typ: Browser, moderne Clients, mobile Apps, sowie „Legacy Authentication“ (ältere Protokolle ohne moderne Token, z. B. ältere IMAP/POP/SMTP-Auth-Varianten).
• Gerätezustand: „Compliant“ oder „hybrid joined“ (verwaltetes Gerät, typischerweise über Intune oder Domänenanbindung mit Gerätestatus).
• Netzwerk/Standort: Named Locations (definierte IP-Ranges), Länder/Regionen, Risikoindikatoren.
• Sitzungsbedingungen: Session Lifetime, App-Enforced Restrictions, Continuous Access Evaluation (laufende Neubewertung bei Risikoereignissen).

Aus Betriebssicht hängt die Qualität Ihrer CA-Konfiguration stark daran, ob diese Signale verlässlich sind. Ein Named Location ist nur so gut wie Ihre IP-Adresshygiene. „Compliant“ ist nur so gut wie Ihre Geräteverwaltung und die Definition von Compliance. Und die Risikobewertung ist nur dann hilfreich, wenn Sie mit den daraus entstehenden Events auch arbeiten.

Microsoft 365 richtig absichern mit Conditional Access: Ein praxistaugliches Policy-Set

Statt einer „großen“ Regel funktioniert im Alltag ein Set aus wenigen, klar abgegrenzten Policies besser. Das reduziert Seiteneffekte und macht Fehlersuche im Incident einfacher. Ein bewährtes Grundmuster besteht aus:

1) Baseline für alle Nutzer: MFA erzwingen, Legacy blocken

Für normale Benutzerkonten ist die Baseline: MFA erforderlich, und Legacy Authentication wird blockiert. Legacy ist hier nicht „altmodisch“, sondern technisch problematisch: Diese Protokolle unterstützen häufig keine moderne MFA-Challenge und sind deshalb ein klassischer Einstiegspunkt für Passwortspraying.

Wichtig: Blocken Sie Legacy nicht „irgendwann“, sondern planen Sie eine Übergangsphase mit Messung. Prüfen Sie über Sign-in Logs, welche Clients noch Legacy nutzen. In Unternehmen hängen daran gerne Multifunktionsdrucker, Scan-to-Mail, oder ältere Mailclients in Spezialumgebungen.

2) Admin-Policy: deutlich strenger als die Baseline

Privilegierte Rollen sollten eine eigene Policy bekommen: Zugriff nur von definierten Admin-Endgeräten (z. B. „compliant“ und ggf. separate Admin-Workstation-Strategie), MFA mit hoher Sicherheit (phishing-resistent, z. B. FIDO2/Passkey oder Zertifikat-basiert), und möglichst Einschränkungen für riskante Länder/Standorte. Auch wenn nicht jedes Unternehmen sofort eine vollständige Privileged-Access-Architektur (PAM, also privilegiertes Zugriffsmanagement) einführt, lohnt dieser Unterschied sofort: Ein kompromittiertes Adminkonto ist ein anderer Schadensraum als ein kompromittiertes Nutzerkonto.

3) Policy für externe Zusammenarbeit und Gäste

Gastzugriffe (B2B Collaboration) erzeugen häufig unerwartete Datenpfade: Gäste laden Dateien aus SharePoint, arbeiten in Teams oder greifen auf Projektportale zu. Legen Sie hier bewusst fest, ob Gäste nur mit MFA rein dürfen, ob bestimmte Apps ausgeschlossen sind und wie lange Sessions gültig sind. Für Projektarbeit ist oft eine kürzere Session-Lebensdauer sinnvoll, um das Risiko „vergessener Logins“ zu reduzieren.

4) Policy für sensible Datenpfade: Gerät oder Sitzung absichern

Der Alltag kennt unterschiedliche Schutzbedarfe: Ein Vertriebsmitarbeiter darf vielleicht von jedem Gerät E-Mails lesen, aber nicht ohne verwaltetes Gerät große Datenmengen aus SharePoint herunterladen. Solche Unterschiede bilden Sie nicht über pauschales „erlaubt/verbietet“, sondern über CA-Kombinationen: „Zugriff erlaubt, wenn Gerät compliant“ oder „Zugriff nur per Browser mit eingeschränkter Sitzung“. Das ist weniger hart als komplettes Blocken – und trotzdem wirksam.

MFA-Ausnahmen: Wo sie realistisch sind – und wie man sie kontrolliert

MFA-Ausnahmen sind kein Zeichen von Schwäche, solange sie bewusst gestaltet und betrieblich kontrolliert sind. Ohne kontrollierte Ausnahmen entstehen Schattenlösungen: Nutzer umgehen Prozesse, Admins schalten Regeln hektisch ab, und irgendwann ist die Policy-Sammlung nicht mehr nachvollziehbar.

Wichtig ist die Unterscheidung: Eine MFA-Ausnahme ist selten „MFA aus“, sondern oft „MFA anders“ oder „Zugriff nur unter anderen Bedingungen“. Typische Ausnahmekategorien:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Viele prozessnahe Softwarelösungen integrieren M365-Dienste: E-Mail-Versand, Kalenderzugriff, SharePoint-Dateiablage, Teams-Benachrichtigungen oder Graph-API-Zugriffe. Solche Integrationen sollten nicht über Benutzerkonten mit deaktiviertem MFA laufen. Besser ist ein technischer Zugriff über App-Registrierungen (Anwendung in Entra ID) mit klaren Berechtigungen und Secret-/Zertifikatslebenszyklus. Das ist keine „MFA-Ausnahme“, sondern eine andere Authentifizierungsart, die auditierbarer ist.

Betriebsfolgen: Secrets müssen rotiert werden, Zertifikate laufen ab, und Berechtigungen müssen rezertifiziert werden. Wenn Sie Integrationen planen, definieren Sie Ownership (wer erneuert Zertifikate/Secrets) und Monitoring (z. B. Warnungen vor Ablauf). Sonst wird aus „sicherer“ App-Auth ein ungeplanter Ausfall.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Hier entstehen die klassischen Diskussionen um SMTP-Relay, Scan-to-Mail oder Raum-Postfächer. Die falsche Lösung ist fast immer „ein Benutzerkonto ohne MFA“. Besser sind technische Pfade, die nicht an interaktiver Anmeldung hängen: zentraler Mail-Relay mit IP-Restriktion, Zertifikats- oder Connector-Ansätze, oder getrennte Systempostfächer mit engen Berechtigungen. Entscheidend ist: Das Gerät selbst kann MFA nicht bedienen, also muss das Design am Transport- und Netzpfad abgesichert werden.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Außendienst, Produktion oder Schichtbetrieb haben Situationen ohne Handyempfang oder ohne private Mobilgeräte. Hier lohnt es sich, früh über alternative MFA-Methoden nachzudenken: Hardware-Token, FIDO2-Sicherheitsschlüssel, oder Windows Hello for Business (gerätegebundene Anmeldung). „Temporär MFA aus“ ist operativ verlockend, skaliert aber schlecht und lässt sich kaum auditieren.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Manche Altsysteme starten Jobs „als Benutzer“, etwa für SharePoint-Uploads oder Reports. Das ist aus heutiger Sicht riskant, weil es Rollen und Zugriffsrechte vermischt. Wenn Ablösung nicht sofort möglich ist, arbeiten Sie mit Zwischenstufen: begrenzte Servicekonten, klare Named Locations, starke Passwort-/Secret-Policies und konsequente Protokollierung. Und: planen Sie die Migration auf App-Identitäten als eigenes Arbeitspaket ein, nicht als „später mal“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Ausnahmen sind im Betrieb nur dann akzeptabel, wenn sie einen Lebenszyklus haben. Praktisch bewährt hat sich ein leichtgewichtiges Vorgehen, das ohne Bürokratie auskommt, aber trotzdem auditfest ist:

1. Begründung in einem Satz: Welche Geschäfts- oder Betriebsfunktion hängt daran (z. B. „Scan-to-Mail an Standort X“)?
2. Technische Einordnung: Welche App/Protokolle, welche Konten, welche Datenpfade?
3. Kompensierende Kontrollen: Was begrenzt das Risiko (IP-Restriktion, minimal notwendige Rechte, Monitoring)?
4. Ablaufdatum: Jede Ausnahme bekommt ein Review-Datum. Ohne Review wird sie entfernt oder neu genehmigt.
5. Owner: Wer ist verantwortlich, wenn es klemmt oder wenn die Ausnahme ausläuft?

Damit werden Ausnahmen nicht „gut“, aber sie werden steuerbar. Und genau das ist im Alltag der Unterschied zwischen einer robusten M365-Sicherheitsbasis und einem Richtlinien-Wildwuchs.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass-Accounts sind Notfallkonten für den Zugriff auf den Tenant, wenn reguläre Adminzugänge nicht funktionieren – etwa durch Fehlkonfiguration in Conditional Access, Ausfall eines MFA-Providers oder einen Identity-Incident. Der Zweck ist klar, aber die Umsetzung hat typische Fallen: Ein Break-Glass-Konto, das nie getestet wird, hilft im Ernstfall nicht. Ein Break-Glass-Konto, das zu bequem erreichbar ist, ist ein attraktives Angriffsziel.

Was Break-Glass nicht ist

• Kein tägliches Admin-Konto: Es darf nicht im normalen Betrieb genutzt werden.
• Kein Ausnahmen-Sammelbecken: Es ersetzt kein sauberes CA-Design.
• Kein „wir haben eins, passt schon“: Ohne Prozess, Test und Alarmierung ist es nur ein theoretischer Plan.

Grundprinzipien für Break-Glass im Betrieb

Ein praktikables Setup orientiert sich an drei Zielen: erreichbar im Notfall, schwer angreifbar im Normalbetrieb, und sauber nachvollziehbar.

• Mindestens zwei Konten: Redundanz gegen Sperrung, Fehlbedienung oder kompromittierte Zugangsdaten.
• Stark abgesichert: Lange, zufällige Passwörter; keine E-Mail-Weiterleitungen; keine Nutzung für Apps/Integrationen.
• Gezielt aus CA ausgenommen – aber eng: Typisch ist eine Ausnahme von bestimmten CA-Policies, damit man im Notfall nicht durch eigene Regeln ausgesperrt wird. Gleichzeitig sollten andere Sicherheitsmechanismen greifen: Alarme bei Nutzung, restriktive Rollenvergabe, getrennte Aufbewahrung der Zugangsdaten.
• Protokollierung und Alarmierung: Jede Anmeldung muss ein sofortiges Signal auslösen (SIEM/SOC oder zumindest E-Mail/Teams-Alarm an ein Incident-Postfach). Die Break-Glass-Nutzung ist per Definition ein Sicherheitsereignis.

Ein zentraler Punkt: Entscheiden Sie bewusst, ob Break-Glass mit oder ohne MFA betrieben wird. Viele Organisationen lassen es ohne MFA, um bei MFA-Ausfall handlungsfähig zu bleiben. Dann müssen aber die kompensierenden Kontrollen besonders sauber sein (Aufbewahrung, Zugriff auf das Passwort, Alarmierung, regelmäßiger Wechsel). Alternativ kann man Break-Glass mit hardwarebasiertem MFA (z. B. FIDO2) ausstatten, das unabhängig von Mobilfunk ist. Wichtig ist nicht die „richtige“ Ideologie, sondern ein Notfallpfad, der in Ihrem Kontext real funktioniert.

Rollout-Realität: So vermeiden Sie Lockouts und Support-Spitzen

Viele CA-/MFA-Rollouts scheitern nicht technisch, sondern organisatorisch: zu schnell, zu breit, ohne Telemetrie und ohne klaren Supportprozess. Ein stabiler Rollout arbeitet mit Wellen und Messpunkten.

Schritt 1: Sichtbarkeit schaffen (bevor Sie blocken)

Nutzen Sie Sign-in Logs und Auswertungen, um herauszufinden: Welche Apps werden genutzt? Welche Clients sind „Legacy“? Welche Standorte/IP-Ranges sind real? Welche Nutzer haben besonders viele Anmeldeprobleme? Ohne diese Daten ist jede Policy ein Blindflug.

Schritt 2: Pilotgruppen mit echten Sonderfällen

Piloten sollten nicht nur „IT und ein paar Freiwillige“ sein. Nehmen Sie bewusst Randfälle hinein: Außendienst, Produktionsstandorte, Projektmitarbeiter mit Gastzugriff, und mindestens eine Abteilung mit typischen Drittanbieter-Tools. Ziel ist nicht Harmonie, sondern das frühe Finden der echten Stolpersteine.

Schritt 3: Helpdesk-Playbooks festlegen

Wenn MFA erzwungen wird, steigen Tickets an: Gerätewechsel, verlorene Telefone, neue Mitarbeitende, Konto gesperrt nach zu vielen Versuchen. Legen Sie fest, was der First-Level lösen darf (z. B. MFA-Reset nach Identitätsprüfung) und wann eskaliert wird. Ohne Playbooks eskaliert alles – und die Admins werden zum Flaschenhals.

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA macht versteckte technische Schulden sichtbar: veraltete Mailclients, nicht dokumentierte Scanner, Skripte mit Passwort im Task Scheduler, oder Integrationen, die noch Basic Auth nutzen. Planen Sie diese Nacharbeiten als sichtbare Arbeitspakete ein. Sonst bleiben sie als „dauerhafte Ausnahme“ hängen.

Typische Fehlerbilder aus dem Betrieb – und wie man sie schneller einordnet

Im Alltag zählen schnelle Hypothesen. Einige Muster kommen immer wieder:

„Plötzlich geht Outlook nicht mehr“

Häufige Ursachen: Legacy-Client, altes Profil, oder ein CA-Block wegen fehlendem Gerätezustand. Prüfen Sie: Client-Typ im Sign-in Log, angewendete CA-Policy, und ob das Gerät als compliant geführt wird. Der operative Fix ist selten „Policy aus“, sondern „Client modernisieren“ oder „Geräteverwaltung sauberziehen“.

„Service XY kann keine E-Mails mehr senden“

Oft steckt eine Umstellung von SMTP-Authentifizierung, eine geänderte Relay-Policy oder eine neue CA-Regel dahinter, die unbeabsichtigt auch technische Konten erfasst. Hier hilft ein klarer Architekturentscheid: Versand über Relay/Connector statt Benutzerlogin, mit IP-Restriktion und Logging (Nachvollziehbarkeit im Incident).

„Admin kommt nicht mehr in den Tenant“

Das ist der Moment, für den Break-Glass gedacht ist. Wenn der Break-Glass-Zugang ebenfalls nicht funktioniert, fehlt meist ein getesteter Notfallpfad oder die Ausnahme wurde falsch gebaut. Deshalb: Nutzung regelmäßig üben (mit Dokumentation, wer wann testet, und wie der Alarm aussieht).

„Zu viele Ausnahmen – niemand blickt durch“

Das ist ein Governance-Problem. Konsolidieren Sie Policies, definieren Sie ein Review-Ritual (z. B. monatlich 30 Minuten), und entfernen Sie Ausnahmen, die keine Owner/keinen Zweck mehr haben. Technisch ist das nicht glamourös, aber es ist der Unterschied zwischen kontrollierbarer Sicherheit und historisch gewachsenen Sonderrechten.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA und MFA erzeugen viele Events. Wenn Sie alles sammeln, ertrinken Sie; wenn Sie nichts auswerten, merken Sie Probleme zu spät. Praktisch sinnvoll sind drei Ebenen:

• Alarmierung auf harte Ereignisse: Break-Glass-Login, Admin-Login aus ungewöhnlichen Ländern, Block-Events auf kritischen Apps.
• Regelmäßige Reviews: Top-Blockgründe, Top-User mit MFA-Problemen, Legacy-Auth-Versuche, neue Apps/Enterprise Apps.
• Audit-Spur für Ausnahmen: Wer hat welche Ausnahme genehmigt, mit welchem Ablaufdatum, und wann wurde reviewed?

Wenn Sie bereits zentrale Logging- und Incident-Prozesse haben (SIEM, Ticketing, Change-Management), verankern Sie CA-Änderungen dort. Conditional Access ist keine „kleine Einstellung“, sondern eine produktionskritische Zugriffsschicht.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

CA-/MFA-Projekte werden unterschätzt, weil sie wie reine Konfiguration wirken. In Wahrheit sind es Schnittstellenprojekte zwischen Identität, Endgeräten, Netz und Fachprozessen. Ein sauberes Verantwortungsmodell reduziert Reibung:

• Identity-Team / Entra Admins: Policy-Design, Rollenmodell, Break-Glass, App-Registrierungen.
• Client-Management (z. B. Intune): Compliance-Definition, Gerätestatus, Rollout von Authenticator/Passkeys, Gerätelebenszyklus.
• Netzwerk: IP-Ranges für Named Locations, Proxy/TLS-Inspection-Ausnahmen, Standortwechsel.
• Service Owner von Business-Anwendungen: Integrationspfade (Graph/SMTP/SharePoint), Umstellung von Legacy-Auth, Secret-Rotation.
• Helpdesk: Standardprozesse für MFA-Reset, Gerätewechsel, Onboarding/Offboarding.

Die wichtigste Managemententscheidung ist oft nicht „MFA ja/nein“, sondern: Haben wir Zeit und Ressourcen für die Nacharbeiten (Legacy abbauen, Integrationen modernisieren, Geräteverwaltung stabilisieren)? Ohne diese Arbeit bleibt der Sicherheitsgewinn hinter den Erwartungen – oder der Betrieb wird unnötig schwer.

Fazit: Sicherheit gewinnt, wenn Notfall und Ausnahme zum System gehören

Microsoft 365 richtig absichern bedeutet, Conditional Access als zentrale Steuerungsschicht zu betreiben – nicht als einmalige Konfiguration. MFA ist dabei Pflicht, aber die eigentliche Betriebsqualität entsteht durch saubere Ausnahmen (mit Ablaufdatum, Owner und kompensierenden Kontrollen) und durch Break-Glass-Accounts, die getestet, überwacht und organisatorisch eingebettet sind. Wer diese drei Elemente zusammendenkt, reduziert Account-Risiken, bekommt Auditfähigkeit ohne Overhead und verhindert, dass Sicherheitsregeln im Incident zum eigenen Gegner werden.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.