Build the Microsoft 365 Outage Runbook You Didn’t Have

At 17:30 UTC on 31 August 2026, sign-in requests against Exchange Online started failing. Within hours the same pattern showed up in Teams, SharePoint, OneDrive, Purview, Defender XDR, the admin center, Copilot, and Universal Print. Microsoft didn't declare the incident mitigated until the afternoon of 3 September — roughly 73 hours later, Exchange Online the last service to fully recover. It was a three-day Microsoft 365 outage, and most tenants had no runbook to reach for.

Seventy-three hours is long enough to expose every assumption an IT team makes about its own emergency tooling. The admin center you'd use to check status was degraded. Teams, your default channel for coordinating a response, was affected too. Defender XDR, the console you'd use to rule out a security incident rather than an outage, had its own portal problems on top. That's the textbook failure mode for a large authentication incident, but most tenants only discover it live, because nobody wrote down what to do when the identity plane itself is what's broken.

This is the runbook to write before the next one: why an "authentication component" failure cascades, how to configure break-glass accounts and Conditional Access so part of your access survives, what CAE and resilience defaults do while token issuance is degraded, how to detect the next incident before your help desk does, how to communicate when usual channels are down, and what to do afterward.

Three Days, Traced Against Microsoft's Own Timeline

Microsoft's updates, relayed through press coverage as the incident unfolded, describe a misconfiguration issue impacting its service — specifically "a core authentication configuration used by multiple Microsoft 365 services" that "prevented authentication components from deploying as expected to a portion of infrastructure," per TechCrunch. BleepingComputer reported Microsoft had "isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity." Neither outlet reported a more specific cause, and this article doesn't speculate beyond what Microsoft stated.

The prefix matters for your own tooling: Microsoft's service health issue schema uses a service-letter prefix plus a numeric ID (its own example is EX226792), so an EX-only alert misses the moment an incident is reclassified as multi-service under an MO ID.

Why "authentication component" cascades the way it does. Microsoft published no dependency diagram — this is general platform architecture, not a Microsoft claim — but it explains what you saw. Exchange Online, SharePoint, Teams, and Graph all rely on Entra ID to issue and refresh access tokens. A service running on an already-issued, still-valid token keeps working for a while after the identity plane degrades; a service needing a new token — a fresh sign-in, an expired session, a new app registration — fails closed the moment issuance is unhealthy. Not everything breaks at once: cached and long-lived tokens buy time, and most of this runbook is about using that window well.

Two Accounts in a Safe, Excluded From Everything That Might Change

Break-glass accounts are the single most load-bearing control here, and Microsoft's guidance on managing them is specific about what "done right" means in 2026:

• Cloud-only, on the default domain. Create at least two accounts as cloud-only users on *.onmicrosoft.com that "aren't federated or synchronized from an on-premises environment." A federation outage is one of the scenarios these accounts exist for — don't let it also be why they can't sign in.
• Passkey (FIDO2), not a password plus app-based MFA. Microsoft recommends "Passkey (FIDO2) (Recommended)" or certificate-based auth if you run a PKI, and a different method than your normal admin accounts — if admins carry Microsoft Authenticator, the break-glass account shouldn't.
• Excluded from every Conditional Access policy that can block sign-in. Microsoft's wording: "Verify that emergency access accounts are excluded from any Conditional Access policy that blocks or restricts sign-in… an enforced Conditional Access policy could prevent sign-in during the exact emergency the account is designed for." Report-only policies don't need the exclusion.
• Excluded from method-migration sweeps, not just from CA. The gap most tenants miss: when you retire SMS and voice MFA or roll passkeys out tenant-wide, a bulk method-enforcement policy can silently re-scope an account that isn't in its own excluded group. Put both accounts in a dedicated group — Microsoft's example name is EmergencyAccess — and exclude that group from every authentication-strength policy, not just access policies.
• FIDO2 keys, stored physically. "Store credentials in secure, fireproof safes that are in secure, separate locations." A password manager entry isn't a safe.
• Tested at least every 90 days. Validate sign-in and admin tasks under the tenant's current Conditional Access configuration — not as a one-time setup step.

Wire monitoring in the same place you configure the accounts. Microsoft's documented pattern uses Azure Monitor against SigninLogs, filtered to the emergency accounts' object IDs, with a severity-0 alert on any hit:

