The Microsoft 365 outage also hit Defender, Intune and Purview: what to check once service returns

This article is being updated. The incident was still open at the time of writing. Over the coming days we will update it with the impact on Microsoft 365's security services as Microsoft publishes its post-incident report.

For the hours that Microsoft 365 left thousands of users without email, the same platform could not guarantee that mail was being scanned, that devices could be trusted or that the rules on sensitive data were being applied. In many organisations, delivering mail, inspecting it, deciding which devices to trust and watching over data all rest with one provider.

It began on the afternoon of 12 November, Central European Time, with problems reaching Exchange Online mailboxes in the Americas (incident EX1550543). Within minutes a second incident, MO1550821, was warning that users in any region might be unable to connect to several services. The incident record mirrored by the University of Pennsylvania lists Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Microsoft Defender XDR, as does SecurityWeek.

Later updates, as reported by WindowsForum and Cyber Security News, added Defender for Office 365, Intune and several Microsoft Purview functions, including data loss prevention and auto-labelling. By mid-morning on 13 November, Central European Time, Microsoft had yet to declare a full recovery.

Microsoft rules out an attack for now: a spokesperson told ABC News Australia there was no indication of one, and Australia's Home Affairs Minister Tony Burke repeated the message after a briefing from the company. An availability failure still leaves hours in which an organisation sees less and controls less, and those hours should be reviewed as a security incident.

What is known about the cause?

Little is known, and all of it is provisional. Microsoft first cited elevated load across several regions, then corrected itself on its status account: traffic had not risen; a number of servers had dropped out and the rest were carrying their load. Those servers were failing automated health checks. SecurityWeek adds that Microsoft was testing a way around the component that runs those health probes and investigating high processor usage on the affected servers.

Restarting servers, moving traffic and freezing deployments and configuration changes did not do enough. Microsoft later wrote that a core process on the affected servers was becoming overwhelmed. On 13 November, according to ABC News Australia, it reported narrowing down the problem and reverting a recent network change, and shortly afterwards acknowledged that some restored servers stopped responding again once traffic returned.

Microsoft usually sets out the root cause in the post-incident report it publishes in the Microsoft 365 admin centre.

Which security layers were affected?

Three layers need separating, because the risk differs in each.

Prevention on the endpoint

Microsoft Defender for Endpoint's antivirus, attack surface reduction rules and network protection run on the device with the configuration it already had. Nothing published suggests they stopped. What remains unknown is whether cloud-delivered protection, telemetry upload and alert correlation in Defender XDR kept working.

Mail filtering

Exchange Online Protection filters inline, before delivery. During an outage, mail is more likely to be delayed or refused than delivered unscanned. Defender for Office 365 is on the affected list, but Microsoft has not said whether attachment and link analysis suffered or only the console.

Identity and devices

Entra ID does not appear on the affected-service lists in ENow's transcript of the service health notices, and those notices describe connection failures to the workloads rather than authentication failures. There is no record, then, of sign-in, Conditional Access or multi-factor authentication (MFA) being affected.

Intune behaves differently. Conditional Access does not query Intune at each sign-in; it reads the compliance state Intune has written to the device object in Entra ID. If Intune stops evaluating, the last known state stands until the compliance status validity period expires, 30 days by default. Mass lock-out is unlikely. The realistic risk is devices that fell out of compliance during the window (on a Defender for Endpoint risk signal, say) continuing to get access, and new device enrolments failing.

Where should the review start once service returns?

Treat the affected period (the "window" from here on) as time without cloud detection coverage until Microsoft's report says otherwise. Define it using your tenant's service health history, exportable through the Microsoft Graph API: in UTC, from the first notice to confirmed recovery in your region.

Detections no rule ever evaluated

This step is easy to overlook. Microsoft Sentinel's scheduled analytics rules select events by the time they were generated (TimeGenerated) within their lookback period, so an event that arrives later than that lookback is never evaluated by any run. Near-real-time (NRT) rules work on arrival time and suffer less. The query below measures that delay; the 95th percentile shows how long most events took to arrive. Delay per table and hour (UTC; adjust the start time to your tenant's first notice):

union DeviceProcessEvents, EmailEvents, IdentityLogonEvents | where TimeGenerated between (datetime(2026-11-12 16:00) .. now()) | extend Delay = ingestion_time() - TimeGenerated | summarize Events = count(), DelayP95 = percentile(Delay, 95) by Type, bin(TimeGenerated, 1h) | order by Type asc, TimeGenerated asc

Compare volumes with the same hours a week earlier; a low count only means something against that baseline. Then rerun your critical rules manually across the whole window wherever their lookback is shorter than the delay you measured. A SIEM holding non-Microsoft telemetry gives you the cross-check: proxy traffic to newly seen domains, or firewall connections that Defender raised no alert for.

Mail delivered, held or lost

Join EmailEvents with EmailPostDeliveryEvents to see what was delivered during the window, with which verdict, and whether a later action removed it. Zero-hour auto purge (ZAP) is on by default for malware and phishing, but it only acts within 48 hours of delivery: confirm that it did act, and remediate anything beyond that limit by hand from Threat Explorer. Check UrlClickEvents for link clicks in the window, and message trace for non-delivery reports and messages that expired in the queue. Some legitimate mail never arrived, and fake bounce notices can serve as bait.

Data that left unchecked

