Microsoft 365 outage, August 2026: what the SLA pays

On August 31, 2026, Microsoft opened an incident it tracked as EX1464935, later retracked as MO1465074. Microsoft's service health record in the Microsoft 365 admin center, read September 18, 2026, lists a start time of 7:56 AM PDT on August 31, 2026 and an end time of 3:00 AM PDT on September 3, 2026. Earlier reporting had described Microsoft as opening the incident at 5:30 PM UTC — the time coverage reported at the time, not the admin center's own recorded start.

It did not resolve in a day. Attachment-download failures were part of the original incident's impact, and Microsoft's own timeline for it spans a month boundary, closing on September 3. A separate report of Outlook on the web sign-in failures on September 2 was initially logged under the same incident ID while Microsoft investigated — but Microsoft's post-incident report says that symptom was ultimately deemed unrelated: anomaly detection was throttling new traffic patterns from Google Chrome 152, and access was restored once Microsoft reconfigured its systems to let that traffic through.

Ten Microsoft 365 services carried some impact, per Microsoft's own service health record: Microsoft Graph, Exchange Online, Outlook for iOS and Android, the Microsoft 365 Admin Center, Microsoft Purview, Microsoft Defender XDR, Microsoft Teams, Microsoft 365 Copilot, OneDrive for Business and SharePoint Online (grouped under one heading in Microsoft's record), and Universal Print. Microsoft's own Post Incident Report puts a number on how much of the service that actually touched: approximately 5% of the Exchange Online service, on infrastructure in datacenters in North America and Europe, and most customers who received the incident communications likely experienced no noticeable impact.

Microsoft's status updates during the incident, 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.” Microsoft's own admin center record separately listed a “Preliminary root cause” reading: “An issue within a core access configuration used by multiple Microsoft 365 services was resulting in impact.” Both are Microsoft's own words, from different points in the incident, and we keep them here as the record of what was said in real time.

Microsoft's Post Incident Report, published September 10, 2026, gives the final account. A code update to Microsoft's automated certificate management system caused it to stop distributing a subset of new certificates. The defect stayed latent while previously distributed certificates were still valid; once those certificates hit their regularly scheduled expiration, requests relying on them began to fail. Separately, a defect in Microsoft's certificate-expiration monitoring pipeline meant a subset of certificates was not recognized as needing expiration checks, so it was allowed to expire without proper alerting. Microsoft's own unit testing had covered the change, but the report attributes the miss to differences between the test and production environments — its findings table specifically points to differing .NET versions between the two.

Microsoft's report also lists what it is doing about it, on a cadence of monthly progress updates for the next six months. Three items are already marked complete: the certificate-synchronization fix itself, a reusable certificate deployment package for future incidents of this kind, and a fix to the monitoring data source that missed the expiring certificates. Two remain open: closing the gap between test and production environments is targeted for October 2026, and a change so that services reload new certificates without requiring a restart — the step that stretched this incident's recovery across multiple days — is targeted for Q2 2027.

Microsoft's service health record shows a status of “Post-incident report published” for this incident, with an update logged Sep 10, 2026, 5:47 PM PDT (“A post-incident report has been published”). We have since read that report; its account of root cause, scope, and timeline is reflected throughout this page and in the update callout above. Microsoft's report states its contents may not be reproduced without its permission, so what follows here is our paraphrase, with short quotations only where the exact wording carries the claim.

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.

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.

There is one detail in Microsoft's own report worth sitting with for a different reason: the root failure was a certificate that expired without proper alerting, because a defect in Microsoft's own monitoring pipeline missed it. That is the same failure class a mid-market IT function is expected to manage on its own Exchange hybrid infrastructure — we wrote about the on-prem side of that exact problem earlier this year. Microsoft runs certificate rotation at a scale almost no on-prem environment will ever approach, and it still slipped past their own monitoring long enough to cause a multi-day incident. That is not a reason to feel better about your own certificate hygiene. It is a reason to check it.

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 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.

