The workaround was to turn off Global Secure Access: the advice your own policy blocks

At 18:20 UTC on 13 October, with the incident about to hit eleven hours, the timeline records a workaround for affected users: turn off GSA. Eleven minutes later, at 18:31, the incident was declared over, so in practical terms that advice reached almost nobody in time. It is still worth stopping on, because there is a set of deployments where it cannot be followed: precisely the ones built the way the vendor's own documentation recommends building them.

What happened on 13 October

From 07:40 to 18:31 UTC — 10 h 51 m — Microsoft 365 users egressing through Global Secure Access could not use Outlook, Outlook on the web, OneDrive, SharePoint Online, Teams or Windows 365 Cloud PCs. The initial scope covered the United Kingdom and Germany; from 17:26 UTC it narrowed to Germany. Mid-incident updates describe the cause as "a section of GSA infrastructure is performing below acceptable performance thresholds", and the mitigation was redirecting traffic away from that infrastructure and restarting it in batches.

It is worth saying what it was not: it was not a Microsoft 365 outage. The services were up and working for everybody else. What was degraded was the path. Global Secure Access is Microsoft's access layer: an agent on the laptop acquires traffic and sends it to the Entra cloud, where policy is applied before it reaches its destination. It is, almost word for word, what we sell when we say Zero Trust: stop trusting which network the user is on and trust the identity and the path they arrive by.

The checkbox that makes the path mandatory

On top of that path sits a control called the compliant network check. Enabling it gives Conditional Access a location named All Compliant Network locations, and the documentation spells out its purpose: it "ensures users connect through the Global Secure Access service for their specific tenant and are compliant with security policies enforced by administrators". The sample policy that same page walks through step by step says: all users, all resources, network "any location" excluding the compliant ones, and the grant is block access. Translated: if you do not come in that way, you get into nothing.

The control is not decoration. It is built against token theft and replay, one of the few things that neutralises well-deployed MFA. Entra ID "performs authentication plane enforcement at the time of user authentication", and if somebody steals a session token and replays it from a device that is not on the compliant network, "Microsoft Entra ID immediately denies the request and blocks further access". With Continuous Access Evaluation the rejection also happens in the data plane "in near-real time". It is a good control and we recommend it. This post is not about removing it.

The same page documents the block as the proof of success

At the bottom of that page there is a section headed Try your compliant network policy. Three steps, and the last two are the ones that matter: with the client running, open an application in the tenant; then "pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Disable"; and then, on trying to reach another application, "Microsoft Entra ID Conditional Access blocks your access". The screenshot next to the step shows the message: You can't access this right now.

In other words: turning the client off and being locked out is the documented check that the policy is correctly in place. What was offered on the 13th as an escape route is, in the same vendor's manual, the control's success criterion.

Both sentences are correct and they do not contradict each other: they describe different tenants. Whoever runs Global Secure Access without a compliant network policy turns off the client and gets back to work. Whoever has it turns off the client and sees the message in the screenshot. The difference between the two is not company size or budget: it is a checkbox somebody ticked one day because somebody — possibly us — recommended it. And finding out which group you are in is not a matter of looking at a status dashboard; it is a matter of looking at a policy.

Who gets locked out, and when

The block does not land on everyone at once, and the documentation bounds it honestly: "if you're already signed in to an application, access isn't interrupted"; Entra "reevaluates the Compliant Network check the next time sign-in is required, when your application session expires". The step, therefore, is uneven:

• Whoever had Outlook open since before 07:40 can keep working for a while, which is why they will tell you it works fine for them.
• Whoever rebooted, arrived later, switched devices or opened their laptop at nine needs a fresh sign-in. Fresh check, block.
• Windows 365 Cloud PCs, which were on the affected list, are not a tab you already had open: every connection starts by authenticating.

That same page gives a figure that helps bound the grace period, though it needs reading carefully: discussing a stolen token without Continuous Access Evaluation, it says its default lifetime is "between 60 and 90 minutes". That is not the ceiling of your application session, which can last longer; it is the order of magnitude to reason with. Against a 10 h 51 m incident it is very hard for an open session to reach the end without asking for a fresh sign-in. And there is an operational irony worth facing: on integrated services that support CAE, the rejection also plays out in the data plane in near-real time. The better configured it is, the sooner you are locked out. Exactly how much sooner depends on your configuration; there is no single number that applies to everyone.

The right procedure exists, and Microsoft wrote it in March

This is where the vendor deserves fair treatment, because we were about to write our own emergency sequence and it turns out one is already published. Microsoft has two pages, dated 16 March 2026, each with a PowerShell script: one titled Disable traffic forwarding and disable Conditional Access policies using the compliant network condition in a break glass scenario, and a recovery one. The text is explicit: "temporarily disabling traffic forwarding profiles and disabling the Compliant Network condition policies can help your users regain access to their Microsoft apps in favor of productivity".

