Microsoft 365 outage: DDoS, or its own change? The real risk for security teams

Yesterday afternoon my timeline filled up with "Microsoft, AWS, Gmail, Claude... everything is down" lists. Some ended with lines like "when Microsoft names what knocked those servers out, you'll wish you'd followed me." So I sat down and went through Microsoft's statements and reliable sources. In this post I've collected what's confirmed, the possible causes, and what I see as the real risk in this outage from a security point of view.

At a glance

• The outage began around 1:00pm US Eastern time on November 12 and still wasn't fully resolved on November 13.
• Downdetector showed close to 130,000 Outlook reports and more than 45,000 Microsoft 365 reports in the US alone.
• More than 10 services were affected.
• Microsoft says it sees no sign of malicious activity. The root cause hasn't been announced.

Microsoft's admin center entries are EX1550543 (Exchange Online) and MO1550821 (wider Microsoft 365).

Not just Outlook

In the first hours everyone talked about Outlook, but the list of affected services is much longer:

• Exchange Online and Outlook: no mailbox access on the web or desktop clients.
• Teams, Copilot, Planner, To Do: features tied to Exchange broke.
• SharePoint and OneDrive: files opened, but Exchange-dependent features behaved inconsistently.
• Defender XDR and Purview: security and compliance tools are on the list too.
• Sign-in, Azure and Microsoft Store: sign-in problems in some regions and user reports, but Microsoft hasn't separately confirmed these.

For me the most striking part of the list is Defender XDR and Purview. I'll come back to that below.

What happened?

1. Mailbox access was lost first in the Americas. Shortly after, Microsoft said any region could be affected.
2. Microsoft paused all deployments, moved traffic off the affected infrastructure and restarted servers.
3. Restarted servers stopped responding again once traffic returned, which is why recovery took longer than expected.
4. Microsoft began rolling back a network config change that lines up with when the outage started.
5. Temporary traffic throttling was applied in some locations. As of November 13 recovery was partial, and Microsoft hadn't given a time for full recovery.

What happened technically?

Putting Microsoft's statements together, the chain looks like this:

1. Loss of capacity. A large number of servers became unexpectedly unavailable, and the load shifted onto the servers still up. There was no traffic surge from outside.
2. A choke on the TLS side. On the affected servers, a process responsible for establishing secure connections became overwhelmed and stopped processing requests.
3. Health checks shrinking the pool. Servers failed automated health checks and were pulled from the pool. As the pool shrank, the remaining servers took even more load. That's a classic cascading failure.
4. The fix creating new load. According to Microsoft, the mitigations caused a surge of calls from routing services to backend servers. Some machines stuck in a bad state also blocked the config rollback from syncing.

Microsoft also said it had validated an alternative health check method on a subset of servers and was rolling it out more broadly.

Is it a DDoS?

Nothing so far points to a DDoS. I say that for three reasons:

• Microsoft's statement. EVP Charles Lamanna said there was no indication of malicious or cyber activity. It's worth noting this is Microsoft's own assessment, not an independent finding.
• The symptoms are different. In a DDoS you see an abnormal surge of traffic from outside. Here, servers fail from within, and the ones brought back fall over again when normal traffic arrives.
• Compare with 2023. In the June 2023 Outlook and OneDrive outage, Microsoft openly confirmed a layer 7 DDoS attack by Anonymous Sudan. There's no such statement this time.

So what might have caused it? Two possibilities are being discussed right now:

1. The network config change. The change Microsoft is rolling back lines up with when the outage began. It's the strongest lead, but Microsoft hasn't confirmed it as the cause.
2. A problem in the health check component. Some analyses suggest the component that judges server health may have flagged healthy servers as failing, shrinking the pool for no reason. This is speculation and hasn't been confirmed by Microsoft.

What we know, what we don't

I couldn't find a source confirming the other services on the viral lists. During a big outage, users don't know where the problem is and flag every service they see on Downdetector, so small spikes on unrelated services are normal.

The real risk for security teams: the blind window

Even when an outage isn't an attack, it opens a window of opportunity for attackers. In this one, I think four things stand out.

A visibility gap. Defender XDR and Purview were among the affected services. If your security tools run on the same infrastructure as the cloud they watch, alerts may have been delayed or never arrived during the outage, and audit logs may have been processed late. For an attacker, this is exactly the moment when noise is highest and visibility is lowest.

Phishing and vishing. Attackers watch Downdetector too. After similar outages, lookalike domains and emails titled "Re-verify your Microsoft account" usually show up within 24 to 48 hours. There's a phone version as well: "This is IT calling, we need to reset your password because of the outage." Since users really couldn't sign in, these messages are more convincing than usual.

MFA confusion. A user having sign-in trouble is more likely than usual to approve an unexpected MFA prompt, thinking "the system must be recovering."

Shadow IT. Work doesn't stop when email does. Files may have gone to personal Gmail, WhatsApp or some random file-sharing site.

SOC checklist

1. Hunt back over the outage window. Look at late Defender alerts, Entra ID sign-in logs and the Unified Audit Log. Pay particular attention to hours that look "quiet" during the outage.
2. Warn users about phishing and vishing. Turn on lookalike domain monitoring.
3. Tighten the helpdesk and MFA. Keep identity verification strict on password and MFA reset requests, and over the next few days watch new MFA registrations and unusual spikes in failed sign-ins.
4. Define an out-of-band communication channel. Teams and email can go down at the same time; know in advance where you'll talk during an incident.
5. Map your dependencies. Which of your security tools runs in the same cloud it watches? Which visibility do you lose when that cloud goes down?
6. Follow the incident entries, and don't forget the SLA credit. Watch EX1550543 and MO1550821 in the admin center. For enterprise Microsoft 365 subscriptions, Microsoft commits to 99.9% monthly availability for Exchange Online. If it falls below that, you're entitled to a discount on that service's monthly fee (a service credit): 25% below 99.9%, 50% below 99%, 100% below 95%. In a 30-day month, 99.9% means at most about 43 minutes of downtime; a company whose tenant was affected for more than 24 hours drops to roughly 96.7%, which is the 50% credit tier. The credit isn't automatic; an admin has to open a claim in the admin center, documenting the affected users and the duration. Personal and family subscriptions don't include this.

I'll update this post with the root cause once Microsoft publishes the post-incident report.