Der weltweite Ausfall von Microsoft-Diensten am 12. und 13. November 2026 beeinträchtigt Unternehmen, Behörden und öffentliche Einrichtungen. Der Vorfall wirft grundlegende Fragen zur Widerstandsfähigkeit digitaler Geschäftsprozesse auf. Denn Cloud-Verfügbarkeit und unternehmerische Resilienz sind keineswegs dasselbe.
Für Millionen Beschäftigte gehören Outlook, Teams, SharePoint und weitere Microsoft-365-Anwendungen zur selbstverständlichen Arbeitsumgebung. E-Mails, Besprechungen, Dokumente, Aufgaben und zunehmend auch KI-gestützte Arbeitsabläufe werden über eine gemeinsame Plattform abgewickelt. Solange diese funktioniert, fällt die weitreichende technische Integration kaum auf.
Der aktuelle Ausfall verändert diese Perspektive. Seit Donnerstag, dem 12. November 2026, kämpfen Nutzer weltweit mit erheblichen Einschränkungen. E-Mails können nicht abgerufen oder versendet werden, Kalenderfunktionen versagen, Anwendungen reagieren nicht oder lassen sich nur eingeschränkt nutzen. Auch Sicherheits- und Verwaltungsfunktionen sind betroffen.
Microsoft arbeitet an der Wiederherstellung. Doch die Störung macht eine strukturelle Schwachstelle vieler Digitalisierungsstrategien sichtbar: Unternehmen haben wesentliche Teile ihrer operativen Handlungsfähigkeit von einer Plattform abhängig gemacht, ohne deren vollständigen oder teilweisen Ausfall immer ausreichend in ihrer Notfallvorsorge zu berücksichtigen.
Eine Störung mit weltweiten Auswirkungen
Nach den von Microsoft veröffentlichten Incident-Daten begann die Beeinträchtigung von Exchange Online am 12. November um 17:17 Uhr mitteleuropäischer Zeit. Die übergreifende Microsoft-365-Störung wurde ab 19:26 Uhr als eigener Vorfall geführt.
Zunächst standen insbesondere Zugriffsprobleme auf Exchange-Online-Postfächer im Vordergrund. Im weiteren Verlauf wurde deutlich, dass zahlreiche miteinander verbundene Microsoft-Dienste betroffen waren.
Auf der Störungsplattform Downdetector gingen zeitweise rund 130.000 Meldungen zu Outlook-Problemen ein. Innerhalb kurzer Zeit registrierte der Dienst Störungen aus 74 Ländern und Regionen. Diese Zahlen beschreiben Nutzerberichte, nicht die tatsächliche Gesamtzahl betroffener Personen oder Unternehmen.
Die Auswirkungen beschränkten sich keineswegs auf die Bürokommunikation.
In Großbritannien kam es unter anderem zu Einschränkungen bei polizeilichen Online-Meldesystemen und Verzögerungen im Gesundheitswesen. Ein Gerichtsverfahren in Manchester musste unterbrochen werden. Regierungsstellen in Norwegen, Griechenland, Singapur und Japan berichteten ebenfalls über Beeinträchtigungen.
In der Wirtschaft konnten Unternehmen teilweise nicht mehr zuverlässig mit Kunden kommunizieren. Der US-Nutzfahrzeughersteller Workhorse Group verschob eine Veranstaltung zur Veröffentlichung seiner Geschäftszahlen. Auch Verbindungen zwischen KI-Anwendungen von OpenAI beziehungsweise Anthropic und Microsoft-365-Diensten waren betroffen.
Diese Beispiele verdeutlichen, wie schnell eine technische Dienststörung weit außerhalb des eigentlichen IT-Betriebs wirksam werden kann.
Zum Redaktionsstand am späten Nachmittag des 13. November meldet Microsoft eine fortschreitende Stabilisierung. Die E-Mail-Warteschlangen haben sich deutlich reduziert. Dennoch können weiterhin sporadische Zugriffsprobleme und Zustellverzögerungen auftreten.
Was über die technische Ursache bekannt ist
Microsofts bisherige Angaben lassen erkennen, dass Teile der betroffenen Serverinfrastruktur unter erhöhter Last standen. Ein zentraler Prozess auf betroffenen Systemen wurde nach Angaben des Unternehmens überlastet. Server reagierten daraufhin nicht mehr, wodurch weitere Verarbeitungskapazität verloren ging.
Die Wiederherstellung gestaltete sich zunächst schwierig. Neu gestartete Systeme wurden teilweise erneut instabil, sobald sie wieder regulären Datenverkehr verarbeiten mussten. Microsoft untersuchte deshalb Verkehrsverteilung und Kapazitätsengpässe und versuchte, betroffene Infrastruktur schrittweise wieder in Betrieb zu nehmen.
Im weiteren Verlauf meldete das Unternehmen positive Ergebnisse nach Anpassungen beziehungsweise einem Patch an einer vorgelagerten Authentifizierungs- und Routing-Konfigurationskomponente. Gleichzeitig wurden zusätzliche Kapazitäten bereitgestellt und Datenströme neu verteilt.
Wichtig ist die Unterscheidung zwischen einer erfolgreichen Gegenmaßnahme und der tatsächlichen Fehlerursache. Aus der Wirksamkeit einer Konfigurationskorrektur lässt sich noch nicht abschließend ableiten, wodurch die Störung ursprünglich ausgelöst wurde.
Microsoft hat bislang keine Hinweise auf böswillige Aktivitäten im Zusammenhang mit dem Vorfall festgestellt. Eine Cyberattacke ist damit nach gegenwärtigem Erkenntnisstand nicht als Ursache belegt. Der angekündigte Post-Incident-Report soll die technische Ursachenanalyse und weitere Verbesserungsmaßnahmen dokumentieren.
Zur Sicherung verzögerter Nachrichten hat Microsoft das Zeitfenster für E-Mail-Zustellversuche auf 48 Stunden verlängert. Damit soll vermieden werden, dass Nachrichten während der Wiederherstellung vorzeitig als unzustellbar behandelt werden. Eine Garantie, dass sämtliche Nachrichten ohne weitere Verzögerungen zugestellt werden, ist dies allerdings nicht.
Die unterschätzte Abhängigkeit innerhalb einer integrierten Plattform
Besonders aufschlussreich ist, welche Dienste von der aktuellen Störung betroffen sind.
Bei Exchange Online geht es um die unmittelbare Verfügbarkeit geschäftlicher E-Mail-Kommunikation. Bei Microsoft Teams funktionieren grundlegende Funktionen teilweise weiterhin, während kalender- und Exchange-abhängige Funktionen beeinträchtigt sind. Auch bei SharePoint bleiben bestimmte Dateizugriffe möglich, obwohl einzelne Integrationen nicht zuverlässig arbeiten.
Darüber hinaus nennt Microsoft Einschränkungen bei Microsoft Graph, Copilot, Planner, Intune sowie verschiedenen Sicherheits- und Compliance-Diensten.
Das ist aus Resilienzperspektive bemerkenswert. Denn diese Anwendungen werden in Unternehmen häufig als unterschiedliche Systeme wahrgenommen, obwohl sie technisch über gemeinsame Plattformkomponenten und Abhängigkeiten miteinander verbunden sind.
Ein Unternehmen kann Outlook für seine Kundenkommunikation, Teams für die Zusammenarbeit, SharePoint für Dokumentation und Microsoft Purview für die Informationssteuerung einsetzen. Organisatorisch erscheinen das als unterschiedliche Funktionen. Technisch können sie jedoch denselben Fehlerdomänen unterliegen.
Besonders kritisch wird diese Abhängigkeit dort, wo Sicherheitsfunktionen selbst betroffen sind.
Microsoft berichtete beispielsweise über Einschränkungen beim Zugriff auf Teile des Defender-XDR-Portals sowie bei Funktionen von Purview, darunter Data Loss Prevention, Klassifizierung und Audit-Suchen.
Daraus folgt nicht, dass sämtliche Sicherheitskontrollen ausgefallen wären. Es bedeutet jedoch, dass bestimmte Fähigkeiten zur Überwachung, Untersuchung und Durchsetzung von Sicherheitsvorgaben zeitweise eingeschränkt sein können.
Für ein Security Operations Center stellt sich damit eine unangenehme Frage: Wie verlässlich kann es einen Sicherheitsvorfall bewerten, wenn die dafür vorgesehenen Überwachungs- und Managementoberflächen selbst nicht erreichbar sind?
Ein zweites Problem entsteht bei der Krisenkommunikation. Werden Alarmierung, Krisenstabsarbeit, Lageinformationen und Entscheidungen ausschließlich über Microsoft 365 organisiert, kann ein solcher Ausfall auch die Fähigkeit beeinträchtigen, den Vorfall koordiniert zu bewältigen.
Hochverfügbarkeit ist nicht gleich Business Continuity
Cloud-Plattformen bieten erhebliche Vorteile. Professionell betriebene Rechenzentren, automatisierte Skalierung, verteilte Infrastruktur und redundante Systeme ermöglichen regelmäßig ein Verfügbarkeitsniveau, das viele Unternehmen mit eigenen Mitteln kaum wirtschaftlich erreichen könnten.
Daraus entsteht allerdings leicht die Erwartung, dass ein Cloud-Dienst grundsätzlich verfügbar sei.
Technische Redundanz schützt vor bestimmten Fehlerbildern. Sie garantiert jedoch nicht, dass alle denkbaren Störungen beherrscht werden.
Wenn ein gemeinsamer Dienst, eine übergreifende Konfiguration oder eine zentrale Plattformkomponente betroffen ist, können auch geografisch verteilte Systeme gleichzeitig ausfallen oder in ihrer Leistungsfähigkeit eingeschränkt werden.
Die entscheidende Frage lautet deshalb nicht allein, wie hoch die vom Anbieter zugesicherte Verfügbarkeit ist. Entscheidend ist, welche Auswirkungen der Ausfall auf die eigene Leistungserbringung hat und wie lange das Unternehmen diese Auswirkungen beherrschen kann.
Ein Service-Level-Agreement beschreibt vertragliche Leistungszusagen. Es ersetzt weder eine Business Impact Analysis noch einen Notfallplan.
Auch eine mögliche finanzielle Gutschrift wegen einer unterschrittenen Verfügbarkeit kompensiert keine versäumte regulatorische Frist, keinen unterbrochenen Kundenprozess und keinen relevanten Reputationsschaden.
Die Verantwortung für die Fortführung der eigenen Geschäftsprozesse bleibt beim Unternehmen.
Was der Vorfall über unternehmerische Resilienz aussagt
Der Microsoft-Ausfall ist zunächst ein technischer Betriebszwischenfall. Ob daraus für ein einzelnes Unternehmen ein Notfall oder eine Krise entsteht, hängt von dessen konkreten Abhängigkeiten und den daraus resultierenden Auswirkungen ab.
Ein Unternehmen, dessen Beschäftigte für einige Stunden keine E-Mails empfangen, kann den Betrieb möglicherweise mit geringen Einschränkungen fortführen.
Anders sieht es aus, wenn über dieselbe Plattform zeitkritische Kundenaufträge eingehen, Produktionsfreigaben abgestimmt, medizinische Leistungen koordiniert oder rechtlich relevante Mitteilungen verarbeitet werden.
Die Kritikalität liegt nicht im Produkt Outlook. Sie liegt im Geschäftsprozess, der auf die Verfügbarkeit von Outlook angewiesen ist.
Genau hier setzt ein wirksames Business Continuity Management an.
Der BSI-Standard 200-4 sieht vor, zeitkritische Geschäftsprozesse, ihre Ressourcen und Abhängigkeiten systematisch zu betrachten und darauf aufbauend geeignete Strategien zur Geschäftsfortführung zu entwickeln.
Für den vorliegenden Fall bedeutet das insbesondere, die tatsächlichen Abhängigkeiten von Microsoft 365 zu kennen. Nicht allein auf Ebene einzelner Softwareprodukte, sondern über die gesamten Prozessketten hinweg.
Dazu gehören auch Schnittstellen zu Drittsystemen, automatisierte Workflows, Identitätsdienste und die Frage, ob alternative Verfahren im Ereignisfall tatsächlich unabhängig funktionieren.
Eine zweite Microsoft-365-Anwendung ist kein belastbarer Notbetrieb für die erste, wenn beide denselben beeinträchtigten Plattformdienst benötigen.
Dasselbe gilt für Notfallhandbücher, die ausschließlich in SharePoint liegen, oder Alarmierungsketten, deren einzige Kommunikationswege Outlook und Teams sind.
Business Continuity braucht funktionierende Alternativen
Die naheliegende Reaktion auf einen derartigen Vorfall wäre die Forderung nach mehreren Cloud-Anbietern. Eine pauschale Multi-Cloud-Strategie löst das Problem jedoch nicht automatisch.
Vollständige Redundanz geschäftlicher Kommunikations- und Kollaborationsplattformen ist technisch aufwendig und verursacht laufende Kosten. Identitäten, Kalender, Berechtigungen, Datenhaltung und Compliance-Anforderungen lassen sich nicht ohne Weiteres synchron und unabhängig betreiben.
Notwendig ist deshalb eine risikoorientierte Betrachtung.
Für viele Unternehmen dürfte es zunächst wesentlich wirksamer sein, die Fortführung ausgewählter kritischer Prozesse abzusichern, statt ihre gesamte Office-Infrastruktur zu duplizieren.
Dazu gehört eine unabhängig verfügbare Krisenkommunikation, die auch ohne Microsoft 365 funktioniert. Kritische Kontaktinformationen, Alarmierungswege, Entscheidungsbefugnisse und Notfallanweisungen müssen außerhalb der möglicherweise betroffenen Plattform zugänglich sein.
Für besonders zeitkritische Kommunikationsprozesse kann ein vorbereiteter alternativer E-Mail- oder Nachrichtendienst sinnvoll sein. Seine technische Unabhängigkeit und seine datenschutzrechtliche Zulässigkeit müssen allerdings vor dem Ereignis geklärt werden.
Weitere Möglichkeiten bestehen darin, notwendige Informationen kontrolliert offline vorzuhalten und für ausgewählte Geschäftsprozesse manuelle oder teilautomatisierte Ersatzverfahren vorzubereiten.
Entscheidend ist nicht, dass der Ersatzbetrieb sämtliche Komfortfunktionen bereitstellt. Er muss diejenigen Leistungen ermöglichen, deren Unterbrechung für das Unternehmen nicht tragbar wäre.
Dabei ist ein weiterer Unterschied zu beachten: Ein Backup schützt primär vor Datenverlust und ermöglicht Wiederherstellung. Es macht einen ausgefallenen Cloud-Dienst nicht automatisch wieder erreichbar.
Datenverfügbarkeit, technische Wiederherstellbarkeit und operative Geschäftsfortführung müssen deshalb getrennt bewertet werden.
NIS-2 und DORA machen die Fragestellung verbindlicher
Die regulatorische Entwicklung verstärkt die Bedeutung dieser Betrachtung.
Artikel 21 der europäischen NIS-2-Richtlinie nennt ausdrücklich Maßnahmen zur Aufrechterhaltung des Betriebs, einschließlich Backup-Management, Wiederherstellung nach Notfällen und Krisenmanagement. Auch die Sicherheit von Lieferketten und Dienstleisterbeziehungen gehört dazu.
Für Finanzunternehmen konkretisiert DORA die Anforderungen an digitale operationelle Resilienz. Dazu gehören die Analyse kritischer Abhängigkeiten von IKT-Drittdienstleistern, Business-Continuity- und Wiederherstellungsmaßnahmen sowie die Bewertung von Konzentrationsrisiken.
Die Anforderungen sind nicht für jedes Unternehmen identisch anwendbar. Gemeinsam ist ihnen aber ein wesentlicher Gedanke: Die Auslagerung technischer Leistungen beseitigt nicht die Verantwortung für das damit verbundene Betriebsrisiko.
Der aktuelle Microsoft-Ausfall ist dafür ein anschauliches Beispiel.
Unternehmen sollten daher nicht ausschließlich prüfen, ob ihre Cloud-Dienstleister über ausreichende Zertifizierungen, Sicherheitsmaßnahmen und vertragliche Zusicherungen verfügen.
Sie müssen auch beurteilen, was geschieht, wenn der Dienstleister seine Leistung vorübergehend nicht erbringen kann.
Gerade bei marktbeherrschenden Plattformen verdient die Konzentration mehrerer kritischer Unternehmensfunktionen auf gemeinsame technische Komponenten besondere Aufmerksamkeit.
Was Geschäftsführungen und CISOs jetzt überprüfen sollten
Ein Vorfall dieser Größenordnung bietet einen konkreten Anlass, bestehende Annahmen zur eigenen Betriebsfähigkeit zu überprüfen.
Den Ausgangspunkt sollte eine einfache Szenariofrage bilden: Was passiert, wenn Microsoft 365 für 24 oder 48 Stunden nur eingeschränkt zur Verfügung steht?
Die Antwort muss von den betroffenen Fachbereichen kommen und darf nicht auf eine rein technische Einschätzung reduziert werden.
Im Vertrieb geht es möglicherweise um eingehende Kundenanfragen und Angebote. In der Produktion um Abstimmungs- und Freigabeprozesse. Im Personalbereich um zeitkritische Kommunikation. Im Krisenmanagement um Alarmierung, Lageführung und Entscheidungsfähigkeit.
Die Business Impact Analysis sollte solche Abhängigkeiten einschließlich indirekter Auswirkungen berücksichtigen.
Danach müssen die zulässigen Unterbrechungszeiten mit den tatsächlich verfügbaren Notbetriebsverfahren abgeglichen werden.
Besondere Aufmerksamkeit verdienen die gemeinsamen technischen Abhängigkeiten. Es reicht nicht, mehrere Anwendungen als redundant zu betrachten, wenn sie dieselben Identitäts-, Netzwerk-, API- oder Kommunikationsdienste voraussetzen.
Genauso wichtig ist die Prüfung vorhandener Notfallpläne unter realistischen Bedingungen. Eine Stabsrahmenübung oder ein begrenzter Funktionstest, bei dem Outlook, Teams und ausgewählte weitere Microsoft-365-Funktionen als nicht verfügbar angenommen werden, kann sehr schnell organisatorische Schwachstellen offenlegen.
Ein solcher Test sollte auch die Handlungsfähigkeit von IT-Administration und Security Operations umfassen.
Bei aktuell betroffenen Unternehmen steht zunächst die Sicherstellung zeitkritischer Geschäftsprozesse im Vordergrund. Alternative Kontaktwege sollten aktiviert, wichtige Nachrichten über unabhängige Kanäle verifiziert und mögliche Zustellverzögerungen berücksichtigt werden. Das unkontrollierte erneute Versenden von E-Mails kann nach einer Wiederherstellung zu Doppelzustellungen führen.
Darüber hinaus sollten die tatsächlichen Auswirkungen dokumentiert werden. Diese Informationen sind nicht nur für eine mögliche vertragliche Bewertung relevant, sondern liefern wertvolle Grundlagen für die Weiterentwicklung des eigenen BCMS.
Die Verantwortung beginnt dort, wo die Cloud endet
Der gegenwärtige Microsoft-Ausfall ist kein Beleg dafür, dass Cloud-Technologie grundsätzlich unsicher oder ungeeignet wäre. Ebenso wenig lässt sich aus dem Vorfall ableiten, dass der Eigenbetrieb geschäftskritischer Anwendungen zwangsläufig resilienter wäre.
Die entscheidende Schwachstelle entsteht dort, wo hohe technische Verfügbarkeit mit garantierter unternehmerischer Handlungsfähigkeit verwechselt wird.
Unternehmen können ihre IT-Infrastruktur auslagern, die Verantwortung für ihre Geschäftsprozesse jedoch nicht.
Der Ausfall zeigt zudem, dass Resilienz nicht allein durch zusätzliche Sicherheitstechnologie entsteht. Organisation, vorbereitete Ersatzverfahren, klare Verantwortlichkeiten und die Fähigkeit, unter eingeschränkten Bedingungen weiterzuarbeiten, bleiben unverzichtbar.
Eine Geschäftsführung muss nicht im Detail verstehen, wie Microsoft seine Serverinfrastruktur wiederherstellt. Sie sollte aber wissen, welche Leistungen das eigene Unternehmen auch dann noch erbringen kann, wenn diese Wiederherstellung länger dauert als erwartet.
Ein Unternehmen ist nicht deshalb resilient, weil seine Cloud normalerweise funktioniert. Resilient ist es, wenn es auch dann handlungsfähig bleibt, wenn sie es nicht tut.
Quellen und weiterführende Informationen
Microsoft / Incident-Status
- Microsoft Service Health – öffentliche Statusseite
, abgerufen am 13. November 2026.
- Microsoft-365-Incident-Meldungen MO1550821 und EX1550543
, vom University of Pennsylvania IT Service aus dem Microsoft-Administrationsportal veröffentlichte Statusmeldungen.
Berichterstattung zum Vorfall
- Associated Press: Microsoft reports progress in reviving email and other services during a global outage
, 13. November 2026.
- Tagesschau: Weltweite Störungen bei Microsoft-Diensten
, 13. November 2026.
Fachliche und regulatorische Grundlagen
- BSI-Standard 200-4: Business Continuity Management
, Bundesamt für Sicherheit in der Informationstechnik.
- Richtlinie (EU) 2022/2555 – NIS-2, insbesondere Artikel 21
.
- Verordnung (EU) 2022/2554 – DORA
, insbesondere Artikel 11, 12, 28 und 29.
Redaktionsstand: 13. November 2026, später Nachmittag (MEZ). Die technische Ursachenanalyse ist noch nicht abgeschlossen.
