Microsoft 365 stand still. Ihre Nachweise auch.

/01Was am 31. August passiert ist

Microsoft bestätigte den Vorfall am 31.08.2026 gegen 17:30 Uhr UTC — kurz vor halb acht abends mitteleuropäischer Sommerzeit — und führte ihn im Admin Center unter der Kennung EX1464935. Nutzer meldeten Verzögerungen und Fehlschläge beim Senden und Empfangen, Authentifizierungsfehler beim Zugriff auf Exchange Online und unvollständige Ergebnisse bei der Postfachsuche. Downdetector zählte zehntausende Meldungen.

Als vorläufige Ursache nannte Microsoft ein Problem in einer zentralen Authentifizierungskonfiguration, die von mehreren internen Diensten der Exchange-Online-Infrastruktur genutzt wird. Techniker setzten Konfigurationen serverweise von Hand zurück. Deutschsprachige Berichte führten den Fehler auf ein nicht rechtzeitig erneuertes Zertifikat zurück — bestätigt war das zum Zeitpunkt dieses Artikels nicht.

/02Der eigentliche Befund: eine Fehlerdomäne

Ein E-Mail-Ausfall ist ärgerlich und in den meisten Betrieben nach ein paar Stunden aufgeholt. Was diesen Vorfall lehrreich macht, ist die Liste der mitbetroffenen Dienste: neben Exchange Online auch Microsoft Teams, SharePoint Online und OneDrive for Business, Microsoft Purview und Microsoft Defender XDR.

Lesen Sie die Liste noch einmal von hinten. Defender XDR ist die Erkennung am Endpunkt. Purview trägt Protokollierung, Aufbewahrung und Auditspuren — die Grundlage für ISO 27001 und DSGVO-Nachweise. Teams ist der Ausweichkanal, wenn E-Mail steht. SharePoint hält die Dokumente, in denen das Runbook liegt. Alle vier hingen an derselben Authentifizierungskomponente wie das Postfach.

Das ist keine Verkettung unglücklicher Umstände, sondern eine Bauform. Wer Arbeitsplatz, Kommunikation, Dokumente, Erkennung und Nachweis bei einem Anbieter mit einer gemeinsamen Identitätsschicht (Entra ID) bezieht, hat eine Fehlerdomäne — einen Bereich, der gemeinsam ausfällt. Das ist bequem, es ist meistens günstig, und es ist an genau zwei Tagen im Jahr ein Problem.

/03Warum das ein NIS2-Problem ist

Seit dem 6. Dezember 2025 gilt das deutsche Umsetzungsgesetz zu NIS2 ohne Übergangsfrist. Betroffene Einrichtungen müssen einen erheblichen Sicherheitsvorfall binnen 24 Stunden an das BSI melden. Diese Frist läuft ab Kenntnis — sie läuft auch dann, wenn die Werkzeuge zur Kenntnisnahme gerade nicht erreichbar sind.

Nun stellen Sie sich einen Angriff vor, der zufällig in dasselbe Zeitfenster fällt. Ihre Erkennung ist weg. Ihre Protokolle sind nicht abrufbar. Ihre Dokumentenablage mit dem Meldeformular ist offline. Ihr Ausweichkanal zur Belegschaft ebenfalls. Sie haben 24 Stunden, und Sie haben keine Sicht.

Das ist kein konstruiertes Szenario. Es ist die Kombination aus zwei unabhängigen Wahrscheinlichkeiten, die beide nicht klein sind. Und es ist der Grund, warum Protokollierung und Erkennung nach Möglichkeit nicht in derselben Domäne liegen sollten wie das, was sie überwachen.

/04Local Breakout — was es löst und was nicht

Local Breakout heißt: Datenverkehr zu Cloud-Diensten verlässt den Standort direkt ins Internet, statt zuerst über eine Zentrale oder ein Rechenzentrum geleitet zu werden. Microsoft empfiehlt das für Microsoft 365 ausdrücklich, weil der Umweg Latenz kostet und die eigene Firewall zum Nadelöhr macht.

