Was Microsoft Defender XDR affected by the outage too?

Yes. Defender XDR was one of the ten Microsoft 365 services Microsoft listed as affected by the same incident. That matters beyond the inconvenience: Defender XDR is the tool a security team would normally use to determine whether a service disruption is an outage or an attack in progress, and it was degraded at the same time as the services it would otherwise be watching.

Can I get a service credit for the August 2026 Microsoft 365 outage?

Possibly, depending on measured uptime in your own tenant during the incident — something neither we nor you know without pulling it from Microsoft. Microsoft's SLA for Volume Licensing customers (Service Level Agreement for Microsoft Online Services, September 1, 2026 edition) defines Exchange Online Downtime as any period when users cannot send or receive email via Outlook Web Access, and sets credit tiers based on your tenant's Uptime Percentage for the affected month: below 99.9% pays 25% of that month's fees for the service, below 99% pays 50%, and below 95% pays 100%. A separate service level covers average email delivery time, with its own tiers. Whether either tier applies to your tenant depends on data Microsoft holds, not on the fact that an outage occurred.

How much is a Microsoft 365 service credit actually worth?

Less than most people assume, and only for a single month. Microsoft's SLA defines the credit as a percentage of "Applicable Service Fees" — fees actually paid for that Service, applied to the Applicable Period, which for most services is the calendar month in which the credit is owed. A 25% credit is 25% of one month's fee for the affected service, not 25% of an annual contract. The SLA also states plainly that "Service Credits are your sole and exclusive remedy for any performance or availability issues for any Service under the Agreement and this SLA," and that a customer "may not unilaterally offset" fees. There is no path in this SLA to recovering business losses from downtime — only a credit against the fee for the service that fell short.

If an outage affects multiple Microsoft 365 services, can I file multiple service credit claims?

It depends on how you bought, and you may not automatically be in the position to do it. Microsoft's SLA states that if a customer purchased more than one Service "not as a suite," claims may be submitted as if each Service were covered by an individual SLA — its example being Exchange Online and SharePoint Online purchased separately, which could yield two separate credits. A customer on a Microsoft 365 E3 or E5 suite license is not automatically in that position, because the suite is one purchased Service, not several. The SLA also caps a single Incident hitting more than one Service Level for the same Service: you have to pick one Service Level to claim under, even if the incident both blocked availability and delayed delivery. Check how your organization actually purchased its licensing before assuming multiple claims are available.

What is the deadline to file a Microsoft 365 service credit claim for the August 2026 outage, and who do I file it with?

Microsoft's SLA states claims for most services must be received "by the end of the Applicable Period following the month in which the Incident occurred," and gives a worked example: an incident on February 15 has a claim deadline of March 31. The August 2026 outage began August 31 and, under a single incident ID, ran into September. Applying Microsoft's own worked example conservatively, the deadline to file is September 30, 2026 — treated as the conservative reading rather than a certainty, because the incident straddled a month boundary and Microsoft has not published guidance addressing that specific case. Filing earlier costs nothing; filing after the deadline forfeits the claim entirely. Who you file with depends on how your organization purchased its Microsoft 365 licensing: customers who bought direct or through an Enterprise Agreement generally file with Microsoft, while customers who bought through a reseller, a Cloud Solution Provider partner, or a distributor generally route the claim through that partner instead. Confirm which applies to you before assuming.

Field notes · 10 min read · September 3, 2026

Microsoft 365 outage, August 2026: what the SLA pays

Microsoft's own SLA document defines the claim window as the calendar month following the month an incident occurred. Applied to an incident Microsoft opened at 5:30 PM UTC on August 31, 2026 and kept open into September under the same incident ID, the conservative reading is that a claim needs to reach Microsoft by September 30, 2026. That is a reading of Microsoft's worked example, not a certainty — but filing early costs nothing and filing late costs the whole claim, so treat September 30 as the date that matters.