Microsoft's own Post Incident Report adds context worth weighing before you spend the effort reconstructing a timeline: the report scopes the impact to a subset of infrastructure — approximately 5% of the Exchange Online service — and states that most customers who received the incident communications likely experienced no noticeable impact. That is not a reason to skip the check. It is the reason the check matters: whether your tenant has a claim depends on what your own measured uptime shows, not on the fact that an incident with your tenant's name attached to it occurred.

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.

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's own Post Incident Report gives for this incident — a defect inside Microsoft's automated certificate management and monitoring systems — 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.

Update — September 2026: a second Exchange Online incident, four days later

On September 4, 2026, roughly twelve hours after Microsoft declared the August 31 incident resolved, it opened a new one: EX1467029, tracked separately, affecting mail sent to and from external domains in Exchange Online.

Microsoft's published description, as reported by BleepingComputer from the admin center's service health updates, is that the issue "impacts users who may be attempting to send and receive email messages from external domains in Exchange Online. Users may experience intermittent 'Server busy' errors, affecting multiple mailboxes." On cause, Microsoft said only that its "initial investigation has identified instances where anti-spam protections may be contributing to impact for a subset of users" — a different stated factor from the core authentication configuration behind the August 31 event. The incident opened at 2:19 a.m. Eastern; at 10:26 a.m. Eastern Microsoft reported that "telemetry shows that the service is performing as expected for new emails."

One operational detail is worth writing down now, because it decides what your users have to redo. Microsoft's own guidance: "Depending on the client, the service should attempt to periodically retry sending the email previously impacted by the issue. If the initial sender received an NDR after 24-72 hours (different clients or email providers can vary), they will need to send a new email." A retried message is not a delivered message, and a bounce inside that window means somebody re-sends it by hand.

What this changes is not the arithmetic above. It is the frequency assumption underneath it. One multi-service outage is an event you absorb. Two mail-flow failures in four days, under two tracking IDs and two different stated causes, is an operating environment. If you were undecided about whether reconstructing the August 31 timeline was worth the hour, this is the argument for doing it: you will need the same exercise again, and the second one is far cheaper when the first is already written down.

Microsoft has since published a post-incident report for the August 31 incident (MO1465074 / EX1464935) — see the update note near the top of this page. As of this writing, no post-incident review has been published for EX1467029, the September 4 incident described here. A closure statement is not a PIR and should not be described as one.

Update — September 2026: the credit is gated on the vendor's own description of the event

There is a step missing from the section above, and it sits underneath everything else on this page. A service credit is owed when a service falls short of its committed availability. The vendor measures that, the vendor describes it, and the vendor decides what to call it. Your claim is an assertion about an event that the provider has already characterised in public — and if that public characterisation is mild, you are arguing uphill from the first sentence.

This is not hypothetical, and it is not specific to Microsoft. We track the published status pages of the platforms our clients depend on. On September 10, 2026, Zoom posted an incident titled “Service Degradation Affecting Zoom Phone, Zoom Contact Center and Zoom Meetings in Europe” and labelled its own impact none. A degradation affecting telephony and contact centre across a continent, carrying the vendor's lowest severity label. Two further Zoom degradations the same day were also labelled none.

The same week, at another provider, a 25-hour incident was labelled minor while a three-minute incident at the same vendor was labelled major. The labels do not track duration and they do not track how many of your users were stuck. They are the vendor's internal triage vocabulary, published outward, and they are written by the party who would owe you money.

The practical consequence for a claim. Everything this post already tells you to write down — timestamps, affected users, what failed, what you told staff — matters more than it appears to, because it is the only record of the event that is not authored by the counterparty. When the provider's own incident note is thin, understated, or posted retroactively, your internal record is what turns “we had a bad morning” into a claim with a shape. You are not disputing their severity label; you are documenting your own downtime, which is what the agreement actually asks you to do.

Update — September 26, 2026: Microsoft's incident record lags the impact, and disagrees with itself

