Exchange Online Outage Tied to an Expired Certificate
A Microsoft 365 outage on August 31, 2026 broke Outlook and Exchange Online logins for hours. Leaked error logs point to an expired certificate as the cause.
On the evening of August 31, 2026, Outlook users across North America started seeing a version of the same message: “Something went wrong.” Webmail wouldn’t load. Desktop clients stopped syncing. Admins trying to look up affected mailboxes in the Microsoft 365 admin center hit dead ends of their own. Microsoft confirmed the incident under tracking ID EX1464935 at 5:30 PM UTC, and it didn’t stay contained to email for long.
What happened
Microsoft’s own status updates described the cause in vague terms: a “common failure pattern” affecting authentication and protocol connectivity for Exchange Online. That’s the kind of language companies use when they know something broke but aren’t ready to say exactly what. Customers found a more specific answer on their own.
A reader of the Born’s Tech and Windows World blog who was troubleshooting the outage for clients ran into an error while trying to make changes in a tenant through the Exchange admin API. The response included this line, buried in the JSON: “The cert with thumbprint 19F04B8A233DD9CE916F118056D224A1751729EA is expired.” That single field did more to explain the outage than anything in Microsoft’s public updates.
To be clear about the sourcing here: Microsoft has not officially confirmed that an expired certificate caused the outage. The evidence is a leaked internal error message, not a root cause analysis. But it lines up with what admins were seeing, and it’s consistent with how these things usually play out. An internal service-to-service certificate expires, whatever monitoring was supposed to catch it doesn’t fire or gets ignored, and a piece of infrastructure millions of people depend on grinds to a halt over a date field nobody checked.
The outage didn’t stay confined to Exchange Online. Microsoft’s admin center eventually rolled it into a broader incident that also covered Teams, SharePoint Online, OneDrive for Business, Microsoft Purview, and Defender XDR. Downdetector logged tens of thousands of reports. OpenAI, which relies on Microsoft’s Azure infrastructure, reported its own ChatGPT outage around the same window, though Microsoft hasn’t drawn a direct line between the two.
Why it matters
This is Microsoft, a company with more certificate management tooling and internal automation than almost anyone else running infrastructure at this scale. If an expired cert can still knock out Exchange Online, Teams, and SharePoint at once, it says something about how certificate expiration keeps failing in the same way: not because the technology is hard, but because the process for tracking thousands of internal certificates across a sprawling environment has more gaps than anyone wants to admit.
It also lands at an awkward moment. The CA/Browser Forum’s shift to 200-day maximum certificate validity took effect in March 2026, and the industry has been bracing for an October wave of expirations as the first batch of those shorter-lived certificates comes due. A story like this, even an internal one at Microsoft, is a preview of what happens when renewal cadence increases and tracking doesn’t keep pace.
What actually failed
Exchange Online authenticates a lot of moving parts behind the scenes: client connections, admin API calls, service-to-service calls between Exchange, Teams, and SharePoint. Many of these rely on internal TLS or signing certificates that never touch a public CA and never show up in an external certificate transparency log. That makes them invisible to third-party monitoring. If a public-facing certificate on outlook.office.com expired, an external checker would catch it in minutes. An internal certificate securing an authentication backend can expire without anyone outside the company noticing until the errors start.
Certificate monitoring that only watches your public-facing domains misses exactly the certificates most likely to cause a cascading outage. Nobody put them on a dashboard because nobody thought of them as certificates that mattered.
What to check on your end
You don’t run Exchange Online’s backend, but the same failure mode applies to your own infrastructure. A few things worth checking after a story like this: internal service certificates used for API authentication, mTLS between microservices, and certificates embedded in automation scripts or CI/CD pipelines. These are exactly the certificates that tend to get set up once, forgotten, and never added to a renewal calendar because nobody thinks of them as “the website’s certificate.”
If you’re not sure whether your organization has full visibility into every certificate in use, including internal and service-to-service ones, that’s worth a look before your own version of this incident shows up in someone’s error logs.
To avoid becoming the next headline, consider using SSLcalendar.com to get reminders before your certificates expire, public or internal. For deeper TLS health monitoring, SSLboard.com provides full certificate surveying and vulnerability detection across your whole environment.
Sources: Born’s Tech and Windows World: EX1464935: M365 Outage Due to Forgotten Certificate Renewal, BleepingComputer: Microsoft Exchange Online outage causes email failures, auth issues