Office 365 im Stillstand: Wenn die bequeme Cloud zur Abhängigkeit wird

Am 31. August 2026 gerieten Microsoft 365 und insbesondere Exchange Online weltweit ins Stocken. Was zunächst wie eine Störung des E-Mail-Dienstes Outlook wirkte, erfasste nach Angaben Microsofts auch weitere Bestandteile der Plattform. Für betroffene Organisationen zeigte sich damit erneut die Kehrseite einer stark zentralisierten Cloud: Fallen gemeinsam genutzte Basiskomponenten aus, können mehrere betriebliche Werkzeuge gleichzeitig unerreichbar werden.

Der Ausfall begann bei Exchange Online – und blieb nicht dort

Microsoft führte den Vorfall zunächst unter der Kennung EX1464935. Nach den veröffentlichten Angaben begann die Beeinträchtigung am 31. August gegen 15:08 Uhr UTC, also 17:08 Uhr mitteleuropäischer Sommerzeit. Microsoft bestätigte öffentlich, Berichte über Probleme mit Exchange Online zu untersuchen. Die dokumentierten Symptome waren erheblich: E-Mails wurden verspätet oder gar nicht versendet und empfangen, Anmeldungen schlugen fehl, Suchergebnisse blieben unvollständig und administrative Funktionen waren teilweise nicht erreichbar.

Microsoft beschrieb ein gemeinsames Fehlermuster, das mit „authentication and protocol connectivity“ zusammenhing – also mit Authentifizierung und Protokollverbindungen. Später nannte der Konzern als Ursache ein Problem in einer zentralen Authentifizierungskonfiguration, die von mehreren Microsoft-365-Diensten genutzt wurde. Eine zusätzliche Meldung mit der Kennung MO1465074 erfasste die dienstübergreifenden Auswirkungen.

Betroffen waren nach den Statusinformationen neben Exchange Online zeitweise unter anderem Microsoft Teams, OneDrive for Business, SharePoint Online, Microsoft Graph, Purview, Defender XDR, Microsoft 365 Copilot, Universal Print und sogar das Microsoft 365 Admin Center. BleepingComputer dokumentierte den Verlauf und die betroffenen Dienste. Auch das Swiss IT Magazine berichtete über die grossflächige Störung und über zehntausende Meldungen auf Störungsportalen.

Einzelne Berichte führten den Ausfall auf ein möglicherweise abgelaufenes Zertifikat zurück. Diese Erklärung ist jedoch bis zum Stand dieses Artikels nicht offiziell von Microsoft bestätigt. Microsoft blieb bei der allgemeineren Formulierung einer fehlerhaften zentralen Authentifizierungskonfiguration. Eine abschliessende technische Ursachenanalyse lag öffentlich noch nicht vor. Die Zertifikatsthese als gesicherte Ursache darzustellen, wäre daher voreilig.

Stundenlanger Hauptausfall, mehrtägige Nachwirkungen

In der Nacht auf den 1. September setzte eine schrittweise Erholung ein. Damit war der Vorfall aber noch nicht vollständig beendet. Microsoft sprach zunächst von positiven Erholungstendenzen. Am 2. September lag die gemeldete Verfügbarkeit wieder über 99 Prozent, dennoch bestanden bei einzelnen Diensten und Funktionen weiterhin Einschränkungen. Dazu gehörten zeitweise Probleme mit Exchange Online, OneDrive, SharePoint, dem Herunterladen von E-Mail-Anhängen und der Anmeldung an Outlook im Web.

Am 3. September meldete Microsoft die betroffenen Szenarien als behoben; am 4. September wurde auf der öffentlichen Statusseite kein aktiver Vorfall mehr ausgewiesen. Das bedeutet nicht, dass sämtliche Nutzer über drei Tage vollständig arbeitsunfähig waren. Der schwere Hauptausfall dauerte Stunden, die Wiederherstellung und einzelne Restprobleme zogen sich jedoch über mehrere Tage.

