An identity provider outage is the one failure mode where your dashboards stay green and your entire company stops working anyway. On August 31, 2026, Microsoft acknowledged a widespread Exchange Online incident at 5:30 PM UTC, tracked as EX1464935, and described it in the admin center as "a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity." Tens of thousands of users were affected according to Downdetector. Email delivery stalled, admin consoles refused to load, and reporting during the event described the impact spreading well past Exchange into other parts of the Microsoft 365 suite.

If you were on call that evening and your company runs on Microsoft 365, your monitoring probably told you very little. CPU was fine. Your own error rates were fine. Your synthetic checks against your own product passed. And yet half your organisation could not send an email, join a meeting, or open a document. That gap between what you measure and what your users experience is the defining property of an authentication outage, and most on-call rotations are not designed for it.

This post is about that gap: why identity failures behave differently from ordinary outages, how to map your authentication blast radius before the next one, and how to keep an incident running when the thing that broke is the thing you log in with.

What actually happened, and why the symptom list matters

Microsoft published a symptom list that is worth reading carefully, because it is a near perfect description of an auth plane failure rather than a capacity or code failure. The reported symptoms included delays or failures when sending or receiving email, authentication related errors when accessing Exchange Online services, difficulty accessing or performing actions within Exchange administration experiences, and intermittent failures affecting mailbox operations and message delivery workflows.

Notice what is missing. There is no mention of a bad deploy, a regional capacity event, or a specific feature regressing. Every item on that list is the downstream shadow of requests that could not establish trust. Mail did not fail because the mail pipeline broke. Mail failed because the requests carrying it could not prove who they were.

One failure, many product names

The second thing to notice is the spread. Exchange Online was the first thing to surface publicly, but coverage during the incident described the same underlying problem reaching into SharePoint Online, OneDrive for Business, Teams, Purview and Defender XDR. Several outlets attributed the root cause to an expired authentication certificate that had not been renewed on schedule. Microsoft's own public wording during the event stayed narrower than that, so treat the certificate detail as reported rather than confirmed until a formal postmortem lands.

Either way, the structural lesson holds regardless of the exact root cause. A single shared authentication component sits underneath products that your organisation almost certainly treats as separate systems. In your vendor inventory, Teams and SharePoint and Defender are separate rows with separate owners and separate criticality ratings. In the provider's architecture, they share a dependency. When that dependency fails, your carefully differentiated risk assessment collapses into one event.

This is not a Microsoft specific observation. Google Workspace, Okta, Auth0, AWS IAM and every SSO provider have the same shape. Consolidating identity is genuinely good security practice. It is also, by construction, the creation of a correlated failure domain that spans every application behind it.

Why an identity provider outage breaks normal on-call instincts

Most incident response training assumes a failure that is local, partial and observable. Auth failures violate all three assumptions at once.

Your traffic graphs will lie to you

In a typical outage, the signal arrives as a spike: error rate up, latency up, throughput down. In an authentication outage of a third party suite, your own product may be entirely healthy. What changes is that humans cannot get into things. Nobody is generating the traffic that would show up as an anomaly on your side, and the vendor's own dashboards may still be aggregating before anything turns red.

The practical consequence is that your first credible signal is very often a human in a chat channel saying that something feels broken. Teams that treat human reports as low priority noise until a monitor agrees will lose fifteen to thirty minutes on exactly the class of incident where they can least afford it.

The failure is correlated, not sampled

Ordinary degradation hits a percentage of requests. Auth failures tend to hit everything that shares the broken trust path, all at once. That changes triage arithmetic. Under partial degradation you can reasonably spend ten minutes narrowing scope. Under a correlated auth failure, scope is already maximal, and the useful question is not "how much is broken" but "what can we still do."

Your recovery tools also need to authenticate

This is the part that catches otherwise well prepared teams. The runbook lives in a wiki behind SSO. The escalation contact list lives in the HR system behind SSO. The incident bridge is a meeting product in the affected suite. The admin console you would use to check status requires an admin login through the identity provider that is down. Every one of those is a perfectly sensible choice on a normal day and a dead end during an auth outage.

When your organisation's primary chat and meeting platform is part of the affected suite, the failure is compounded further: the outage removes the channel you would normally use to coordinate the response to the outage. Teams that run incident response inside a single vendor's collaboration stack should assume, at least once, that the stack itself is the incident.