// Alert on any sign-in from a break-glass account — severity 0, notify immediately.
// Add one "or UserId == ..." clause per additional emergency access account.
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Every hit — drill or real emergency — should trigger a post-mortem of what the account did and why. Before you close out the quarterly test, run a Conditional Access gap analysis against the break-glass UPN using What-If, so the exclusion is verified rather than assumed.

What Keeps Working When Entra Can't Answer in Real Time

Two mechanisms decide how much of your tenant keeps functioning while token issuance is unhealthy, and both need to be in the state you want before the next incident starts.

Resilience defaults. During an outage, Microsoft's Backup Authentication Service "automatically issues access tokens to applications for existing sessions" when the primary authentication service is unavailable — worth having, since "reauthentications for existing sessions account for more than 90% of authentications to Microsoft Entra ID." It can't issue tokens for brand-new sessions or guest users, and can't evaluate conditions needing real-time data — group or role membership, sign-in risk, user risk, country/region location.

The setting is disableResilienceDefaults on each policy's session controls, and it's enabled by default unless someone turns it off. Query your tenant for any policy where that's happened, intentionally or not:

# Requires: Microsoft.Graph.Authentication module and Policy.Read.All scope
Connect-MgGraph -Scopes Policy.Read.All

$policies = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"
$policies.value |
  Where-Object { $_.sessionControls.disableResilienceDefaults -eq $true } |
  Select-Object displayName, id

Microsoft recommends leaving resilience defaults enabled tenant-wide: disabling it on a policy "reduces resilience for all users in the tenant" whenever that policy targets a group or role, since membership can't be checked in real time and the block falls on everyone in scope, not just the users the policy meant to catch. One caveat: the Backup Authentication Service shares CAE's revocation events, so a token already revoked before the outage stays revoked regardless.

Continuous access evaluation (CAE). Separately, CAE changes how long a session survives without touching Entra ID at all. It "focuses on Exchange, Teams, and SharePoint Online," and for CAE-aware clients, "token lifetime increases to long-lived, up to 28 hours" instead of the default one hour — real buffer in a multi-day incident: a user already signed in before the outage keeps working for more than a full day without a fresh token. New sign-ins and expired sessions still depend on the primary or backup path answering.

Watching the Health Feed Before Your Help Desk Does

Most tenants find out about an outage the way this one broke: users calling the help desk. Three channels catch it earlier, none dependent on the admin center staying reachable.

Microsoft Graph's service health API. The serviceAnnouncement/issues endpoint returns every service health issue for your tenant, with the ServiceHealth.Read.All permission — the same data feeding the admin center's Service health page:

# Requires: Microsoft.Graph.Devices.ServiceAnnouncement module
Import-Module Microsoft.Graph.Devices.ServiceAnnouncement
Connect-MgGraph -Scopes ServiceHealth.Read.All

Get-MgServiceAnnouncementIssue | Where-Object { $_.Classification -eq 'Incident' -and -not $_.IsResolved }

Poll this from somewhere that doesn't itself depend on M365 auth — an Azure Function with a managed identity, or infrastructure outside the affected cloud — and you get an alert the moment Microsoft opens an incident, not when a user notices mail stopped arriving.

A Sentinel analytic rule on sign-in failure spikes. Sentinel ships a built-in rule for privileged-account failure spikes; the same pattern, generalized tenant-wide, catches an authentication-plane problem before it's officially declared:

// Flag an unusual spike in failed sign-ins across the tenant, bucketed hourly.
// Tune the threshold against your own baseline before enabling as a live alert.
SigninLogs
| where ResultType != "0"
| summarize FailedSignIns = count() by bin(TimeGenerated, 1h)
| where FailedSignIns > 500

status.cloud.microsoft — for when the admin center itself is down. Microsoft's service health guidance is explicit: "If you're unable to sign in to the admin center, you can use the service status page to check for known issues," pointing to status.cloud.microsoft plus @MSFT365Status on X. Bookmark it on a personal device, not a work laptop tied to the tenant it's reporting on — and if your runbook still cites an RSS feed for the Service Health Dashboard, drop it; Microsoft's current guidance names only the admin center, status.cloud.microsoft, and @MSFT365Status, with no RSS option among them.

A Channel That Doesn't Depend on the Thing That's Down

