Certificate Bugs Behind Microsoft's 67-Hour M365 Outage
Certificate bugs, not a forgotten renewal, caused Microsoft's 67-hour Microsoft 365 outage in August 2026. Here's what the post-incident report means for you.
A week ago the best available explanation for the Microsoft 365 outage was an error string a partner admin pasted into a blog comment section: a certificate thumbprint, and the word “expired.” Microsoft’s own status updates said nothing more specific than “core authentication configuration.” Now the preliminary post-incident report is out, and the actual sequence is more interesting than a missed renewal date.
What the report says
According to Microsoft’s preliminary post-incident report, published September 6, the trigger was a code update rolled out to its internal certificate management system. That update stopped the system distributing a subset of new authentication certificates. Nothing broke at the moment of deployment. The certificates already in place kept working, so the change sat there doing nothing visible.
Then the old certificates started reaching their expiry dates, with no replacements arriving behind them. That is when Exchange Online fell over on August 31.
The second half is the part worth sitting with. Microsoft does run a system that watches certificates for upcoming expiry. A separate bug meant that not every certificate was flagged as requiring expiration validation, so the ones about to expire without replacements were not on the list. The pipeline stopped delivering and the alarm stayed quiet.
The scope
The preliminary report covers Exchange Online, Microsoft Graph, the admin center, Purview, Defender XDR, Teams, 365 Copilot, OneDrive for Business, and SharePoint. Microsoft estimates about 5 percent of the Exchange Online service was affected, which sounds small until you notice how long it took to clear. StatusStack tracked the incident at 66 hours and 52 minutes, from 3:08 PM UTC on August 31 to 10:00 AM UTC on September 3.
Part of that duration was the fix itself refusing to land. Microsoft spent most of the first afternoon reapplying authentication components and restarting infrastructure so the changes would actually take, and at one point was openly considering reverting the update. If the distribution system is the thing that is broken, pushing new certificates through it is not straightforward.
Why this failure mode is worse than a forgotten renewal
A forgotten renewal is embarrassing but legible. Someone owned a certificate, the reminder went to a mailbox nobody reads anymore, the date passed. You fix it by assigning an owner and putting the date somewhere visible.
This was different. Microsoft had automation. The automation was running. It reported no errors. It had simply stopped producing output for one subset of certificates, and the monitoring that should have noticed the gap had a blind spot in exactly the same place.
That is the failure mode worth losing sleep over, because it is the one automation was supposed to eliminate. Teams move from spreadsheets to ACME clients and renewal pipelines and then stop thinking about expiry, on the reasonable assumption that the robot has it. The robot usually does. When it does not, nobody is watching the calendar anymore, because watching the calendar was the job the robot took over.
What to check on your side
Two questions are worth asking about your own setup.
First, does anything verify that your renewal automation produced a certificate, rather than just that it ran without throwing an error? A cron job exiting zero is not evidence that a new certificate exists and is installed. Check the actual expiry date on the endpoint.
Second, is your expiry monitoring built from the same inventory your renewal system uses? If both read from the same list, a certificate missing from that list is invisible twice over. Independent discovery, something that goes and looks at what is actually being served, catches the certificates nobody remembered to register.
This matters more every year now. The CA/Browser Forum’s move to 200-day certificates took effect in March, and the first big wave of those renewals is due in early October. Certificate lifetimes drop to 100 days in March 2027 and 47 days in 2029. More renewals means more chances for a pipeline to fail quietly, and less slack between the failure and the outage.
Microsoft had roughly 200 days of runway on this one and still did not see it coming. Nobody else gets to feel smug.
To avoid becoming the next headline, consider using SSLcalendar.com to get reminders before your certificates expire, independent of whatever automation is meant to renew them. For deeper TLS health monitoring, SSLboard.com provides certificate surveying and vulnerability detection across your environment.
Sources: Tech Jacks Solutions: Exchange Online Authentication Failure Disrupts Global Email, StatusStack: You Can’t Debug Microsoft 365 From Microsoft 365, Born’s Tech and Windows World: EX1464935, Messageware: Microsoft 365 Outage, Exchange, Teams & SharePoint hit by Authentication failure