Der Nutzen ist real und wird oft unterschätzt: In vielen Betrieben ist der häufigere Ausfallgrund nicht Microsoft, sondern der eigene Weg dorthin — eine überlastete Zentrale, ein VPN-Konzentrator, eine einzelne Leitung. Wer lokal ausbricht, nimmt diese Glieder aus der Kette und braucht dafür keine neue Serverlandschaft, sondern eine Änderung an Routing, Proxy und Regelwerk — häufig zusammen mit einem Umstieg von klassischem VPN auf ZTNA.

Local Breakout löst das Wegproblem. Es löst nicht das Abhängigkeitsproblem. Beides ist sinnvoll, aber es sind zwei Projekte mit zwei Begründungen — und das erste ist deutlich billiger als das zweite.

/05Die fünf Prozent, die nicht stehenbleiben dürfen

Die Antwort auf einen Cloud-Ausfall ist nicht der Rückzug aus der Cloud. Für die allermeisten Betriebe ist Microsoft 365 verfügbarer, sicherer und billiger, als sie es selbst hinbekämen. Die Antwort ist eine Trennung: Welche wenigen Funktionen dürfen nicht gleichzeitig mit ausfallen?

In der Praxis sind es drei.

Mailannahme

Ein eigener Mailrelay vor der Cloud nimmt Nachrichten an und hält sie in der Warteschlange, solange das Ziel nicht erreichbar ist. Ihre Kunden bekommen keine Unzustellbarkeitsmeldung, Ihre Lieferanten auch nicht. Sobald Exchange Online zurück ist, läuft die Warteschlange aus. Das ist ein kleiner Dienst mit sehr begrenztem Pflegeaufwand — und der einzige Baustein, der während des Ausfalls sichtbar Geld spart, weil keine Anfrage verlorengeht.

Protokollierung und Erkennung

Wenn Protokolle in einer Umgebung liegen, die mit ausfällt, sind sie genau dann nicht da, wenn man sie braucht. Ein eigenes SIEM, das Ereignisse entgegennimmt und aufbewahrt, ist unabhängig von der überwachten Domäne — und liefert den Nachweis, den NIS2 verlangt, auch dann, wenn der Anbieter gerade schweigt.

Ein zweiter Weg zur Belegschaft

Wenn E-Mail und Teams gleichzeitig stehen, braucht es einen dritten Kanal. Das muss keine Plattform sein. Eine gepflegte Mobilnummernliste außerhalb von SharePoint und ein abgestimmter Ablauf reichen — vorausgesetzt, beides liegt nicht dort, wo der Ausfall ist.

/06Was das kostet, und was es nicht ist

Rechnen Sie zuerst die andere Seite. Microsoft 365 erreichte im ersten Quartal 2026 eine Verfügbarkeit von 99,526 Prozent. Das sind rund 614 Minuten Ausfall im Quartal und der niedrigste Wert seit Beginn der Messung im Jahr 2013. Das Service-Level-Versprechen liegt bei 99,9 Prozent im Monat, also etwa 43 Minuten — und eine Gutschrift erhält nur, wer sie selbst per Support-Ticket beantragt. Der Ersatz ist ohnehin ein Prozentsatz der Monatsgebühr, nicht ein Ausgleich für den entgangenen Auftrag.

Setzen Sie dagegen Ihre eigene Zahl: Was kostet ein Arbeitstag, an dem niemand Mail hat? Bei fünfzig Mitarbeitenden ist das keine Frage der Bequemlichkeit mehr. Ein Mailrelay und ein eigenes Protokollsystem liegen zusammen im unteren dreistelligen Bereich pro Monat. Das ist keine Versicherung gegen alles, sondern gegen genau diesen Fall.

/07Die erste Stunde: ein Ablauf, der ohne Cloud funktioniert

Ein Runbook, das in SharePoint liegt, ist bei einem SharePoint-Ausfall wertlos. Das klingt banal, ist aber der häufigste Fehler, den wir bei Bestandsaufnahmen finden. Der Ablauf für die erste Stunde gehört auf Papier und auf ein Gerät, das nicht am Konto hängt.