The interesting part is not that it exists: it is the order in which it does things, because that order is not the intuitive one. The emergency script finds every Conditional Access policy using the compliant network location — it spots them by a fixed identifier, 3d46dbda-8382-466a-856d-eb00cbc6b910, the same in every tenant — switches them to report-only mode and then disables the forwarding profiles. The recovery script does exactly the opposite: profiles back on first, policies second. And both open with the same warning in the header: run them from "an Entra ID emergency access admin account, not subject to Microsoft Entra Internet Access Compliant Network policy".

That order has a reason, and the boxed warning on the policy page states it for a neighbouring case — disabling GSA signalling in Conditional Access, which is a different switch from unchecking the traffic profiles: "if your organization has active Conditional Access policies based on compliant network check, and you later disable Global Secure Access signaling in Conditional Access, you might unintentionally block targeted end users from accessing the resources. If you must disable this feature, first delete any corresponding Conditional Access policies". Two different switches, one shared lesson: remove the path before the policy and you lock people out yourself.

What the scripts do not tell you: the clock

Both scripts do their work in seconds and finish by telling you it went fine. What appears in neither is how long each step takes to reach your people's laptops, and there is a number there worth memorising. It is in the client diagnostics guide, the same one that documents the state called, literally, break-glass mode — "break-glass mode prevents the Global Secure Access client from tunneling network traffic to the Global Secure Access cloud service. In break-glass mode, all traffic profiles in the Global Secure Access portal are unchecked and the Global Secure Access client isn't expected to tunnel any traffic" — and it reads: "the Global Secure Access client should receive the updated forwarding profile within one hour after you make changes in the portal".

Up to an hour between running the script and the laptop finding out. For an eleven-hour outage, it arrives in time. For a twenty-minute one, you arrive after the incident does. And on the way back, that same hour again: re-enable the policies before the clients have picked the profile back up and you reproduce the outage yourself, this time with nobody else to blame. That is in no script, because a script does not know how to wait: you have to know, and have it written next to the step.

The sequence, with a clock

This is not a list of best practices, nor a sequence of ours: it is the official script's steps, in its order, with the clock for each one next to it. The right-hand column is the only thing we add, and it is what turns a script into a procedure. Half a page, filed wherever your incident procedure lives.

And one exclusion that does not come from this incident but gets charged on the same day: if your organisation enrols devices in Intune, the documentation recommends excluding the Microsoft Intune Enrollment and Microsoft Intune applications from the policy "to avoid a circular dependency". The new laptop somebody tries to enrol that very morning needs that exception written beforehand, because there is no elegant way to write it mid-incident.

What we are not saying

• We had no affected customers and we have no telemetry of our own on this incident. Everything above comes from the published timeline and the vendor documentation; the original advisory is only visible from inside the affected tenant.
• We are not saying you should remove the compliant network check. It does what it promises, token theft is a serious problem and very little else stops it as well. We will keep recommending it.
• Nor that the vendor had not planned for it: it had, with a procedure and two scripts, since March. We were going to write the sequence from scratch and found it already published; we say so because the useful finding for you is that those two pages exist.
• What we are saying: a control that depends on a path turns that path's health into a dependency of your ability to work. That is no reason not to deploy it. It is a reason to write, the day you deploy it, the procedure for taking it off.

There is a pattern here we have run into twice this month. A few weeks ago we wrote that the Conditional Access policies you did not write are already in your tenant, put there by the vendor rather than by you; and after the Azure outage, that what mattered were not the four doors and the place where you kept the plan B. All three times the problem is not the failure: it is that the piece meant to save you lives inside the thing that failed. An access control that requires a path, a plan B stored behind plan A, a policy you did not write. The good question is not "what happens if it goes down?", it is "how do I get in to fix it when it does?".

Sources (checked 15 Oct 2026): the 07:40–18:31 UTC window on 13 October 2026, the 10 h 51 m duration, the list of affected services, the narrowing of scope to Germany at 17:26, the sentence about infrastructure below threshold and the 18:20 workaround come from the timeline IncidentHub reconstructs from Microsoft's status page. A precision that matters to us: that timeline entry reads "workaround suggested to users to turn off GSA", and no more; we have not seen the original advisory — it is only visible from inside the affected tenant — so we put no sentence in Microsoft's mouth. The eleven-minute gap to the declared end is flagged by that page itself. The incident was also covered by Neowin and The Register. The compliant network check, the sample policy, the exclusion of emergency accounts and of Intune, the "Try your compliant network policy" section with the Disable step, the note about already-signed-in sessions, the 60–90 minute token figure and the warning about the order when disabling signalling are in Microsoft Learn's "Enable Compliant Network Check with Conditional Access". The break-glass mode and the one-hour window for the client to receive the forwarding profile are in the Windows client diagnostics guide. The emergency procedure, its order, the location identifier and the emergency access account requirement are in the two PowerShell scripts dated 16 March 2026: the break glass one and the recovery one. What is ours, and we bound it: reading the 13 October workaround against the documentation's own test section, and the clock column — the "up to an hour" placed next to each step — which appears in neither script. The sequence itself is not ours: it is the vendor's.