What happened in the CrowdStrike outage and what should defenders learn?

On 19 July 2024 a faulty Falcon content update from CrowdStrike crashed Windows hosts running sensor 7.11 and above. It was reverted 78 minutes after release. The cause was a content defect, not an attack. Defenders should take away lessons on staged rollouts, recovery access and vendor update control.

What was the timeline?

All times below come from CrowdStrike's incident summary for Channel File 291, in UTC.

• 28 February 2024: sensor 7.11 became generally available, introducing a new template type.
• 5 March 2024: the template type passed stress testing and the first instance went to production.
• 8 to 24 April 2024: three more template instances were deployed and performed as expected.
• 19 July 2024, 04:09: a content update shipped with two new template instances, and one passed validation despite containing bad data.
• 19 July, 05:27: the defect was reverted.
• 22 July: automated remediation techniques were introduced.
• 24 July: over 97 percent of Windows sensors were back online, week over week.
• 29 July: about 99 percent of Windows sensors were online compared with before the update.
• 6 August: the root cause analysis was published.

CISA's alert, first issued on 19 July 2024, reported that Microsoft estimated 8.5 million Windows devices were affected. CrowdStrike's own page gives no absolute device count. Mac and Linux hosts were not affected.

What was the cause?

CrowdStrike reports that the content update supplied 21 input fields while the sensor expected 20. The mismatch caused an out of bounds memory read, and the sensor's content interpreter could not handle the resulting exception gracefully, which crashed Windows. A logic error in the content validator let the content through. CrowdStrike and a third party review concluded the bug is not exploitable by an attacker.

How did people recover?

The guidance had two tracks. For individual hosts, reboot, preferably on a wired connection, so the host can fetch the reverted file. If it crashed again, use recovery media or the manual process, and note that BitLocker protected hosts may need a recovery key. For cloud machines, roll back to a snapshot from before the update or mount the disk on another machine and delete the faulty file.

The hard part was scale. Many machines needed hands on the console, and the recovery key was a bottleneck wherever keys were poorly tracked.

What should defenders learn?

Test recovery, not only prevention. Could you reach every machine's disk encryption key quickly? Do you know which systems need physical access to fix?

Question automatic updates. CrowdStrike listed staged deployment rings and customer control over content deployment among its preventive measures. If a vendor lets you choose a ring, use a canary group first.

Know your critical dependencies. An inventory of agents and drivers that run at kernel level is part of knowing what can bring a machine down.

Plan for the phishing wave. CISA warned about outage related phishing and advised following only guidance from legitimate sources.

Keep an out of band channel. If your chat, email and ticketing run on affected machines, how do you coordinate?

What do we not claim?

We do not rank companies or assign blame. We only report what CrowdStrike and CISA published. Pages can be revised, so read the sources yourself.

What to do

1. Inventory endpoint agents and drivers that load early in boot, and who controls their updates.
2. Create a canary ring that gets vendor updates first, where the vendor allows it.
3. Store disk encryption recovery keys somewhere reachable when the domain is down.
4. Run a recovery drill on a sample of machines and time it.
5. Prepare an out of band communication plan.
6. Pre-brief staff on outage phishing and the legitimate guidance channel.

Quick check

Sources

• CrowdStrike, Channel File 291 incident summary, fetched 18 October 2026.
• CISA, Widespread IT outage due to CrowdStrike update, fetched 18 October 2026.

Last reviewed: 18 October 2026.