Gerade diese Differenzierung ist wichtig: Ein Cloud-Dienst kann für einen Grossteil der Kunden wieder funktionieren und dennoch für einzelne Organisationen, Regionen oder Funktionen weiterhin unbrauchbar sein.

Microsoft erklärt in seiner eigenen Dokumentation, dass Administratoren aktive Störungen und deren Verlauf im Service-Health-Bereich des Admin Centers verfolgen können. Bei diesem Vorfall war allerdings zeitweise auch das Admin Center selbst betroffen. Das macht ein grundsätzliches Problem sichtbar: Wenn Betriebswerkzeug, Statusinformation und administrative Eingriffsmöglichkeiten am selben Anbieter hängen, kann eine Störung nicht nur die Arbeit, sondern auch die Reaktion auf die Störung erschweren. Microsoft beschreibt den Aufbau seines Service-Health-Dashboards hier.

Was bedeutete der Vorfall für die Schweiz?

Die Störung war global und wurde von mehreren Schweizer IT- und Nachrichtenportalen aufgegriffen. ICTkommunikation berichtete von blockierten Anmeldungen, verzögerten oder fehlgeschlagenen E-Mails, eingefrorenen Anwendungen und fehlerhafter Postfachsynchronisation. Auch Nau.ch fasste die weltweiten Auswirkungen und die zugrunde liegende Cloud-Störung zusammen.

Eine verifizierbare, schweizweit aufgeschlüsselte Zahl betroffener Unternehmen oder ein offizieller Schadensbetrag war zum Recherchezeitpunkt jedoch nicht öffentlich verfügbar. Ebenso liessen sich keine belastbaren öffentlichen Angaben finden, mit denen sich konkrete Produktionsausfälle einzelner Schweizer Unternehmen dem Microsoft-Vorfall eindeutig zuordnen liessen. Aussagen wie „die Schweizer Wirtschaft erlitt Schäden in Millionenhöhe“ wären deshalb Spekulation und gehören nicht in eine sachliche Berichterstattung.

Die operativen Folgen für tatsächlich betroffene Schweizer Betriebe lassen sich dennoch aus den bestätigten Funktionen ableiten. Wenn E-Mails nicht versendet werden, bleiben Angebote, Bestellungen, Rechnungen und Supportanfragen liegen. Wenn Kalender und Teams-Funktionen ausfallen, werden Besprechungen und interne Abstimmungen erschwert. Wenn OneDrive oder SharePoint nicht zuverlässig erreichbar sind, fehlt möglicherweise der Zugriff auf gemeinsam bearbeitete Unterlagen. Und wenn dieselbe Plattform auch Identität, Sicherheitsverwaltung und Administration bündelt, trifft ein Fehler nicht mehr nur ein einzelnes Programm.

Für ein kleines oder mittleres Unternehmen können bereits wenige Stunden entscheidend sein. Dabei ist nicht nur die Dauer der Störung relevant, sondern auch der Zeitpunkt: Eine nicht zugestellte Offerte vor einer Frist, ein unerreichbares Vertragsdokument oder eine blockierte Kommunikation mit Kunden lässt sich später nicht immer vollständig nachholen.

Die Schweiz diskutiert längst über digitale Abhängigkeit

Der Ausfall trifft auf eine Debatte, die in der Schweiz bereits geführt wird. Die Bundesverwaltung ist selbst stark von Microsoft-Produkten abhängig und prüft Alternativen. Daniel Markwalder, Delegierter des Bundesrats für die digitale Transformation, erklärte gegenüber SRF, bei einer Verlagerung in die Cloud lägen die Daten nicht mehr bei der Verwaltung, sondern beim Softwareanbieter. Zudem könne der Zugang zu den eigenen Daten aus technischen oder politischen Gründen beeinträchtigt werden.

Sein formuliertes Ziel ist bemerkenswert klar: „eine echte Ausweichlösung zu schaffen und damit unsere Abhängigkeit zu reduzieren.“ Die Bundesverwaltung plant dafür einen erweiterten Praxistest mit Open-Source-Software an 3.000 Arbeitsplätzen. Das vollständige Interview veröffentlichte SRF am 6. September 2026.

