Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Am Montagabend, dem 31. August 2026, begann um 17:53 Uhr ein weltweiter Microsoft 365 Ausfall, der erst am Dienstagmorgen um 06:07 Uhr bei Mailversand und -empfang behoben war. Betroffen waren Exchange Online, Outlook, Teams, SharePoint und Defender XDR: Anmeldungen schlugen fehl, Postfächer synchronisierten nicht mehr, Anwendungen froren ein. Microsoft nennt als Ursache einen Fehler in einer zentralen Authentifizierungskomponente; Fehlermeldungen deuten auf ein abgelaufenes internes Zertifikat hin. Wir ordnen den Ablauf ein und zeigen, welche Vorbereitung einen solchen Ausfall beherrschbar macht.
Das Wichtigste in Kürze
- Weltweite Störung von Microsoft 365 vom 31.08.2026, 17:53 Uhr, bis zum 01.09.2026, 06:07 Uhr - gut zwölf Stunden ohne verlässlichen Mailverkehr.
- Betroffen waren Exchange Online, Outlook, Teams, SharePoint und Defender XDR; Microsoft führte den Vorfall unter der Kennung EX1464935.
- Ursache war laut Microsoft eine fehlerhafte Konfiguration der Kern-Authentifizierung, die mehrere Dienste gemeinsam nutzen.
- Fehlermeldungen aus dem Partnercenter deuten auf ein abgelaufenes internes Zertifikat hin; ausdrücklich bestätigt hat Microsoft das bislang nicht.
- Kunden konnten nichts reparieren - die einzige wirksame Vorbereitung sind ein zweiter Kommunikationsweg, lesender Zugriff auf ältere Mails und ein bekanntes Vorgehen für den Ausfalltag.
So verlief der Microsoft 365 Ausfall
Der Vorfall begann nach Microsofts eigener Zeitangabe am Montag um 17:53 Uhr MESZ. Im Message Center des Microsoft-365-Admin-Centers erschien die Meldung, man habe „ein häufiges Fehlermuster bei betroffenen Exchange-Online-Anfragen identifiziert, das mit der Authentifizierung und der Protokollverbindung zusammenhängt“. Geführt wurde der Vorfall unter der Kennung EX1464935, für die weiteren Dienste kamen die Kennungen MO1465074 und EX1465001 hinzu.
Zunächst sah es nach einem reinen Exchange-Online-Problem aus. Im Lauf des Abends erweiterte Microsoft den Kreis der beeinträchtigten Dienste auf Teams, SharePoint und Defender XDR. Wer über Outlook oder über die Weboberfläche outlook.office.com auf sein Postfach zugreifen wollte, erhielt Authentifizierungsfehler; auch die Exchange-Verwaltungsumgebungen waren betroffen.
Auffällig war die ungleiche Verteilung: Nach Beobachtung von Günter Born, der den Vorfall in seinem Blog dokumentiert hat, waren innerhalb desselben Tenants nicht alle Postfächer gleich stark betroffen. Für die Fehlersuche in den Unternehmen war das ein zusätzliches Problem, weil der Ausfall zunächst nach einem lokalen Fehler aussah.
In der Nacht spielten Microsoft-Techniker gezielte Korrekturen ein und nahmen nach eigenen Angaben ein Update zurück, das die betroffene Infrastruktur kurz zuvor erhalten hatte. Um 06:07 Uhr am Dienstagmorgen meldete Microsoft Mailempfang und -versand als wiederhergestellt. Die tagesschau berichtete am Morgen von einer schrittweisen Erholung; Rückstaus im Mailversand und die weltweite Synchronisation brauchten danach noch Zeit.
Zahlen, Daten, Fakten
Beginn der Störung: 31.08.2026, 17:53 Uhr (MESZ). Mailversand und -empfang wieder verfügbar: 01.09.2026, 06:07 Uhr. Vorfallkennung im Microsoft-365-Admin-Center: EX1464935.
Stunden ohne verlässlichen Mailverkehr
0
betroffene Microsoft-365-Dienste
0
Vorfallkennungen im Admin-Center
0
Handlungsoptionen auf Kundenseite
0
Abgelaufenes Zertifikat als Ursache des Ausfalls
Offiziell spricht Microsoft von „einer Konfiguration der Kern-Authentifizierung, die mehrere Dienste nutzten“. Das erklärt, warum ein Problem, das als Exchange-Störung begann, kurz darauf auch Teams und SharePoint erfasste: Alle diese Dienste hängen an derselben Anmeldeschicht.
Konkreter wird es durch eine Fehlermeldung aus dem Microsoft-Partnercenter, die Günter Born und das Fachmagazin IT-Administrator aufgegriffen haben: Darin wird ein Zertifikat mit einem bestimmten Fingerabdruck als abgelaufen bezeichnet. Das passt zum Fehlerbild, ist aber ein Indiz und keine Bestätigung – Microsoft hat ein abgelaufenes Zertifikat als Auslöser bislang nicht ausdrücklich benannt.
Zum Hintergrund
Interne Zertifikate sind Ausweise, mit denen sich die Bausteine eines Cloud-Dienstes gegenseitig als vertrauenswürdig erkennen. Läuft ein solcher Ausweis ab, weist die Gegenstelle die Verbindung ab – unabhängig davon, ob die Software fehlerfrei arbeitet. Ein einzelnes abgelaufenes Zertifikat an zentraler Stelle kann deshalb eine ganze Dienstfamilie stoppen.
Zertifikatsthemen sind bei Exchange Online in diesem Jahr nicht neu. Ende Juni 2026 dokumentierte Born ein Problem mit einer veralteten Zertifikatskette bei Exchange Online Protection, das den Mailversand von Linux-Systemen über den SMTP-Relay traf. Der Fall lag technisch anders, zeigt aber dasselbe Muster: Zertifikate laufen still ab, bis nichts mehr geht.
Was der Ausfall im Betrieb bedeutet
Für die betroffenen Unternehmen fiel nicht nur die E-Mail aus. Wer Teams als primären Chat- oder Telefonieweg nutzt, verlor gleichzeitig den Rückkanal, über den ein Ausfall sonst kommuniziert wird. Auch Notfallpläne und Kontaktlisten waren nicht erreichbar, sofern sie ausschließlich in SharePoint liegen.
Die Sicherheitsüberwachung fällt mit aus
Der wenig beachtete Punkt ist Defender XDR. Wenn die Sicherheitsüberwachung Teil derselben Störung ist, sinkt für die Dauer des Ausfalls die Erkennungsfähigkeit. Hinweise auf eine Ausnutzung gibt es nicht; für die Planung bleibt trotzdem festzuhalten, dass Betrieb und Sicherheitsüberwachung gleichzeitig ausfallen, wenn beides beim selben Anbieter liegt.
Für die Praxis heißt das: Ein Kunde konnte an diesem Abend nichts reparieren. Es gab keinen Patch, keine Einstellung und keinen Neustart, der geholfen hätte. Der einzige Hebel liegt in der Vorbereitung.
Hinweise für IT-Admins nach dem Ausfall
Die folgenden Punkte lassen sich in den meisten Umgebungen ohne großen Aufwand umsetzen:
1
Statusquelle festlegen
Den Microsoft-365-Servicestatus und das Message Center im Admin-Center als verbindliche Informationsquelle benennen, ergänzt um den Kanal @MSFT365Status. So ist beim nächsten Mal in Minuten geklärt, ob der Fehler beim Anbieter oder im eigenen Netz liegt.
2
Zweiten Kommunikationsweg bereithalten
Einen Messenger oder Telefonweg außerhalb von Microsoft 365 festlegen, inklusive gepflegter Rufnummernliste. Ein Notfallplan, der nur in SharePoint liegt, ist im Ernstfall nicht verfügbar.
3
Lesenden Zugriff auf ältere Mails sichern
Eine unabhängige E-Mail-Archivierung erlaubt es, auf bereits zugestellte Nachrichten zuzugreifen, während das Postfach nicht erreichbar ist.
4
Mailfluss von außen absichern
Klären, wie eingehende Mails bei einem Ausfall behandelt werden. Sendende Systeme stellen in der Regel automatisch erneut zu; Weiterleitungen auf Zweitadressen brauchen dagegen eine bewusste Entscheidung und einen Datenschutzblick.
5
Rückstau einplanen
Nach der Entstörung laufen Nachrichten verzögert ein. Rechnen Sie mit doppelten Zustellungen und mit falschen Zeitstempeln in Ticket- und Freigabeprozessen.
6
Ausfall dokumentieren
Beginn, Ende, betroffene Dienste und Vorfallkennung festhalten. Diese Aufzeichnung ist die Grundlage für die spätere Bewertung von Verfügbarkeit und für Gespräche über Service Level.
7
Abhängigkeiten sichtbar machen
Notieren, welche Geschäftsprozesse ohne Microsoft 365 stillstehen. Meist ist die Liste länger als erwartet, weil Freigaben, Zeiterfassung und Telefonie mit daran hängen.
Bedeutung für Geschäftsführung und Entscheider
Dieser Vorfall ist kein Sicherheitsproblem und kein Grund, Cloud-Dienste in Frage zu stellen. Eigene Serverräume fallen ebenfalls aus, meist länger und ohne ein Technikerteam, das die Nacht durcharbeitet. Die betriebswirtschaftlich richtige Frage lautet deshalb nicht „Cloud oder nicht“, sondern: Wie lange hält unser Geschäft einen Ausfall der zentralen Kommunikationsplattform aus?
Zwölf Stunden ohne E-Mail sind für ein Handelsunternehmen mit Bestelleingang per Mail eine andere Größenordnung als für einen Betrieb, der überwiegend telefonisch arbeitet. Diese Einschätzung lässt sich nur intern treffen, und sie gehört schriftlich festgehalten. Aus ihr ergibt sich, ob ein zweiter Kommunikationsweg, eine unabhängige Archivierung oder eine abweichende Auslegung einzelner Prozesse nötig ist.
Zu beachten ist außerdem der vertragliche Rahmen: Die Verfügbarkeitszusagen von Microsoft gelten gegenüber dem Kunden, nicht gegenüber dessen Kunden. Wer selbst Reaktionszeiten zusagt, sollte prüfen, ob diese Zusagen einen Ausfall des Cloud-Anbieters berücksichtigen. Für Unternehmen im Anwendungsbereich der NIS-2-Regulierung sind Verfügbarkeit und Notfallvorsorge ohnehin ausdrücklich Thema.
Der Aufwand für die Vorbereitung ist gering. Ein zweiter Kommunikationsweg, eine gepflegte Kontaktliste außerhalb der Cloud und ein einseitiges Vorgehenspapier sind Arbeit von Stunden. Der Nutzen zeigt sich am Tag, an dem niemand mehr an sein Postfach kommt.
FAQ zum Microsoft 365 Ausfall
Nein. Microsoft nennt als Ursache einen Fehler in einer zentralen Authentifizierungskomponente, nicht einen Angriff. Hinweise auf unbefugten Zugriff im Zusammenhang mit dem Vorfall sind bislang nicht bekannt.
Nein. Die Störung lag vollständig in der Cloud-Infrastruktur von Microsoft. Weder ein Neustart noch eine Änderung an der eigenen Konfiguration hätte geholfen. Wirksam ist ausschließlich die Vorbereitung auf den Ausfalltag.
Nach bisherigem Stand nicht. Sendende Mailserver wiederholen die Zustellung über einen längeren Zeitraum, weshalb die Nachrichten nach der Entstörung verzögert eingingen. Ein Rückstau im Versand blieb noch am Vormittag des 1. September bestehen.
Der Servicestatus und das Message Center im Microsoft-365-Admin-Center zeigen laufende Vorfälle mit Kennung an, hier EX1464935. Ein Blick dorthin sollte der erste Schritt sein, bevor im eigenen Netz gesucht wird.
Nur eingeschränkt. Ein Backup schützt vor Datenverlust, nicht vor fehlender Verfügbarkeit des Dienstes. Für den lesenden Zugriff während einer Störung eignet sich eine unabhängige E-Mail-Archivierung besser.
Fazit
Der Microsoft 365 Ausfall vom 31. August 2026 hat weltweit gut zwölf Stunden lang Mail, Teams und SharePoint blockiert – ausgelöst nicht durch einen Angriff, sondern durch eine Störung in der zentralen Anmeldeschicht, an der alle diese Dienste hängen. Die Hinweise auf ein abgelaufenes internes Zertifikat sind plausibel, offiziell bestätigt sind sie nicht. Für Unternehmen bleibt die Erkenntnis, dass der Betrieb einer Cloud-Plattform zwar ausgelagert werden kann, die Vorbereitung auf deren Ausfall aber nicht. Wer heute festlegt, worüber im Ernstfall kommuniziert wird und wie lange welcher Prozess stillstehen darf, verkürzt beim nächsten Vorfall vor allem eines: die Zeit, in der niemand weiß, was gerade zu tun ist.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!