Map your authentication blast radius before the next outage

The single highest value exercise you can run this quarter takes about ninety minutes and needs no new tooling. Build an explicit map of what stops working when each identity dependency fails.

Build the auth dependency table

List every system your team touches during an incident. For each one, record which identity provider it authenticates against, whether a non SSO fallback login exists, who holds that fallback credential, and how the credential is stored. Most teams discover two uncomfortable things immediately. First, far more systems route through one provider than anyone assumed. Second, the fallback credentials that do exist are stored in a password manager that itself authenticates through the same provider.

Do the same for the vendor side. For each major SaaS suite you depend on, write down which of its products share a control plane. You will not get this perfectly right from the outside, but even a rough grouping beats treating twelve products as twelve independent risks when the vendor treats them as one.

Rank by what it blocks during an incident, not by normal day importance

A wiki is a low criticality system on a normal Tuesday. During an incident it may be the only place your runbook exists, which makes it a critical path dependency. Re-rank your inventory by incident time importance rather than business as usual importance and the priorities shift noticeably.

Alert delivery: can a page reach a human if the identity provider is down? Test this specifically, not in general.
Coordination channel: where do responders talk if the primary chat platform is part of the affected suite?
Runbook access: is there an offline or separately authenticated copy of the top ten runbooks?
Contact list: can the incident commander reach the current on-call engineer without querying a system behind SSO?
Customer communication: is your status page hosted and authenticated independently of your main identity provider?
Break glass access: do local or emergency accounts exist for the systems you would need to touch, and has anyone used them in the last six months?

The last point deserves emphasis. Break glass credentials that have never been exercised are not credentials, they are hopes. Rotate them, test them on a scheduled cadence, and record the test. An emergency account that turns out to be disabled or expired is worse than none, because you will spend precious minutes discovering that during the incident.

Detect auth failure directly instead of waiting for a status page

Vendor status pages are a lagging indicator by design. They are updated by humans who are themselves in the middle of an incident, they self grade severity, and during the August 31 event the admin center notice arrived after users were already reporting failures on social media and forums. If your detection strategy is "we will know when the vendor posts," your detection strategy is a subscription to someone else's timeline.

Run synthetic authentication checks

The fix is unglamorous and effective: run a small synthetic check that performs a real login flow against each critical provider on a short interval, from infrastructure that does not depend on that provider. Not a health endpoint. Not a ping. An actual token acquisition, from a service account, with the result recorded as a first class metric.

Do the same for one representative downstream action per product. Acquire a token, then send a test message, then read it back. That end to end path is what your users care about, and it catches the case where tokens issue fine but a downstream service rejects them.

Separate the auth signal from the application signal

If your alerting collapses "login failed" and "application error" into the same alert, responders cannot tell an identity outage from an application bug in the first two minutes. Give authentication its own alert class, its own routing, and its own runbook. The response is materially different, so the alert should be too.

This also improves your postmortem data. Teams that tag incidents by failure class rather than by affected product discover patterns they otherwise miss, such as how many of last quarter's user visible incidents were actually trust and credential failures wearing a different costume.

Design an incident path that does not authenticate through the failure

The design goal is simple to state: at least one complete incident response path should not depend on your primary identity provider. Completing that path means detection, paging, coordination, decision making and customer communication all work.

Keep the coordination channel out of the blast radius

Diversity here is worth real money. If your document store, mail, and meetings all live in one suite, your coordination channel should live somewhere else. Many teams already have this by accident: engineering coordinates in Slack while the wider business runs on Microsoft 365, or the reverse. That accident is worth formalising into a written rule, because it is the difference between an awkward hour and a silent one.

Running on-call and incident response inside a chat platform that is independent of your main productivity suite is one of the more practical forms of dependency diversity available. This is the case we make for Slack native on-call at Pagerly: schedules, escalation, paging and the incident channel all live in the tool your engineers already have open, and when a separate vendor's identity plane fails, that path is unaffected. The same logic works in reverse. If Slack is your critical dependency, make sure your paging path has an out of band route that does not require it.

Guarantee the page can still land

Escalation should terminate in a channel that does not share a failure domain with the systems being escalated about. Phone and SMS remain valuable precisely because they route through infrastructure that has nothing to do with your corporate identity provider. Verify that your escalation policy actually has that terminal step, that the phone numbers in it are current, and that someone tested it this quarter.

