Outlook down (2026)

Ein abgelaufenes Zertifikat, zwei Tage Ausfall: Was der Microsoft-365-Vorfall vom 31. August über Testmanagement lehrt.

Am 31. August 2026 begann für zahllose Unternehmen weltweit ein ungeplanter Ausfall zentraler Microsoft-365-Dienste, der sich bis in den 1. September zog. Nur zwei Wochen zuvor hatte ein Sicherheitsupdate bereits Teams und Outlook auf bestimmten Geräten lahmgelegt. Zwei Vorfälle, zwei völlig unterschiedliche Ursachen — und doch beide durch strukturiertes Testmanagement vermeidbar.

Das Problem

Ein Authentifizierungszertifikat lief ab, ohne dass die automatisierte Erneuerung rechtzeitig griff — nach Microsofts eigener Beschreibung eine “misconfiguration issue” (EX1464935) in einer zentralen Authentifizierungskonfiguration, die den ordnungsgemäßen Rollout der Authentifizierungskomponenten verhinderte.
Zwei Wochen zuvor erzeugte bereits das Sicherheitsupdate KB5121003 einen Abhängigkeitskonflikt bei paketierten Apps, der Teams und das neue Outlook auf ARM-basierten Windows-11-Geräten (Snapdragon X2, u. a. Surface Pro 11 und Surface Laptop 7) zum Absturz brachte oder den Start verhinderte.

Die Konsequenzen

Betroffene Nutzer verloren direkt nach einem verpflichtenden Sicherheitsupdate Mitte August den Zugriff auf ihre zentralen Kommunikationswerkzeuge; ein manueller Workaround über den Microsoft Store war notwendig, bis eine reguläre Lösung verfügbar war — mit entsprechendem Supportaufwand in betroffenen Unternehmen.
Exchange Online, Outlook, Teams, SharePoint, Copilot, Purview, Defender XDR und das Admin Center waren durch den Incident am 31.08.26 dann über mehr als 24 Stunden weltweit gestört oder nicht erreichbar. Selbst nach der ersten Entwarnung blieben Teilfunktionen wie die E-Mail-Suche noch beeinträchtigt.

Die Lektion

Globaler, mehrstündiger Ausfall zentraler Business-Kommunikation für Millionen Nutzer; Reputationsschaden für Microsoft trotz technisch simpler Ursache.
Ablaufende Zertifikate gehören zu den am einfachsten testbaren Randfällen überhaupt — vorausgesetzt, der Erneuerungsprozess selbst wird regelmäßig gegen reale Ablaufdaten getestet, nicht nur die Anwendung im Normalbetrieb. Ein Monitoring, das Zertifikats-Ablaufdaten mit ausreichendem Vorlauf aktiv prüft und den Erneuerungsprozess selbst in Testumgebungen simuliert (statt sich auf “läuft schon automatisch” zu verlassen), hätte diesen Ausfall verhindert. Genau das ist der Kern eines strukturierten Monitoring- & Reporting-Ansatzes.

Beide Fälle zeigen: Nicht jeder Ausfall entsteht durch einen komplexen Code-Bug. Manchmal sind es Betriebsprozesse (Zertifikatserneuerung oder Sicherheitsupdates), die nie unter realistischen Bedingungen getestet wurden; manchmal eine Testmatrix, die eine ganze Geräteklasse schlicht nicht abdeckt. In beiden Fällen hätte ein strukturierter, auf den Betrieb ausgeweiteter Testansatz die Lücke vorab sichtbar gemacht.

https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-online-outage-causes-email-failures-auth-issues
https://cybersecuritynews.com/microsoft-teams-outlook-crashes/

Bereit, Ihre Testprozesse zu verbessern?

Hinterlassen Sie Ihre Mailadresse mit Ihrem Anliegen und wir vereinbaren gemeinsam ein kostenloses Erstgespräch

Nach oben scrollen