Email DLP does not apply retroactively, and Purview's activity explorer only shows events that actually happened: if DLP did not evaluate, there is nothing there to find. Review the audit log for sharing activity and anonymous links created, and EmailEvents with EmailAttachmentInfo filtered to external recipients, starting with the users who handle your most sensitive information.

Entra ID sign-in and audit logs

Review Entra ID sign-in and audit logs (authentication method registrations, application consents) and Identity Protection risk detections for the window. For any suspicious account, revoke its sessions: under continuous access evaluation (CAE), tokens can remain valid for up to 28 hours.

Changes made in a hurry

A long outage invites quick fixes: forwarding to personal accounts, Conditional Access exclusions, policies switched off to unblock someone. Search the unified audit log for New-InboxRule, Set-InboxRule and Set-Mailbox with ForwardingSmtpAddress, plus Conditional Access changes; Intune changes sit in Intune's own audit log. Audit latency is not guaranteed and Microsoft has not said whether its pipeline was affected, so repeat the searches after 24 and 48 hours. Every exception needs an owner and a rollback date.

Fraud riding on the outage

ING warned its customers about scammers using the incident as bait, according to ABC News Australia. Messages asking people to sign in again, calls from fake support staff and urgent password-reset requests are the phishing to expect this week. SecurityWeek also notes that Microsoft's monthly security update (Patch Tuesday), two days earlier, fixed an Outlook sender-spoofing flaw Microsoft lists as exploited. It has not been linked to the outage, but it is a good reason to confirm the update is deployed. Remind the service desk that credentials are never reset over the phone without identity verification.

Can a provider outage trigger reporting duties?

It can, even without an attacker. Each entity decides on the basis of its own impact, and the same failure can be major for one and minor for another.

In financial services, DORA classifies ICT-related incidents by their effect regardless of origin, and the entity stays responsible when the fault lies with its provider. Under Delegated Regulation 2024/1772, an incident is major if it affects critical services and crosses at least two materiality thresholds. Two of them fit an outage like this one: duration (an incident lasting more than 24 hours, or more than 2 hours of downtime for an ICT service supporting critical or important functions) and data losses, which include data becoming unavailable.

For a major incident, the initial notification is due within four hours of classification and no later than 24 hours after the entity became aware of it; the intermediate report follows at 72 hours and the final report within a month. In Spain it goes to the Banco de España, the securities regulator (CNMV) or the insurance supervisor (DGSFP) depending on the entity, and clients must be told if their financial interests are affected.

Since 18 November 2025 Microsoft has been one of 19 critical ICT third-party providers designated by the European Supervisory Authorities. The designation brings Microsoft under direct oversight and does not relieve the financial entity of its responsibility.

In their report on 2025, the same authorities counted 3,383 major incidents reported under DORA. Around 29% were caused by an ICT third-party provider failure, and only 10% were cybersecurity-related. The report warns that a single failure at a large provider can generate dozens of related major incidents.

Outside financial services (within them DORA takes precedence), NIS2's definition of an incident includes events that compromise availability, and a significant incident triggers an early warning within 24 hours, a notification within 72 and a final report within a month.

Spain has yet to transpose the directive, as we covered in what to do about NIS2 while Spain's transposition is pending. Spain's National Security Framework (ENS), by contrast, is in force: public bodies and their suppliers must report incidents with significant impact to CCN-CERT, the national government CERT, and availability is one of its security dimensions. Where personal data became inaccessible, the GDPR also calls for an assessment of whether a personal data breach occurred, although a temporary outage will usually not need reporting.

Evidence to preserve

Whatever is not documented this week will be hard to rebuild in a month's time, when an auditor or supervisor asks for it:

• An export of service health with UTC timestamps, the EX1550543 and MO1550821 identifiers and, once published, the post-incident report.
• An internal timeline recording when the organisation became aware, when it classified the incident and every decision with its owner.
• A review of Microsoft's service level agreement: service credits are claimed through the admin centre, within a deadline.
• A record in your information security management system (ISO 27001:2022 controls 5.24 to 5.30) and a review of the impact analysis and recovery objectives for every process that depends on Microsoft 365.

How do you operate without Microsoft 365?

Three checks show whether an incident response plan survives an outage at the provider itself:

• A coordination channel for the security team that relies on neither Teams nor Entra ID accounts, plus a break-glass account excluded from Conditional Access and protected with a FIDO2 hardware key so the tenant can still be administered.
• Security telemetry exported to your own Log Analytics workspace or SIEM through the Defender streaming API or a connector, so investigations do not depend on the Defender portal.
• A list of processes that depend on mail and calendar, with a fallback for each over a full day.

For entities under DORA, testing the ICT business continuity plan and reviewing what happened after a major disruption is an obligation in its own right.

Still unanswered

Still missing are a confirmed root cause, recovery times by region and the answer security teams most need: whether Defender, Intune and Purview stopped processing or merely stopped displaying in the portals. If the post-incident report does not settle it, customers should put that question to Microsoft in writing. The answer will show which Microsoft 365 security checks in this article need strengthening.

The KQL queries and checks are a starting point and must be adapted to each tenant's configuration, licensing and retention. This analysis relies on Microsoft's public communications, its technical documentation and the media coverage cited, with information available on 13 November 2026, while the incident was still open and without a confirmed root cause. The DORA, NIS2, ENS and GDPR references are general guidance and do not replace each entity's legal assessment.