Cache what you cannot afford to lose

Keep a short, boring, offline artifact: current on-call names and phone numbers, the severity matrix, the status page login path, the top five runbooks, and the vendor support escalation procedure. Distribute it in a form that survives a total SSO failure. A printed card in a desk drawer is unfashionable and works.

A first hour sequence for an auth outage

When the pattern matches an identity failure, the ordering of work is different from a normal incident. A sequence that holds up under pressure:

Minutes 0 to 5: confirm the failure class. Is this authentication, or an application error that resembles one? Check your synthetic token acquisition metric first, then the vendor status page second, then user reports third.
Minutes 5 to 10: declare, and declare in the out of band channel. Do not spend this window trying to reach people through the system that is failing. State plainly that the suspected cause is external and that the team is not looking for a bad deploy.
Minutes 10 to 20: establish what still works. Publish the list of functioning capabilities to the whole organisation. This single message prevents dozens of duplicate reports and stops other teams from starting their own parallel investigations.
Minutes 20 to 40: assess your own exposure. Does your product authenticate users through the affected provider? Do your background jobs use tokens from it? Are there queues silently backing up that will cause a second incident when service returns?
Minutes 40 to 60: communicate externally if customers are affected, and set an internal update cadence. Then stop actively working and start monitoring. On a third party auth outage there is usually nothing for you to fix, and burning responders on a problem you cannot influence is a real cost.

That last instruction is the one teams find hardest. There is enormous pressure to look busy during a visible outage. Resisting it, and explicitly standing responders down to a monitoring posture with a named watch owner, protects the people you will need when the recovery surge arrives.

Plan for the recovery surge, not just the outage

Auth outages have a distinctive tail. When trust is restored, every retry, every queued job, every client that has been backing off, and every human who has been repeatedly clicking refresh arrives at once. Providers deploy the fix and then spend a long stretch draining the backlog. In the August 31 event, recovery was reported to take several hours after the initial mitigation began, which is typical.

Two practical implications. First, keep your incident open through the recovery window rather than closing it the moment the vendor says mitigation is deployed, because the thundering herd can produce a second, self inflicted outage on your side. Second, check your own retry behaviour in advance. Clients that retry aggressively without jitter will amplify the surge and can turn someone else's recovery into your degradation.

Communicating when the outage is not yours

Say what is true and what you are doing

Customers do not benefit from vendor blame, and they can usually see the vendor's status page themselves. What they need is scope and expectation. Name the affected capability rather than the vendor product, state whether their data is at risk (in an auth outage it almost never is, and saying so calms people), give a concrete next update time, and offer a workaround if one exists.

Set internal expectations early

Internally, the most useful message is the inverse of the usual one. Tell people what still works. A short list of functioning alternatives, sent to the whole company in the first twenty minutes, does more good than five status updates about a fix you do not control.

What belongs in the review afterwards

A third party outage still deserves a review, and the review should be about your response rather than the vendor's engineering. Useful questions:

How long between first user impact and first internal acknowledgement, and what closed that gap?
Did the coordination channel survive, and if it did, was that by design or by luck?
Which systems turned out to be behind the failing identity provider that were not on the dependency map?
Did break glass access work when someone actually tried it?
Did our own retry behaviour help or hurt during the recovery window?
What did we tell customers, how quickly, and would we say the same thing again?

Track a metric that most teams do not: time to correct classification. How long did it take to know that this was an external authentication failure rather than an internal bug? Every minute spent chasing a deploy that was never the cause is a minute of pure waste, and it is a number you can improve deliberately with better auth specific alerting and a clearer runbook.

The takeaway

An identity provider outage is not a rare exotic failure. It is a recurring, structural consequence of the same consolidation that makes modern security workable. Microsoft has now addressed several Exchange Online service issues in 2026 alone, and every large identity provider has a comparable history. The question is not whether your authentication plane will fail, but whether your incident response can operate while it is failing.

Three things are worth doing this week. Write down the auth dependency map for the systems you would need during an incident. Add a synthetic login check for each critical provider, running from somewhere that does not depend on that provider. And confirm, by actually testing it, that a page can reach the current on-call engineer through a path that does not touch your primary identity provider.

None of that is expensive. All of it is the difference between an incident you run and an incident that runs you.

Sources: BleepingComputer coverage of the August 31, 2026 Exchange Online outage.