On August 31, 2026, Microsoft opened an incident it tracked as EX1464935, later retracked as MO1465074. It began at 5:30 PM UTC. Public symptom reports on outage-tracking sites started roughly two hours earlier, around 8:30 a.m. Pacific — that is a different measurement from Microsoft's own incident-open timestamp, not a contradiction of it, and it is worth holding both numbers rather than picking one.

It did not resolve in a day. On September 2, a further symptom appeared — attachment downloads failing, OWA sign-in failures — under the same incident ID. Not a second outage. One incident, spanning a month boundary, with two distinct waves of user-visible symptoms.

Ten Microsoft 365 services carried the impact: Exchange Online, Microsoft Teams, Microsoft Graph, Microsoft Purview, OneDrive for Business, SharePoint Online, the Microsoft 365 Admin Center, Microsoft 365 Copilot, Universal Print, and Microsoft Defender XDR. Microsoft's status updates, as reported by BleepingComputer and Computerworld, described the cause as “an issue within a core authentication configuration used by multiple Microsoft 365 services.” Earlier in the incident, the same reporting quoted Microsoft describing having “isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity.”

No Post-Incident Review has been published as of this writing. Azure's public status history lists exactly one PIR, dated July 23, 2026, unrelated to this incident. Every statement we could source back to Microsoft cites the authentication configuration issue above, and until a PIR is published, that is where the public record stops.

The detail that matters most: your monitoring was inside the blast radius

Most outage writeups stop at the list of affected services. One entry on that list deserves its own sentence: Microsoft Defender XDR was itself degraded during the incident.

Defender XDR is the tool a security operations function uses to answer the first question that matters when something goes dark: is this an outage, or is this an attack dressed up as one? For two days, the instrument you would reach for to answer that question was inside the same failure it would otherwise be diagnosing. A SOC watching sign-in failures and mail delays during this window did not have a fully functioning detection layer to tell them whether they were watching an outage or the early stages of something worse.

That is not a criticism of any specific control. It is a structural fact worth sitting with: when the failure domain includes your monitoring, "check the dashboard" stops being a reliable first move.

Microsoft 365 Outage: What The SLA Actually PaysWatch on YouTube (opens in a new tab)

There is also a 50-second version covering just the credit tiers and the three claim traps (opens in a new tab).

What this proves: the control plane you do not operate

Here is the uncomfortable framing. Patch compliance was green. MFA was enforced. EDR was deployed. None of that mattered, because the failure was not in anything a mid-market IT function controls, patches, or scans. It was in a shared authentication configuration inside services Microsoft operates on your behalf. You were dark for up to two days regardless of how well-run your own environment was.

That is the same shape of problem as the six CVSS 10.0 Entra ID and Azure vulnerabilities Microsoft disclosed in August 2026, just approached from the other direction. That post is about defects you cannot patch because Microsoft already fixed them in a service you do not operate. This one is about an outage you cannot prevent because the failing component is the same kind of service — you hold no lever that would have kept it running. Different mechanism, same lesson: a meaningful share of your risk now sits in a control plane where "we hardened our environment" is not the relevant sentence.

The honest question this outage raises is not "how do we avoid the next Microsoft 365 outage" — there is no answer to that one available to a customer. The honest questions are about your own dependencies: which business processes silently assume mail, Teams, or SharePoint will be available, and what actually happens when they are not for two days. Most mid-market shops have never written that answer down, because it has never been tested this way before.

The part nobody writes about: the service credit

Microsoft's Volume Licensing agreements carry a Service Level Agreement that pays a credit when a covered service falls short of its committed availability. It is a real, contractual mechanism, and almost no coverage of an outage like this one mentions it. The source for everything below is Microsoft's own document, Service Level Agreement for Microsoft Online Services, Volume Licensing, September 1, 2026 edition. Microsoft revises this document monthly — if you are reading this later, confirm you are looking at the current edition, because terms can move.

What a service credit is not. The SLA states plainly: “Service Credits are your sole and exclusive remedy for any performance or availability issues for any Service under the Agreement and this SLA,” and that a customer “may not unilaterally offset your Applicable Service Fees.” There is no path here to recovering business losses from the outage — lost productivity, missed deadlines, a client email that never arrived. The only remedy is a credit against the fee for the service that underperformed. Decide whether the effort is worth it with that ceiling in view, not before it.

