The Microsoft outage was not a hack, and that is the problem
The 12 to 14 November 2026 Microsoft 365 outage took down Outlook, Teams and Copilot worldwide for over a day, and Microsoft says a network capacity upgrade, not an attack, was the cause. Why one subprocessor holding your email, calendar and chat is a business continuity risk, what the same-day FAA ground stop says about AI in critical systems, and what an actual continuity plan contains.

By Sam Moreton
Researched
On the evening of Thursday 12 November 2026, Microsoft 365 began failing worldwide, and by Friday morning Outlook, Teams and Copilot were still down for millions of users. CNN was still reporting the outage ongoing at mid-morning Friday; USA Today reported services mostly fixed only after a 24-hour run; the Seattle Times counted two days of trouble before things settled. Mashable, citing a monitoring report, called it the largest outage of 2026. Microsoft apologised, said it was deeply sorry, and gave a cause that should stop every reader mid-sip: a network capacity upgrade. Not an attack. ABC News and USA Today both reported the company saying no hack was suspected, and Yahoo Finance confirmed customer email was not lost.
Sit with the shape of that. The largest outage of the year, the one that emptied inboxes on every continent, happened because a supplier did an upgrade. There was no attacker to defend against, no patch to install, nothing to detect. Which means no security product on earth would have prevented it, and the only thing that determined how bad your Friday was, is the thing this site bangs on about every week: architecture and continuity planning.
What actually broke, everywhere at once
The blast radius is the story. BBC reported governments, courts, trains and hospitals hit across North America; NHS trusts, councils and police affected in England; Politico reported congressional offices paralysed; Bloomberg reported traders going back to phones and fax. An expert quoted in The Independent called it one of the most economically damaging outages in history, and Ars Technica carried the argument that it may have been worse than the Amazon or CrowdStrike events. Global Finance noted cyber insurance policies will now be tested against an incident that was not a cyber event at all.
The Associated Press wrote the sentence this whole piece could have been built around: the outage shows the risks of relying on a single technology provider for essential services. The Financial Times ran the same thesis. The Register called it a crash course in dependence on Redmond.
In procurement language: Microsoft became a single subprocessor for your email, your calendar, your chat, your files and, increasingly, the AI assistant layered across all of them. One change window in one supplier's network touched all five at once, worldwide, for more than a day.
The same day, a different failure mode
Friday 13 November added a second event that looks related and, on the reporting so far, was not. A technical issue grounded every flight in the United States, the day after the Microsoft outage began. The FAA administrator called them separate issues; the DHS secretary said there was no Microsoft link, and that a possible AI role was being investigated, with Business Insider reporting that both Microsoft and the vendor behind the FAA's SMART AI system denied responsibility.
Two details matter for anyone running a business. First, critical systems fail without malice, and they fail on the same day as each other simply because there are so many of them. Second, AI is now inside the critical path of national infrastructure, and when it fails, the investigation starts with what the AI did. We covered the other side of that coin in the PHP2Shell timeline: AI found the flaws in October. It is also increasingly running the systems, and November is when that started reaching front pages.
The month that frames it
Since late October this site has covered, in order: PHP2Shell, two critical remote-code-execution flaws in the language powering most of the web, patched fleet-wide by managed hosts while unmanaged servers queued for packages; the November Apache HTTP/2 vulnerability, where the fix lived entirely below the application layer; and now a capacity upgrade that took the business layer down with no attacker at all. Three different failure classes, one shared structural question. Who applies the fix, who absorbs the outage, and what does your business do in the hours between the two.
A vulnerability punishes unpatched stacks. An outage punishes concentration. Both punish the absence of a plan.
What a continuity plan actually contains
Not a binder. An afternoon and one page per section:
A dependency map. Every system the business needs to operate, the supplier behind it, and the failure mode. Email, identity, file storage, invoicing, the website, the helpdesk. For most businesses this page is shorter than the meeting that will discuss it, and the exercise's value is in the surprises: the realisation that password resets route through the same identity provider as the email, so the outage locks you out of everything else too.
A blast-radius test. For each supplier on the map, the question from this week: what still works if they are down for 24 hours? Anything whose answer is nothing, and which matters, gets either a second supplier or a documented manual workaround. Courts ran on paper Friday. That is a workaround, and it worked because someone had the paper.
An out-of-band channel. One communication path that does not run through the same subprocessor as everything else. If email, chat and identity all live with one supplier, Friday was a silent day for your customers. A second channel on different infrastructure is the cheapest insurance in this list.
Restore drills, not backups. A backup is a claim; a restore you have watched succeed is a fact. The method is written up in how to test a Cloudways restore safely, and the habit generalises: test the restore of something that matters this quarter, not someday.
RTO and RPO decisions, in writing. Recovery time and recovery point objectives per system, decided by the business rather than inherited from whatever the supplier's defaults happen to be. These two numbers are what turn a bad Friday into a survivable one, and writing them down is what surfaces the systems nobody has decided about.
An exit path for crown-jewel data. Not because you will use it this month, but because portability is what converts a 24-hour outage from a hostage situation into an inconvenience. Export formats documented, a rehearsed path to another provider, and the legal right to do it checked against the contract's subprocessor clauses.
On SLA credits, the honest version: they exist, they are small, and they are not the point. A credit refunds a fraction of a subscription that costs tens per seat per month against a day of lost trading. The Register's crash course in dependence is the real invoice.
The hosting footnote, honestly
This site runs one layer below this story, and the same rule applies to us. The managed layer carries the patch burden when deep-stack vulnerabilities land, which the PHP2Shell and Apache HTTP/2 pieces documented. The continuity feature that matters when a provider has a bad week is portability: the ability to move workloads between underlying clouds without a rebuild, which is precisely why our hosting choices weigh it. The Cloudways review covers what that looks like in practice, with the usual disclosure that it carries an affiliate relationship.
The next event on this scale is already scheduled by nobody. The businesses that shrug on Monday will be the ones that had the page written, the channel split and the restore drilled. Everything above costs less than the Friday their competitors just had.
Sources: the multi-outlet reporting of 12 to 14 November 2026, principally the Associated Press on single-provider risk, BBC News on public-service impact, GeekWire and Business Insider on the FAA ground stop investigation, Bloomberg and The Independent on economic impact, and USA Today, CNN and Mashable on the outage timeline.
FAQ
Was the November 2026 Microsoft outage a cyberattack?
No. Microsoft apologised and attributed the disruption to a network capacity upgrade, and multiple outlets reported the company said no hack was suspected. No customer email was lost. That is the point of the piece: a supplier change window produced a global day-plus outage with no attacker involved.
Was the FAA ground stop the same incident?
Reporting says no. The FAA administrator called them separate issues, and the DHS secretary said a possible AI role in the air traffic control failure was being investigated. The two failures shared a day, not a cause.
What is the first thing a small business should do after this week?
Write a one-page dependency map: every system that matters, the supplier behind it, and what stops working if that supplier is down for 24 hours. Then put one out-of-band communication channel on a different supplier. Those two steps cost an afternoon and cover most of the exposure this outage demonstrated.