I'm writing this on the day it happened, July 19, while a lot of the world's Windows machines are still showing a blue screen.
Early this morning, at 04:09 UTC, CrowdStrike pushed a routine content update to its Falcon security sensor on Windows. Machines that received it crashed, and on reboot crashed again, before anyone could log in. Airlines grounded flights. Hospitals postponed surgery and went back to paper. Banks, broadcasters, supermarkets, payment terminals and, in some places, emergency call centers went down. Mac and Linux machines running CrowdStrike were not affected.
It came hours after a separate problem: on the evening of July 18, a configuration change on Microsoft's side took down a large part of Azure's Central US region, taking Microsoft 365 services and customers' applications with it. The two weren't related. They just made for a very bad day to work in IT.
It wasn't an attack
The first thing to say clearly, because the rumors started within minutes: this was not a cyberattack. CrowdStrike's CEO said so this morning, and nothing suggests otherwise. It was a defective update from a security vendor, deployed everywhere at once.
That makes it, in a way, more alarming. Nobody had to break in. The software everyone installed to keep attackers out did the damage itself.
Why one update can do this
Three things combined.
It runs in the kernel. CrowdStrike's Windows sensor, like most endpoint security products, runs a driver inside the operating system kernel, where it can see everything and stop malware before it acts. That's also where a crash isn't contained. An application that crashes shows an error. A kernel driver that crashes takes the whole machine down, with a blue screen.
It updates itself, constantly. The update wasn't a new version of the software, which customers can schedule and stage. It was a "content" update, new detection data that CrowdStrike pushes to every sensor automatically, sometimes several times a day, so customers are protected against new threats quickly. Most organizations had no control over its timing at all.
It's everywhere. CrowdStrike is one of the most widely used endpoint security products in large organizations. When every airline, bank and hospital buys the same best-in-class product, they also buy the same failure.
Why the fix is so slow
The workaround is simple to describe: boot the machine into Safe Mode or the recovery environment and delete the faulty file. CrowdStrike published it within hours.
It's also brutal in practice. It has to be done by hand, on each machine, because a machine stuck in a crash loop can't receive a fix over the network. Many corporate disks are encrypted with BitLocker, so each one needs its recovery key, which is often stored on a server that is itself down. Cloud virtual machines need their disks detached and mounted elsewhere. For an organization with fifty thousand laptops scattered across a country, that's days of work.
The real lessons
The usual explanations for outages, software bugs, human error, infrastructure failures, are all technically true here. They're also not very useful. The deeper causes are about design and concentration:
- Staged rollouts matter more than testing. No vendor will ever catch every bug in testing. That's why you deploy to a small fraction of machines first, watch, and then widen. Apparently that didn't happen with this update, and it went to everyone within minutes. Any update to code running in a kernel, including "just data," should go out in stages.
- Customers need control over timing. Organizations should be able to put critical systems in a later update ring, even for security content, and accept a few hours' delay in exchange for not being first.
- Kernel access should be the exception. The more third-party code runs in the kernel, the more ways there are to take the system down. Linux has been moving security tooling to eBPF, where programs must pass a verifier before they load and can't crash the kernel in the same way. Windows will need its own answer.
- Monoculture is a risk to plan for. If one vendor's failure stops your airline, it's a single point of failure regardless of how good the vendor is. For the most critical systems, diversity, of security vendors, operating systems and fallback procedures, is worth paying for.
- Recovery needs to work without the network. Know where your BitLocker keys are, test recovery procedures that work when everything is down, and keep enough paper process to keep operating for a day.
Does open source fix this?
It's tempting to say open source would have prevented this. It wouldn't, on its own. An open source agent that pushed a bad update to every machine at once would crash them all too.
What open source and openness do offer is the ability to see what a privileged agent is doing, the freedom to control when it updates, and the option to switch if a vendor's practices put you at risk. Those are the things today showed we need. I'll look at open source tools for the same job in open source alternatives to CrowdStrike.
For now, if you're one of the people walking from desk to desk with a USB stick and a list of recovery keys: good luck, and drink some water.
Since then
Added October 2026. Microsoft later estimated that 8.5 million Windows machines crashed. CrowdStrike's root cause analysis in August traced it to a mismatch between the number of input fields its sensor expected and the number the new content provided, which its validation didn't catch. Delta alone put its losses at about $500 million and sued. Microsoft responded with a Windows Resiliency Initiative, and in 2025 began previewing a platform that lets antivirus and endpoint security products run outside the kernel. I followed the story in CrowdStrike's history of releasing software that breaks operating systems, the CrowdStrike post-mortem and the postmortem of the July 2024 outage.