What Exchange Online Downtime means, and what it pays

The SLA defines Exchange Online Downtime as “any period of time when users are unable to send or receive email with Outlook Web Access. There is no Scheduled Downtime for this service.” Credit tiers are set against your tenant's measured Uptime Percentage for the affected month: below 99.9% pays a 25% credit, below 99% pays 50%, and below 95% pays 100%. A separate service level covers average email delivery time, with its own tiers: delivery averaging over one minute pays 25%, over four minutes pays 50%, over ten minutes pays 100%.

We do not know, and cannot state, what your tenant's measured Uptime Percentage was during this incident, or what your average delivery time looked like. Neither figure is visible to us or to you without pulling it from Microsoft. Whether any tier applies is a question only your own tenant's data can answer.

The trap: you have to choose one Service Level

This incident's symptom set — OWA sign-in failures and attachment/delivery problems — could plausibly touch both the availability service level and the delivery-time service level for Exchange Online in the same month. Microsoft's SLA closes that door: “In the event that more than one Service Level for a particular Service is not met because of the same Incident, you must choose only one Service Level under which to make a claim based on the Incident.” You do not get to stack both. Decide which one your evidence supports better before filing, because the SLA also limits you to “only one Service Credit” per Service per Applicable Period, absent a specific SLA saying otherwise.

The suite caveat — the easiest thing to get wrong. Microsoft's SLA allows separate credits across multiple services only when they were purchased “not as a suite” — its own example is Exchange Online and SharePoint Online bought individually, which “could be eligible for two separate Service Credits.” Ten Microsoft 365 services were affected by this incident. That does not mean ten claims are available. A customer on a Microsoft 365 E3 or E5 suite license purchased the suite as one Service, not ten separate ones, and is not automatically positioned to file multiple claims the way a customer with separately-purchased standalone services is. Check how your organization actually bought its licensing before assuming the multi-claim path applies to you.

What a claim has to contain

Microsoft's SLA specifies the claim must include: “(i) a detailed description of the Incident; (ii) information regarding the time and duration of downtime; (iii) affected resource names; (iv) the number and location(s) of affected users; and v) a description of errors that occurred during the incident.” And it is explicit about the consequence of missing any of it: “Failure to provide the required information will result in claims being rejected.”

Items (ii) and (iv) are the ones worth flagging. Duration and affected-user count are things only your organization can evidence — help desk ticket timestamps, sign-in logs, user reports by location — and they get harder to reconstruct with every week that passes. That is the actual argument for doing this now rather than "eventually."

The Microsoft 365 SLA claim deadline: September 30, 2026

Microsoft's SLA states: “For claims related to all other Services, we must receive the claim by the end of the Applicable Period following the month in which the Incident occurred. For example, if the Incident occurred on February 15th, we must receive the claim and all required information by March 31st.” Applying that worked example to an incident that opened August 31 and continued under one incident ID into September, the conservative reading is a filing deadline of September 30, 2026. This is a conservative reading of Microsoft's own example, not a stated certainty for this specific incident — Microsoft has not published guidance addressing an incident that straddles a month boundary this way. Filing early costs nothing. Filing after the deadline forfeits the claim. Plan around the earlier date.

Claims that are received are evaluated “typically within forty-five (45) days of receipt.”

The exclusions, and why this incident may not trip them

The Exchange Online availability service level does not apply to downtime caused by: denial of service attacks; Microsoft 365 tenant misconfiguration; network issues outside the Microsoft 365 boundary; exceeding send/receive limits; issues caused by extensions such as tenant custom policies or apps; or third-party-induced incidents such as an ISP or on-premises failure. On the cause Microsoft has stated for this incident — a core authentication configuration issue inside Microsoft's own services — none of the listed exclusions appears to describe it. That is an observation about how the stated cause reads against the exclusion list, not a legal opinion and not a guarantee that any specific claim will be paid.

Who actually files the claim

