On 13 October 2026 some Microsoft 365 users who connected through Global Secure Access (GSA) could not use Outlook, OneDrive, SharePoint Online, Teams and Windows 365 Cloud PCs. Microsoft's final status update gives a window of 07:40 to 18:31 UTC, about 10 hours 51 minutes. We worked from IncidentHub's record of Microsoft's public status updates, because we could not reach the status page directly. Treat the timeline as that record, not as a Microsoft report.
What happened
- 14:38 UTC: traffic optimizations were deployed. Errors dropped at first, then the issue persisted.
- 14:59: engineers began redirecting traffic away from the underperforming infrastructure.
- 15:24: redirection to healthy infrastructure was complete, with further fixes still under way.
- 16:25: part of the infrastructure that had traffic removed was restarted. Internal tests suggested the restart fixed impact for some users.
- 17:26: scope narrowed from Germany and the UK to Germany. The start time was revised to 07:40 from 08:00.
- 18:20: a workaround was posted. Users could turn off GSA.
- 18:48: Microsoft marked the incident resolved, based on telemetry and user reports.
What is confirmed, reported and unknown
- Confirmed by the status updates as recorded: the affected services, the regions, the fix sequence, the workaround and the end time.
- Stated cause, mid incident only: "a section of GSA infrastructure is performing below acceptable performance thresholds." The final update does not restate a cause.
- Unknown: the root cause, whether users not on GSA were affected, and why the turn it off workaround appeared roughly ten and a half hours after the stated start. No post incident report had been published at the time of the source.
This does not look like an attack. Nothing in the updates says so, and nothing says it was not.
What to do now
- Find out whether your tenant routes users through GSA, and for which user groups.
- Check who in Germany and the UK could not work on 13 October, and note the hours.
- Write a one page break glass procedure: who may disable GSA for a group, how, and who approves it.
- Test that Microsoft 365 is reachable without GSA before you need to.
- Watch for the post incident report in Service health and compare its cause with the one here.
How this could have been avoided
Microsoft owns the service, so these are customer side controls that would have shortened the impact.
- A documented bypass. The only workaround was turning GSA off. Teams that had pre approved that step could use it earlier than 18:20.
- Segmented rollout of the access path. Put a pilot group on GSA first and keep the rest on direct access until the pilot is stable.
- Monitoring that sits outside the path. A synthetic login test from a network that does not use GSA tells you whether Microsoft 365 or your access layer is failing.
- A status feed in the on call channel. Impact was regional and partial, so users reported it before anyone saw a global alert.
Try it yourself
Pick the five services your staff cannot work without and write down, for each, what path they take to reach it and how to bypass that path in an emergency.
Click through it at your own pace, or open it full screen.
Quick check
Who was affected?
Users reaching Microsoft 365 through GSA, in Germany and the UK at first and in Germany only after 17:26 UTC. The updates do not address users who were not on GSA.
Did Microsoft publish a root cause?
Only a mid incident description of infrastructure performing below thresholds. No post incident report was available in the source.