Teams was one of the affected services in this incident. If your incident communication plan lives entirely inside Microsoft 365, you lose the ability to coordinate at the exact moment you need it most. Agree on a fallback channel before you need it: a phone tree, an SMS group, or a separate tool that doesn't share an identity provider with the affected service.

Keep the first message short and factual — it exists to stop the flood of individual "is email down for you too?" messages, not to explain the root cause:

[INCIDENT] Microsoft 365 sign-in / mail / Teams issue — ongoing
Confirmed via status.cloud.microsoft at <time>. Tracking as Microsoft
incident <EX/MO-ID once assigned>. No action needed from staff yet.
Updates here every 30 min or on status change. Do not open tickets
for this — reply here if you're seeing something different.

Update on a fixed cadence even with nothing new — "still degraded, no change" is itself useful, and it's the difference between a channel people trust and one they stop checking.

What Still Works at the Endpoint When the Cloud Doesn't

Windows devices carry more local resilience than most admins credit, and knowing what survives an outage stops a panic.

The Primary Refresh Token (PRT) enables cached sign-in. On Microsoft Entra joined and hybrid joined devices, the CloudAP plugin "caches the PRT to enable cached sign in when the user doesn't have access to an internet connection." A PRT is valid 90 days and normally renews every four hours; if renewal can't reach Entra, a user who's signed in before can still unlock the device on cached credentials. On hybrid joined devices, on-premises Active Directory is the primary authority for sign-in, so a user reaches the desktop via a domain controller ticket even while PRT issuance is stalled — though cloud resources needing a fresh token stay unreachable until that clears.

Autopilot has no fallback. Its enrollment status page needs both Entra join and Intune enrollment, both requiring live authentication — a new device provisioned mid-outage stalls rather than degrades, since there's no cached credential for a device that's never signed in. Pause new-device rollouts for the duration.

Universal Print has no offline queue. Every print job routes through the cloud service, so a client that can't authenticate can't submit the job. If you kept a legacy on-premises print server as a fallback, this incident argues against retiring it yet.

The Microsoft 365 Outage Runbook, From Alert to Verified Recovery

Where This Runbook Breaks

A break-glass account that's itself MFA-enforced by a later policy change. Method-migration policies are usually written to apply to "all users" for simplicity, and an account in EmergencyAccess today can still get swept up if a future policy targets a broader group it also belongs to, or someone forgets the exclusion. The fix is the quarterly sign-in test — a gap not caught in a drill gets caught during a real emergency.

A "block legacy authentication" policy that removes a device's only working path. Good hygiene generally, but if a device's only egress is an unremediated legacy client, blocking legacy auth removes the one path it had left. Test legacy-auth changes against your actual inventory, not the intended target.

Assuming Defender XDR is watching when its own portal is degraded. This incident's affected-services list included Defender XDR. A team that assumes detection is still running because "the SIEM would have alerted us" is making an availability assumption about the same plane that just failed. Treat monitoring coverage as unverified until you've confirmed the portal and ingestion are healthy.

Post-Incident Checklist

Two things are worth asking Microsoft for once recovery verification is clean. First, the post-incident review: for unplanned incidents with "broad and noticeable impact across a large number of organizations," Microsoft's documented commitment is "a preliminary post-incident review (PIR) will be delivered via your Service health within 48 hours of incident resolution, followed by a final PIR within five business days," including root cause and corrective actions — read it against your own dependency assumptions.

Second, an SLA credit claim if it qualifies: gather your tenant GUID and the EX/MO identifier from Service health, plus your own impact evidence, and file a support request through the admin center rather than waiting for Microsoft to initiate it. Do this promptly — the claim window ties to the incident's calendar period, not to when you got around to filing.

Close the loop internally too: confirm break-glass accounts weren't used without a matching authorized log entry, roll any credentials touched during manual recovery, and update this runbook with whatever this incident taught you that the last one didn't. A Microsoft 365 outage runbook that never changes after an incident isn't a runbook, it's a document you wrote once and hoped not to need.

Related Articles

• EWS Retirement: Your Exchange Online Graph Migration Plan
• Exchange Online Message Trace vs Mail Flow Rules: Diagnosing Delivery Failures Step by Step
• Microsoft 365 Reporting in 2026: Usage Reports, Graph API, and Entra Logs