It's Not Just You — Microsoft 365 Is Having an Authentication Problem

Microsoft has published its post-incident report, and we can finally answer the question this page has been carrying since September 1.

Closing note — Thursday, September 24, 2026 Microsoft has published its post-incident report, and we can finally answer the question this page has been carrying since September 1. Nobody forgot to renew anything. You may have read that this outage happened because someone at Microsoft let a security certificate expire. A certificate is the digital ID one system uses to prove to another that it really is what it claims to be. They expire on a set date and have to be replaced — and Microsoft replaces thousands of them automatically, across hundreds of thousands of machines, precisely so that no human has to remember. That automation broke. A code update stopped it handing out a subset of new certificates. Nothing failed at that moment, because the ones already installed were still valid. The fault sat there unnoticed until those certificates reached their ordinary expiry date — at which point there was nothing waiting to replace them, and requests started failing. A second thing failed at the same time, and it's the one worth your attention. A separate system watches certificates for approaching expiry, exactly so this can't happen. A defect in how it received its data meant some certificates were never recognised as needing that check. So renewal had silently stopped, and the alarm built to catch that was reading an incomplete list. And the change had been tested. It passed. It passed because the test environment was running a different version of the underlying software framework than the live one — so the fault genuinely could not appear there. The technical part — you can skip this box Microsoft 365 auto-rotates certificates across a partitioned infrastructure. A code update to the automated certificate-management system stopped distribution of a subset of new certificates; unit testing did not catch the regression because of .NET version differences between test and production. Separately, a data pipeline defect meant not all certificates were recognised as requiring expiration validation, so a subset expired without alerting. Impact was confined to roughly 5% of Exchange Online — infrastructure in North America and Europe belonging to customers earliest in the Safe Deployment Procedure rollout. Microsoft Entra was not affected at any point. What that actually means Two independent things had to go wrong together. The robot that replaces certificates stopped replacing a few of them, and the watchdog that was supposed to shout about certificates running out had those particular ones missing from its list. Either one alone would have been caught. Both at once meant the first sign of trouble was customers being unable to get their email. "Entra was not affected" is worth a line, because a lot of people assumed the outage meant Microsoft's login service itself had gone down. It hadn't. The machines were fine and the login service was fine — individual servers simply could no longer prove who they were to each other. What went right, which nobody wrote about. Microsoft ships changes in stages rather than everywhere at once. That is the only reason this hit about 5% of Exchange Online instead of all of it. Detection was quick, too: the first failures were at 2:56 PM UTC and monitoring raised an alert at 3:19 — twenty-three minutes. Expired certificates were identified as the cause by 4:28. The three days that followed weren't spent looking for the problem. They were spent building an emergency way to push certificates out around the broken automation, and then restarting every service that wouldn't pick up a new certificate without being restarted. Microsoft has committed to fixing that last part, though not until 2027. What we'd take from it. Three safeguards — automated renewal, expiry monitoring, pre-release testing — and all three were quietly not doing their job. Nothing looked wrong until the morning it mattered. That pattern does not require hundreds of thousands of machines. It is the backup that runs every night and has never once been restored from. The alert that goes to somebody who left in March. The script that stopped running in June and nobody noticed because it only ever mattered in December. If you rely on something automated, the useful question isn't whether it ran last night. It's who would notice if it stopped. One note on how we covered this. We held off repeating the certificate explanation for three weeks because Microsoft hadn't confirmed it. In fairness, it was broadly right. What waiting bought wasn't being right — it was the mechanism, and the mechanism is the only part you can use. _____ This is over. Microsoft finished restoring services on the morning of Wednesday, September 3. End to end it ran about three days, which is why the note below — written on the Tuesday — still describes a live incident. We've left it in place rather than quietly rewriting it. Nothing was lost. That was true throughout and hasn't changed. What caused it: Microsoft still hasn't said. A week on, the only explanation on record is the one given on day one — "an issue within a core authentication configuration used by multiple Microsoft 365 services." Microsoft said it would publish a preliminary write-up within two business days and a full one within five. Neither has appeared. A word about the certificate story. You may have read that this happened because someone forgot to renew a security certificate. A certificate is the digital ID a system uses to prove it is really itself; they expire on a set date and have to be renewed, and letting one lapse is an ordinary, human mistake that has taken down large services before. That explanation is now nearly everywhere. Microsoft has never given it. It began with a customer posting an error message from their own logs, was picked up, repeated, and somewhere along the way hardened into a fact. It may well turn out to be right. We don't know — and neither do the people writing it down as though they do. When Microsoft publishes its report we'll update this entry either way, including if it turns out the certificate story was correct all along. The part worth keeping. Three days of disruption followed by a week of silence is the ordinary shape of a large cloud failure, not an unusual one. If your plan for a day like August 31 assumes somebody will tell you what broke and when it will be back, it isn't a plan. The businesses that came through last week best didn't have better information than anyone else. They had a way to keep working without it. Update — Tuesday, September 1, 2026, midday Central This is not over yet, though the worst of it is. Email came back late Monday night. Search did not, and as of this morning Microsoft is still restarting the affected infrastructure and re-applying the fix to restore it. There is no estimated time for full resolution. Nothing was lost. This was a failure in the part of Microsoft 365 that checks whether you're allowed in — not the part that stores your files. Nothing was deleted, corrupted or rolled back. Everything that was in your mailbox or your files on Monday morning is still there. What's still broken, and why it looks like several different problems. Search is the piece that hasn't come back, and search sits underneath more things than most people expect. So you may find that Teams shows colleagues as offline when they're at their desks, Copilot can't find a document you know exists, SharePoint or OneDrive search returns nothing, and email queued during the incident is still arriving late. Those look like four separate faults. They're one, and it's Microsoft's, and it is being worked on. Three things worth ten minutes this morning: Anything you saved during the incident — open it and confirm the save actually went through. If a file was open when the connection dropped, the last save may not have reached the server. Print jobs that never printed — Microsoft's print service (Universal Print) was caught up in this. Jobs sent during the incident may still be sitting in a queue that will never move. Send them again rather than waiting. Passwords reset mid-incident — if anyone reset a password while authentication was failing, have them confirm the new one actually works, on every device. The technical part — you can skip this box Microsoft tracked this as EX1464935 in Exchange Online, broadened to MO1465074 as impact spread. Their stated cause: "an issue within a core authentication configuration used by multiple Microsoft 365 services." Recovery involved re-applying a targeted fix to that authentication component and restarting infrastructure associated with search. What that actually means Microsoft 365 has one shared component whose whole job is answering "is this person allowed in?" Email asks it. So do OneDrive, SharePoint, Teams, the admin center and the printing service. Something in that component's settings was wrong, so all of those asked the same question and got no answer. Nobody's data was touched — the door just stopped recognizing anyone. Fixing it meant correcting the setting and then restarting the services that had gotten confused while it was broken, which is why search took longer to come back than email did. Two things not to do today. Don't troubleshoot search — don't rebuild an index, don't re-license anyone, don't reinstall Teams. It isn't yours to fix and you'll only spend the afternoon confirming that. And during an authentication failure, don't reset passwords: bad logins look exactly like a password problem, resetting doesn't help, and it creates real cleanup afterward. When several unrelated services break in the same minute, that is almost never a coincidence and almost never something on your end. One note on wording. We called this a degradation rather than an outage on Monday, because that was Microsoft's own classification and it was the accurate one — partial failures, stale content and timeouts rather than a platform going dark. It isn't a distinction for its own sake: an outage means stop and wait, while a degradation means some things work, retries sometimes succeed, and the useful move is to find what still works and route around the rest. Update — 5:00 PM Central Microsoft is now re-applying the authentication components across affected environments, that recovery is gradual so services will return unevenly, that Universal Print, Teams Rooms devices, desk phones and admin center sign-in have been added to the impact list, that the root cause is confirmed rather than preliminary, and that there's still no ETA with the next update at 7:00 PM Central. If your email has been dropping, Teams has been showing colleagues as away when they're sitting across from you, and OneDrive has been loading half a page, you are not imagining it and there is nothing wrong with your computer. Microsoft confirmed a Microsoft 365 problem beginning at 10:08 AM Central today. Worth being precise about what this is, because it isn't what most people will call it. Microsoft classifies it as service degradation, not an outage, and the distinction matters when you're deciding what to do. A true outage is clean — nothing works, everyone knows, you wait. Degradation is messier. Things work, then fail, then work again. That's what makes people start "fixing" things that were never broken. What's affected Email. Connections to Exchange Online failing or running slowly, by every method — desktop Outlook, the web, phones. Teams. Calendar and search misbehaving. Presence showing stale and refusing to update, even manually. Location changes failing. OneDrive and SharePoint. Pages loading partially, files slow to open or not opening, syncing stalled, phone camera uploads failing, video playback failing. Admin and security tools. Microsoft Purview and Defender are throwing intermittent authorization failures, and administrators can't get into the Purview portal. In the Microsoft 365 admin center, some Exchange administration — things like updating a user's alias — is failing. The technical part — you can skip this box Microsoft's preliminary root cause: "An issue within a core authentication configuration used by multiple Microsoft 365 services is resulting in impact." Remediation is focused on why authentication components aren't deploying as expected, including potentially reverting a recent update to the affected infrastructure. What that actually means Every time you open your email, join a meeting, or open a file, the system quietly asks one question first: is this person allowed to do this? That check is handled by a shared component sitting behind nearly everything in Microsoft 365. That shared component is what's misbehaving. Which explains the strangest part of today — that your email, your files, and your meetings all broke at the same moment in completely different ways. It looks like several problems. It's one problem, showing its face in every room of the house. Microsoft says it's examining recent changes to the service and looking at rolling back an update to the affected infrastructure. The next update is expected at 5:00 PM Central. What we'd actually do Stop troubleshooting your own equipment. This is the important one. Rebooting, reinstalling Office, clearing caches, and rebuilding profiles will not fix a problem inside Microsoft's authentication system — and every hour spent on it is an hour wasted. Do not reset passwords. During an authentication problem, a password change may not propagate properly, and you can end up locked out well after the underlying incident is fixed. If someone genuinely can't sign in today, wait it out. Save your work locally. If a document won't sync, keep a copy on the machine until it does. Don't assume something saved just because it looked like it did. Don't fight the retries. Repeatedly refreshing a page that's timing out adds load without helping. Come back in a few minutes. Tell your team it's not them. Half the cost of a day like this is a dozen people quietly assuming they broke something and trying to fix it on their own. If you're an inc-sys client, we're already watching this and you don't need to open a ticket to tell us. If you're not and today has you wondering who is watching your systems, that's a fair question to be asking.