The section above assumes the vendor's account of an incident is at least internally consistent. It is not always. The clearest example is SP1472983, a SharePoint Online incident unrelated to the outage above. Microsoft's own Service Health text gives a start time of Tuesday, August 25, 2026, at 3:45 PM UTC. Its post-incident report explains why: that is when the change went into production. The report's next timeline entry is Wednesday, September 16, 2026, at 2:51 PM UTC, when Microsoft says it “detected an increase in reports.” The report records nothing in between. That is not three weeks of SharePoint being down for everyone: Microsoft's own scope language says the issue “may have affected any user attempting to load SharePoint Online sites and pages,” with no count given for the period before detection. Plainly: a faulty change sat in production for about three weeks before Microsoft detected it. Users who hit it saw: “Sorry, something went wrong: Thread was being aborted.” Microsoft's stated root cause: “A change intended to improve how links within SharePoint Online pages are processed inadvertently introduced additional service requests when certain pages were loaded.”

Here is the part that matters for your claim evidence. Microsoft's own incident window — the Start and End time written into its update text — covers August 25 to September 16. But the admin center's summary fields for that same incident, the ones that show up first in a history list, cover roughly a 90-minute window on September 16 alone. Same incident ID, same record, two different windows depending on which field you read.

It is not an isolated glitch. Of the nine real incidents we reviewed in Service Health that Microsoft posted between September 15 and 26, four were posted a day or more after Microsoft's own stated start: the SharePoint incident above (about three weeks); an authentication-configuration rollout, MO1479564 (about 4 days 18 hours); call drops on Poly Teams Rooms running Android, TM1477123 (about 4 days 21 hours — posted roughly an hour before Microsoft's own stated end); and a Teams launch-failure incident, TM1473237 (about 26 hours). The rest were posted within minutes to about 90 minutes of their own stated start.

We are not assigning a cause to the detection gap, and this is not a claim about all of Microsoft 365 — it is the incidents we reviewed in Service Health, one tenant's view. What it means for the section above: the vendor's own description of an event, the one your service credit claim has to lean on, is written after the fact, can start counting from days or weeks before anyone was notified, and its own summary fields may not agree with its own update text. Practically: log your own timestamp the first time a user reports a problem, rather than trusting Service Health to have one yet. When you file, use the Start and End time Microsoft writes into its final update text, not the summary fields a history view shows first. And read the final update, not an early one — on these records, the scope and the stated root cause both changed between updates.

Related reading

• The unpatchable side of the same control-plane problem: Entra ID RCE: six CVSS 10.0 CVEs you cannot patch.
• Another Exchange-side deadline worth knowing: Exchange ESU Period 1 expired — your real deadline.
• If licensing cost is also on your radar: Microsoft 365 price increase, July 2026: locking in rates.
• If this outage surfaced a tenant consolidation you have been putting off: Tenant-to-tenant M365 migration playbook.
• Another Exchange Online deadline running the same week: EWS retirement: allow list required from October 10.
• Service detail: Microsoft 365 migration services.

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.
• Microsoft's service health record in the Microsoft 365 admin center, read September 18, 2026 (Issue history for MO1465074 and EX1464935).
• Microsoft's post-incident report for EX1464935/MO1465074, dated September 10, 2026 (downloaded from the Microsoft 365 admin center).

The 30-second version

Microsoft's incident EX1464935 (retracked MO1465074) ran from 7:56 AM PDT August 31, 2026 to 3:00 AM PDT September 3, 2026 — confirmed by Microsoft's own Post Incident Report, which puts the same window at 2:56 PM UTC August 31 to 10:00 AM UTC September 3 (earlier reporting had cited an opening time of 5:30 PM UTC). Ten Microsoft 365 services carried some impact, including Exchange Online, Teams, SharePoint, and — notably — Defender XDR itself, but Microsoft's report scopes the actual impact to about 5% of the Exchange Online service and says most customers who received the incident communications likely saw no noticeable impact. The report's final root cause: a code update stopped Microsoft's certificate management system from distributing a subset of new certificates, the defect stayed hidden until those certificates expired, and a separate monitoring-pipeline defect let a subset of certificates expire without alerting — superseding the “core authentication/access configuration” language reported earlier in the incident. A separate Outlook on the web sign-in report on September 2 was initially logged under the same incident but the report says it was ultimately unrelated, caused by browser-traffic throttling rather than the certificate issue. 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 — and per Microsoft's own report, the incident showing up on your timeline does not by itself mean you were impacted.

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.

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.