This depends entirely on how your organization purchased Microsoft 365, and it is worth confirming rather than assuming. A direct or Enterprise Agreement customer generally files with Microsoft. A customer who bought through a reseller, a Cloud Solution Provider, or a distributor generally routes the claim through that partner instead, under the terms of that purchase relationship. Pro IT NW is not a Microsoft CSP and does not resell or manage Microsoft licensing, so we are not the party either of those paths runs through — but assembling the incident evidence a claim requires is work we can help with regardless of who ends up filing it.

Write this down now, while it is still reconstructable

Whether or not your organization ultimately files a claim, four things are worth capturing well before the September 30, 2026 filing date, and before the incident window fades from anyone's memory or gets overwritten by help desk ticket rotation:

Timestamps of the first and last user reports of a symptom, cross-checked against help desk tickets, not memory.
A rough count and location breakdown of affected users — the number Microsoft's claim form explicitly asks for.
Screenshots or logs of the actual errors users saw, tied to a timestamp.
How your organization purchased Microsoft 365 — direct, EA, CSP, or reseller — because that answer determines who the claim even goes to.

What this changes about architecture

Modestly, and honestly: there is no configuration that prevents the next Microsoft-side authentication outage. That is not an answer available to a customer, and claiming otherwise would be marketing, not engineering. What is worth reviewing is narrower and more useful — which business processes assume mail, Teams, or SharePoint availability without a documented fallback, and whether anyone has actually tested what happens when that assumption breaks for two days. Most organizations discover the answer to that question during the outage itself, which is the worst possible time to learn it.

Sources and further reading

Microsoft, Service Level Agreement for Microsoft Online Services, Volume Licensing, September 1, 2026 edition. This document is revised monthly by Microsoft; confirm you are reading the current edition before relying on any figure in it.
Reporting on Microsoft's status updates for incident EX1464935 / MO1465074, via BleepingComputer.
Reporting on Microsoft's status updates for the same incident, via Computerworld.

The 30-second version

Microsoft's incident EX1464935 (retracked MO1465074) began 5:30 PM UTC August 31, 2026, and ran into September under the same ID, hitting ten Microsoft 365 services including Exchange Online, Teams, SharePoint, and — notably — Defender XDR itself. Microsoft attributes it to a core authentication configuration issue; no Post-Incident Review has been published. Separate from the outage story: Microsoft's Volume Licensing SLA pays a service credit when measured uptime falls short, but it is worth only one month's fee for the affected service, you must choose one Service Level to claim under when an incident trips more than one, a suite license does not automatically unlock multiple per-service claims, and a claim needs specific evidence — duration and affected-user counts chief among them — that only gets harder to reconstruct over time. The conservative filing deadline, based on Microsoft's own worked example, is September 30, 2026. Whether you qualify, and for how much, depends on data in your tenant that neither we nor you have pulled yet.

If you would like help pulling that evidence together, or reviewing what your organization's Microsoft 365 dependencies actually assume about uptime, the project intake form takes about three minutes and gets you scope and a fixed-fee range inside two business days.

Pro IT NW is not a Microsoft CSP and does not resell or manage Microsoft licensing. Nothing in this post is legal or contractual advice; it is a plain-language read of Microsoft's own published SLA terms. Whether a service credit applies to your organization, and in what amount, depends on your specific licensing agreement, how you purchased Microsoft 365, and measured uptime data in your tenant that we have not seen. Confirm terms against the current edition of Microsoft's SLA and consult your own contract before filing a claim.

Questions we get asked