• Feststellen, wo der Fehler liegt. Erreichen andere Standorte den Dienst? Funktioniert der Zugriff über Mobilfunk statt über das Firmennetz? Zwei Minuten Prüfung entscheiden, ob Sie ein eigenes Problem haben oder ein fremdes — und ob überhaupt etwas zu tun ist.
• Statusquelle festlegen. Das Microsoft 365 Admin Center und die Statusmeldungen des Anbieters, nicht Meldungen aus sozialen Netzen. Die Vorfallkennung notieren, hier EX1464935 — sie ist später der Beleg gegenüber Kunden und Prüfern.
• Belegschaft erreichen. Über den vorher festgelegten dritten Kanal, mit einer Sprachregelung: was funktioniert, was nicht, wann die nächste Meldung kommt.
• Kunden informieren, bevor sie fragen. Wer den Ausfall selbst meldet, verliert kein Vertrauen. Wer wartet, bis der erste Anruf kommt, schon.
• Mitschreiben. Uhrzeit, Symptom, betroffene Bereiche, Entscheidung. Diese Notizen sind später die Grundlage für den Post-Mortem und, im Fall eines meldepflichtigen Vorfalls, für die Meldung selbst.

Der letzte Punkt ist der, der am häufigsten unterbleibt und am meisten wert ist. Eine mitgeschriebene Zeitleiste ist der Unterschied zwischen einer Meldung, die trägt, und einer Rekonstruktion aus dem Gedächtnis drei Tage später.

/08Wie Sie die drei Bausteine einführen

Die Reihenfolge ist keine Geschmacksfrage. Sie ergibt sich aus Aufwand und Wirkung.

Beginnen Sie oben. Der dritte Kanal und ein ausgedrucktes Runbook kosten fast nichts und wirken gegen jeden Ausfall, auch gegen den, bei dem Ihr eigener Internetanschluss ausfällt. Das Mailrelay ist der erste Baustein mit Betriebsaufwand — und der einzige, der während eines Ausfalls unmittelbar Geld rettet, weil eingehende Anfragen nicht abgewiesen werden.

Was beim Mailrelay schiefgehen kann

Der technische Teil ist unaufwendig. Der heikle Teil sind die DNS-Einträge: MX, SPF, DKIM und DMARC müssen zusammenpassen, sonst sinkt die Zustellbarkeit — und ein Zustellproblem ist schlimmer als der Ausfall, gegen den Sie sich absichern wollten. Das ist der Grund, warum wir diesen Schritt nicht nebenbei machen und nicht am Freitagnachmittag.

Was die Protokollierung wirklich leisten muss

Nicht alles sammeln, sondern das Richtige: Anmeldungen, administrative Änderungen, Postfachzugriffe, Weiterleitungsregeln. Entscheidend ist, dass die Ablage außerhalb der überwachten Domäne liegt und manipulationssicher ist. Ein SIEM auf eigener Infrastruktur erfüllt beides, ein Export in dieselbe Cloud nicht. Für die Frage, wie lange aufbewahrt werden muss, gilt: Der Rechtstext nennt weniger feste Fristen, als die verbreiteten Merksätze behaupten.

Der Anspruch ist am Ende bescheiden. Es geht nicht um Wiederanlauf im Sinne eines zweiten Rechenzentrums und auch nicht um RPO und RTO für die gesamte Umgebung. Es geht darum, dass drei Dinge weiterlaufen, wenn ein vierter Anbieter einen schlechten Abend hat.

/09Kein Einzelfall: das Jahr 2026 in Zahlen

Ein einzelner Ausfall rechtfertigt keine Investition. Ein Muster schon. Und das Muster ist 2026 deutlicher geworden, als die Wahrnehmung nahelegt.

Die gemessene Verfügbarkeit von Microsoft 365 lag im ersten Quartal 2026 bei 99,526 Prozent. Das entspricht rund 614 Minuten Ausfall im Quartal — gut zehn Stunden — und ist der niedrigste Wert seit Beginn der Veröffentlichung im Jahr 2013. Zum Vergleich: Das zugesicherte Niveau von 99,9 Prozent im Monat entspricht etwa 43 Minuten. Die gemessene Quartalszahl liegt um ein Vielfaches über dem, was das Versprechen zulässt.

