Microsoft 365 Outage Hits 74 Countries, Root Cause Unknown

A Microsoft 365 outage that began on Thursday, November 12, 2026, was still disrupting email, Teams and related services on Friday morning, with reports from 74 countries and no root cause from Microsoft yet. The company tracked the failure as incident MO1550821, a companion to an Exchange Online incident, EX1550543, that its service health data showed starting at 11:17 a.m. Eastern. As of its 6:01 a.m. Eastern update on November 13, Microsoft said recovery actions had finished across parts of its Asia Pacific infrastructure and were being extended to other regions, but some users still had intermittent trouble. Microsoft said it had no evidence of malicious activity.

The affected list grew through the day. Microsoft's incident notice covered Exchange Online, Teams, Microsoft 365 Copilot, SharePoint Online and Microsoft Defender XDR, and CIO reported that Intune, Power BI and several Purview services were added as well. The Guardian, citing Downdetector, counted nearly 130,000 problem reports in 74 countries, while Euronews put reports for Outlook alone at nearly 140,000. Downdetector tallies only users who submit complaints, so neither number measures how many people were affected. For scale, Microsoft puts the audience for its 365 apps above 430 million. The effects spread to others: OpenAI and Anthropic said connectors to Microsoft 365 were disrupted, NHS services in England fell back on paper records, UK police forces asked the public to phone instead of reporting online, and Workhorse, a US electric vehicle maker, postponed an earnings call.

Microsoft's explanation changed as the outage went on. It first pointed to elevated load, then said the load was not caused by a rise in traffic. Instead, many servers had dropped out of service after failing automated health checks, and their work fell onto the machines still running. Later it said a process on the affected servers that sets up encrypted connections was getting swamped, leaving them unable to handle requests. Engineers restarted infrastructure, redirected traffic and reverted a recent network configuration change that coincided with the start of the problem. Servers brought back overnight became unresponsive again once traffic returned, and Microsoft acknowledged that one set of changes was not taking as expected.

The first sign of a durable improvement came in the early hours of Friday. Microsoft reported positive server stability after it patched part of its infrastructure. Its status text described the fix as a patch to an "upstream authentication/routing configuration component." Microsoft then began extending it to regions entering business hours. Charles Lamanna, a Microsoft executive vice president, said the disruption did not look like a cyberattack. To protect delayed mail, the company extended its email timeout window to 48 hours. It also warned that administrators might not be able to open the Microsoft 365 admin center, so it posted updates on its public status page. Microsoft promised a post-incident report with the root cause and repair items after mitigation. None had been published when this article was written, so the cause remains unconfirmed, and outside commentary about misconfigured health checks is inference from Microsoft's own updates.

The incident underscores how a single software-as-a-service provider can become the shared failure point for communication, identity, security monitoring and work itself. For IT auditors and GRC teams, the first question is whether the business continuity plan treats Microsoft 365 as a concentration risk with a tested alternative, rather than a utility assumed to be always on. Plans stored only in SharePoint, call lists kept only in Outlook contacts, and incident bridges that run on Teams all fail together. Reviewers should ask when the organization last ran a drill with the tenant unavailable, and whether customer, regulator and board notifications can go out over channels that do not depend on it. The Bank of England reportedly moved staff email to Teams chats, a workaround the Guardian noted would not help with outside communication.

Visibility during the event deserves its own test. If administrators cannot reach the admin center, who watches the public status page and Microsoft's status account on X, and how is that information passed on? Auditors can check whether emergency administrator accounts and multifactor methods avoid relying on the same service path, since this failure touched an authentication and routing layer. With Defender XDR among the affected services, security teams should record how long detection coverage was degraded and what they used instead. Euronews also noted that outages invite fake support messages, so help desks need a plan for phishing that borrows the incident.

Evidence collected now will matter later. Teams should keep the incident identifiers, status page updates with timestamps, internal tickets, and records of when the organization noticed the problem and who declared an incident. They should also keep a log of manual workarounds, and message traces for mail that was delayed, bounced or lost, because senders' systems may give up before the 48-hour window ends.

Contract and vendor-assurance reviews come next. Confirm the uptime commitment in the Microsoft agreement, how downtime is measured, whether service credits must be claimed and by when, and whether credits are the only remedy. Compare the current SOC 2 report with what happened: check the availability criteria, the stated recovery objectives, any exceptions, and the complementary user entity controls the customer was expected to run. A SOC 2 report describes controls, not guaranteed uptime. Finally, ask critical vendors whether their own email, ticketing and support depend on Microsoft 365, because a provider that cannot be reached during an outage turns a first-party disruption into a third-party one.