Dabei geht es nicht nur um Datenschutz oder den Standort von Rechenzentren. Digitale Souveränität betrifft ebenso die Frage, ob ein Unternehmen seine zentralen Arbeitsmittel weiter nutzen kann, wenn ein Anbieter ausfällt, Bedingungen verändert oder den Zugriff technisch nicht mehr bereitstellen kann. Datenhoheit ohne betriebliche Handlungsfähigkeit bleibt unvollständig.

On-Premises ist kein Rückschritt, sondern eine Frage der Kontrolle

Eigene Infrastruktur wird oft als unbequem oder überholt dargestellt. Tatsächlich bedeutet On-Premises zunächst nur, dass zentrale Systeme auf Infrastruktur betrieben werden, die sich im eigenen Unternehmen oder unter dessen unmittelbarer Kontrolle befindet. E-Mail, Dateiablage, Kalender, Kontakte und Zusammenarbeit müssen nicht zwingend in der Cloud eines globalen Konzerns liegen.

Das heisst nicht, dass ein Server im eigenen Gebäude automatisch ausfallsicher ist. Auch lokale Hardware kann versagen. Stromversorgung, Internetanbindung, Updates, Überwachung, Backups und Wiederherstellungspläne müssen professionell organisiert sein. Wer lediglich einen einzelnen Server aufstellt und auf das Beste hofft, hat noch keine resiliente IT geschaffen.

Der entscheidende Unterschied liegt in der Handlungsfähigkeit. Bei einer Störung der eigenen Infrastruktur können zuständige Techniker Systeme prüfen, Dienste neu starten, Ersatzhardware aktivieren, Sicherungen einspielen oder einen vorbereiteten Notbetrieb einleiten. Fällt dagegen eine zentrale Komponente eines globalen SaaS-Anbieters aus, bleibt Kunden meist nur, Statusmeldungen zu verfolgen und zu warten.

Eine sinnvoll aufgebaute On-Premises-Umgebung kann lokale Datei- und Kommunikationsdienste im Unternehmensnetz verfügbar halten, auch wenn ein externer Cloudanbieter gestört ist. Dazu gehören getrennte Sicherungen, redundante Komponenten, dokumentierte Wiederanlaufverfahren und ein Kommunikationskanal, der nicht von derselben Plattform abhängt wie E-Mail, Meetings und Administration. Je kritischer ein Prozess ist, desto weniger sollte sein Notfallweg dieselbe technische Ursache haben wie der Regelbetrieb.

Bequemlichkeit ist keine Resilienzstrategie

Microsoft 365 bietet zweifellos leistungsfähige Funktionen und reduziert für viele Organisationen den administrativen Aufwand. Der Vorfall vom 31. August zeigt jedoch, dass Grösse, weltweite Rechenzentren und zentrale Verwaltung keine Garantie für ständige Verfügbarkeit sind. Im Gegenteil: Die enge Verbindung zahlreicher Dienste kann die Auswirkungen eines Fehlers vergrössern.

Unternehmen sollten deshalb nicht nur fragen, wie bequem eine Lösung im Alltag ist. Sie sollten auch wissen, wo ihre Daten liegen, welche Dienste voneinander abhängen, wie sie bei einem Ausfall weiterarbeiten und wer dann tatsächlich handeln kann. Die Antwort muss nicht für jede Organisation gleich aussehen. Doch eine Infrastruktur ohne unabhängige Rückfallebene ist keine vollständige Strategie.

Der jüngste Microsoft-Ausfall ist kein Beweis dafür, dass jede Cloud grundsätzlich ungeeignet wäre. Er ist aber ein deutlicher Beleg dafür, dass die vollständige Abhängigkeit von einem einzigen Anbieter ein reales Geschäftsrisiko darstellt. Wer kritische IT wieder stärker unter eigene Kontrolle bringt, entscheidet selbst über Architektur, Sicherungen, Wartung und Wiederherstellung.

Oder kürzer: Die Cloud kann bequem sein. Kontrolle, Resilienz und digitale Souveränität muss ein Unternehmen dennoch selbst gestalten.