Dazu passen die dokumentierten Vorfälle des Jahres. In der Nacht zum 23. Januar 2026 fielen Outlook, Defender und Purview über Stunden aus, schwerpunktmäßig in Nordamerika. Im Juni traf es Exchange Online unter der Kennung EX1331830 auf drei Kontinenten. Ende August folgte EX1464935. Drei größere Ereignisse in acht Monaten, alle mit Übergriff auf Dienste jenseits der E-Mail.

Was das für die Vertragslage bedeutet

Das Service-Level-Agreement ist finanziell hinterlegt, aber die Hinterlegung ist schwächer, als viele annehmen. Die Gutschrift bemisst sich am Anteil der Monatsgebühr für den betroffenen Dienst, nicht am wirtschaftlichen Schaden. Sie wird nicht automatisch erstattet, sondern muss vom Kunden per Support-Ticket beansprucht werden. Und sie deckt keine Folgekosten: nicht den entgangenen Auftrag, nicht die Überstunden, nicht die verlorene Anfrage, die beim Wettbewerber gelandet ist.

Wer Verfügbarkeit absichern will, sichert sie also nicht über das SLA des Anbieters ab, sondern über Architektur. Das ist die unbequeme, aber ehrliche Antwort — und es ist derselbe Gedanke, mit dem man Sicherungen begründet: nicht weil der Speicher schlecht wäre, sondern weil ein zweiter, unabhängiger Weg das Einzige ist, was gegen den Ausfall des ersten hilft.

Für Einrichtungen, die unter KRITIS- oder NIS2-Pflichten fallen, kommt ein zweiter Punkt hinzu: Aufsichtsbehörden interessiert nicht, wer den Ausfall verursacht hat, sondern ob die Einrichtung ihre Pflichten trotzdem erfüllen konnte. Ausgelagerte Verantwortung bleibt Verantwortung — das gilt für Managed Services genauso wie für die Public Cloud.

/10Spiegel-Infrastruktur: wenn drei Bausteine nicht reichen

Die drei Bausteine aus Abschnitt /05 sind die untere Stufe. Sie verhindern, dass Post verlorengeht und dass Sie blind sind. Sie sorgen nicht dafür, dass weitergearbeitet wird. Für einen Betrieb, in dem ein Ausfalltag ein paar tausend Euro kostet, ist das genug. Für einen Betrieb, in dem die Fertigung steht, ist es das nicht.

Die obere Stufe heißt Spiegel-Infrastruktur: ein zweiter, vollständiger Satz der betriebskritischen Dienste, der mitläuft — nicht kalt danebensteht. Dieselben Postfächer, dieselben Dateien, dieselben Konten, laufend abgeglichen und jederzeit übernahmefähig. Der Unterschied zu einem Notfallkonzept auf Papier ist, dass die Umschaltung geprobt ist, weil das System ohnehin läuft.

Was gespiegelt wird — und was nicht

Nicht alles verdient einen Spiegel. Gespiegelt wird, was den Betrieb anhält: Mail, Dateiablage, Verzeichnisdienst und die Fachanwendung, ohne die niemand arbeitet. Nicht gespiegelt wird, was einen Tag warten kann — Auswertungen, Archive, Zusammenarbeit an Dokumenten, die nicht dringend sind. Diese Trennung ist der eigentliche Beratungsteil; die Technik danach ist Handwerk.

Bei uns läuft ein solcher Spiegel auf eigener Hardware in unserem Rechenzentrum in Coburg, mit dem Ausweichstandort in Neustadt. Das ist standortgetrennt, und wir nennen es bewusst nicht georedundant: beide Häuser liegen in Oberfranken und erfüllen die BSI-Empfehlung von über 200 Kilometern nicht. Wer diese Entfernung braucht, bekommt sie — dann aber über einen dritten Standort und mit der entsprechenden Rechnung.

Der Weg dorthin ist keine Grundsatzentscheidung, sondern eine Reihenfolge. Man beginnt mit den drei Bausteinen, weil sie in Tagen stehen. Man spiegelt danach das, was zuerst weh tut. Und man stellt am Ende fest, dass die hybride Lösung nicht der Kompromiss war, sondern die Bauform, die man von Anfang an hätte wählen sollen.

/11Häufige Fragen