What happened
Microsoft investigated a widespread outage affecting multiple Microsoft 365 services, including Outlook, Teams and Copilot, as users reported connectivity problems worldwide. In a Microsoft 365 admin center advisory tracked as MO1550821, Microsoft confirmed that customers might be unable to connect to Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot and Microsoft Defender XDR.
The scale was large:
- Reuters reported that Microsoft 365, Outlook, Teams and other apps stayed disrupted for thousands of users for more than five hours on Thursday. The outage also hit connectors used by OpenAI's and Anthropic's AI services.
- Downdetector reports of Outlook problems peaked at 138,058 around 1 p.m. ET and had fallen to around 34,490 by evening.
- Microsoft apologized on Friday, with service still being restored nearly 24 hours after the connectivity problems began.
- Microsoft's non-commercial consumer products were affected too, according to a notice on its website.
- Microsoft's status pages listed Exchange Online, Copilot, Planner, SharePoint, To Do, Windows 365, cloud printing and mobile device management among the affected corporate services.
On the cause, reporting points to server availability. Microsoft said earlier in the day that a number of servers were unexpectedly unavailable for the elevated load, rather than traffic having increased. One tracker noted that Microsoft had not published a final root cause by November 13. Treat any firmer explanation as unconfirmed for now. BlackBerry's post says Microsoft has no evidence of malicious activity.
Not every service failed
Reports differ on how much Teams was affected. Al Jazeera said that desktop Outlook might still show emails already downloaded, while Teams chats and calls had largely continued working. One analysis said Microsoft stated that Teams calls, meetings, group chats and channel messages were not affected. That reflects the earlier Teams incident and the broader MO1550821 advisory overlapping. An earlier Thursday Teams incident hit users in North and South America and was attributed to resource contention within Microsoft's infrastructure. The picture was uneven, and it depended on the service and the time.
BlackBerry's claim, and how far it stretches
BlackBerry's Christine Gadsby, its vice president and chief security advisor, wrote that the outage knocked emergency communications and coordination systems offline. The post doesn't say which systems failed or where. I found no independent reporting in my searches that establishes this as a general failure. Read it as BlackBerry's characterization. It does not show that emergency services universally went down. What the outage does show is how many organizations tie sign-in, email, alerts and chat to one vendor.
The post also has a commercial angle. BlackBerry sells secure communications and promotes a downloadable tabletop-exercise guide. Its recommendations are its own, not an industry consensus. The post also doesn't show that any BlackBerry product holds the certifications it lists.
The case for separation
The post does not tell anyone to leave Microsoft 365. It calls the platform highly reliable. Its argument is about separating dependencies:
- Identity: A fallback channel needs verified identities. BlackBerry warns that staff turn to personal email and consumer apps during outages, and that these have no identity checks or records.
- Shared dependencies: A backup fails with the primary if it shares sign-in, admin tools or devices. That includes alerts sent through email or collaboration tools.
- Delivery confirmation: Alerts should reach every channel and device and report back who received them, so leaders can see who is safe.
- Metadata: Secure voice and messaging should also protect who talked to whom, not just message content.
- Multiple routes: Carriers, Wi-Fi, PBX and international networks give redundancy. On-premises or air-gapped alerting can keep working inside an enclave if outside connectivity fails.
- Independent assurance: BlackBerry cites NIAP Common Criteria, the NSA CSfC Components List and FedRAMP authorization as examples. It tells non-US users to check the certifications that apply in their own jurisdiction. These credentials are not interchangeable, and none of them guarantees availability.
What this outage shows about hidden dependencies
Several of the admin-facing effects show how far one outage can spread. Admin-center reporting for this incident also listed Defender for Office 365 Safe Links as potentially unable to verify URLs, which could affect people clicking links in Outlook and Teams. Microsoft Defender XDR was on the list of services customers might be unable to connect to. Exchange Online mailbox access failed through Outlook on the web, desktop Outlook, mobile mail and REST, and email delivery might be delayed.
Together these show how one platform can carry mail, collaboration, security tooling, device management and AI assistants. If your alerting, ticketing, MFA prompts or incident bridge depend on mail or Teams, you may be locked out of the tools you would use to respond. That is an inference from general IT practice, not something BlackBerry or Microsoft said about specific customers.
A practical drill
BlackBerry's starting point is simple, and I'd follow it:
- List the critical workflows that depend on the primary platform. Include the sign-in and admin tools underneath them.
- Run a tabletop exercise that assumes the primary is unavailable for 24 hours.
- Record every step that stalls.
- Ask four questions: Is the degraded-mode plan tested? How do you alert staff, and can you confirm receipt? Does the backup share sign-in, admin tools or devices with the primary? How do leaders talk securely?
The following are my own suggestions, not BlackBerry's:
- Keep an out-of-band contact roster stored somewhere that doesn't require your tenant to be up.
- Check whether break-glass admin accounts and MFA recovery paths depend on the affected services.
- Decide in advance who declares degraded mode and over which channel.
- Pick a status source that doesn't depend on email or Teams, and name it in the plan.
- Repeat the drill after any major architecture change.
Bottom line
BlackBerry's post is marketing, and its claim about emergency systems is unverified. Its core advice is still sound: map your communications dependencies and test whether your fallback works when the primary identity, admin or notification path is gone. A final root cause has not been published, and a post-incident report from Microsoft should clarify what failed.