What was the August 2026 Microsoft 365 outage, and is it over?: Microsoft tracked the incident as EX1464935, later retracked as MO1465074. It began at 5:30 PM UTC on August 31, 2026, and affected ten Microsoft 365 services: Exchange Online, Microsoft Teams, Microsoft Graph, Microsoft Purview, OneDrive for Business, SharePoint Online, the Microsoft 365 Admin Center, Microsoft 365 Copilot, Universal Print, and Microsoft Defender XDR. On September 2, a further symptom — attachment downloads failing and OWA sign-in failures — appeared under the same incident ID, not a new one. As of this writing, Microsoft has not published a Post-Incident Review; Azure's public status history lists exactly one PIR, from July 23, 2026, unrelated to this event.
What did Microsoft say caused the outage?: Microsoft's status updates, as reported by BleepingComputer and Computerworld, described the root cause as "an issue within a core authentication configuration used by multiple Microsoft 365 services." Earlier in the incident, the same reporting quoted Microsoft as saying it had "isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity." That authentication-configuration language is the only cause Microsoft has stated. No Post-Incident Review has been published as of this writing to elaborate on it further, and until one is, that is where the public record stops.
Was Microsoft Defender XDR affected by the outage too?: Yes. Defender XDR was one of the ten Microsoft 365 services Microsoft listed as affected by the same incident. That matters beyond the inconvenience: Defender XDR is the tool a security team would normally use to determine whether a service disruption is an outage or an attack in progress, and it was degraded at the same time as the services it would otherwise be watching.
Can I get a service credit for the August 2026 Microsoft 365 outage?: Possibly, depending on measured uptime in your own tenant during the incident — something neither we nor you know without pulling it from Microsoft. Microsoft's SLA for Volume Licensing customers (Service Level Agreement for Microsoft Online Services, September 1, 2026 edition) defines Exchange Online Downtime as any period when users cannot send or receive email via Outlook Web Access, and sets credit tiers based on your tenant's Uptime Percentage for the affected month: below 99.9% pays 25% of that month's fees for the service, below 99% pays 50%, and below 95% pays 100%. A separate service level covers average email delivery time, with its own tiers. Whether either tier applies to your tenant depends on data Microsoft holds, not on the fact that an outage occurred.
How much is a Microsoft 365 service credit actually worth?: Less than most people assume, and only for a single month. Microsoft's SLA defines the credit as a percentage of "Applicable Service Fees" — fees actually paid for that Service, applied to the Applicable Period, which for most services is the calendar month in which the credit is owed. A 25% credit is 25% of one month's fee for the affected service, not 25% of an annual contract. The SLA also states plainly that "Service Credits are your sole and exclusive remedy for any performance or availability issues for any Service under the Agreement and this SLA," and that a customer "may not unilaterally offset" fees. There is no path in this SLA to recovering business losses from downtime — only a credit against the fee for the service that fell short.
If an outage affects multiple Microsoft 365 services, can I file multiple service credit claims?: It depends on how you bought, and you may not automatically be in the position to do it. Microsoft's SLA states that if a customer purchased more than one Service "not as a suite," claims may be submitted as if each Service were covered by an individual SLA — its example being Exchange Online and SharePoint Online purchased separately, which could yield two separate credits. A customer on a Microsoft 365 E3 or E5 suite license is not automatically in that position, because the suite is one purchased Service, not several. The SLA also caps a single Incident hitting more than one Service Level for the same Service: you have to pick one Service Level to claim under, even if the incident both blocked availability and delayed delivery. Check how your organization actually purchased its licensing before assuming multiple claims are available.
What is the deadline to file a Microsoft 365 service credit claim for the August 2026 outage, and who do I file it with?: Microsoft's SLA states claims for most services must be received "by the end of the Applicable Period following the month in which the Incident occurred," and gives a worked example: an incident on February 15 has a claim deadline of March 31. The August 2026 outage began August 31 and, under a single incident ID, ran into September. Applying Microsoft's own worked example conservatively, the deadline to file is September 30, 2026 — treated as the conservative reading rather than a certainty, because the incident straddled a month boundary and Microsoft has not published guidance addressing that specific case. Filing earlier costs nothing; filing after the deadline forfeits the claim entirely. Who you file with depends on how your organization purchased its Microsoft 365 licensing: customers who bought direct or through an Enterprise Agreement generally file with Microsoft, while customers who bought through a reseller, a Cloud Solution Provider partner, or a distributor generally route the claim through that partner instead. Confirm which applies to you before assuming.

Related service

Microsoft 365 migration services

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Share on LinkedIn Follow Pro IT NW