CrowdStrike outage insured losses: replay 19 July 2024 on your book

No government agency or insurance regulator has published an estimate of insured losses from the CrowdStrike outage of 19 July 2024. What the public record does establish is the event itself: a defective content update to a security product crashed Windows systems worldwide, it was not a cyber attack, and, by the vendor's own testimony to Congress, the update went to every customer at once. Loss estimates in circulation come from commercial modelling firms and brokers; they vary widely and are not repeated here. For an insurer, the honest question is narrower and more useful than "how much did the market lose": would our accumulation method, run on 19 July with the data we held on 18 July, have named the insureds who later claimed, and estimated what we paid? Botminds' Cyber Accumulation Management is built to run exactly that kind of replay: a past vendor event, against an in-force book, with every dependency tied to dated evidence.

Where this guide uses product screens, they show a fictional sample book (Thistlebrook Specialty, 2,846 insureds) and a fictional vendor outage, not the CrowdStrike event; every company in them is invented. Public facts about July 2024 come from CISA, the House Homeland Security Committee, the U.S. Treasury and the UK Financial Conduct Authority, linked where they appear.

How much did the CrowdStrike outage cost insurers?

There is no official answer. The U.S. agencies that wrote about the outage described its cause and scope; none estimated insured losses. Treasury's Federal Insurance Office, in its June 2026 report to Congress on the terrorism insurance program, cited the event as a warning rather than a loss: "Recent “near miss” incidents, such as the July 2024 CrowdStrike outage and hyperscale cloud services provider outages, have highlighted how a cyber incident with broad effects could lead to catastrophic losses for the financial sector or the broader economy" (U.S. Treasury, Report on the Effectiveness of the Terrorism Risk Insurance Program, June 2026).

The phrase "near miss" carries the lesson. The outage was short for most organisations, it was non-malicious, and many cyber policies treat a provider's system failure less generously than an attack. All three features kept insured loss small relative to the disruption. Change any one of them (a longer outage, a malicious cause, broader dependent cover) and the same day becomes a catastrophe for the books that held the dependency. A market total hides which feature did the work.

The scale of the disruption is on the public record. CISA's alert, updated on 21 July 2024, passed on the platform owner's count: "Microsoft estimates the outage affected 8.5 million Windows devices. Microsoft notes that this number makes up less than one percent of all Windows machines" (CISA alert, Widespread IT Outage Due to CrowdStrike Update). Less than one percent of machines was enough to stop airlines, hospitals and federal agencies, because the affected machines were concentrated in organisations that had bought the same security product.

Was the CrowdStrike outage a cyber attack?

No. CISA's first alert, at 11:30 a.m. EDT on 19 July 2024, said the vendor had confirmed that the outage "Is due to the CrowdStrike Falcon content update and not to malicious cyber activity", that it affected Windows 10 and later systems, and that Mac and Linux hosts were not affected. The same alert warned that "threat actors" were "taking advantage of this incident for phishing and other malicious activity", a reminder that a non-malicious event can still generate malicious follow-on losses.

For accumulation, the cause decides which policies respond. A policy that covers business interruption from a provider's attack but not from its system failure was silent on 19 July. That is why an estimate must carry the cause as a switch, not an assumption, and why the PRA asked insurers in its 2022 stress test to consider "whether a claim is determined as arising from a malicious or non-malicious actor" when they compare modelled losses (PRA, Insurance Stress Test 2022 feedback).

Did cyber insurance cover the CrowdStrike outage?

For any one insured it depended on four things in the wording, and an accumulation estimate has to test all four. First, whether the policy had dependent (or contingent) business interruption cover at all, and whether it named the provider or covered any provider. Second, whether that cover responds to a provider's system failure or only to an attack. Third, whether the insured's interruption outlasted the waiting period. Fourth, the dependent business interruption sublimit and retention.

The third test was unusually hard on 19 July. The vendor's fix was deployed the same day, but affected machines did not heal themselves; CISA's 21 July update reported a recovery tool "that uses a USB drive to boot and repair affected systems". For an insured with thousands of crashed endpoints, the interruption lasted as long as its own recovery, not as long as the vendor's fault. A replay that uses the vendor's outage length instead of each insured's documented recovery will understate the hours past the waiting period. The mechanics are worked through in the guide to the cyber insurance waiting period.

The first test is where named-supplier wording matters. The Financial Stability Institute and the IAIS noted in 2026 that contingent business interruption "is not standard in all cyber policies" and that its scope "is often limited to specific named suppliers" (FSI Insights No 75, 2026). A security software vendor is not on many named-supplier lists, which is one reason this event produced less insured loss than its disruption suggested.

What did Congress find about the CrowdStrike outage?

The House Homeland Security subcommittee's September 2024 hearing put two accumulation facts on the public record. The company's witness said the faulty update was routine in kind: "We release 10 to 12 of these updates, content updates, every single day." And it was not staged: "The updates were distributed to all customers in one session. We’ve since revised that" (House Committee on Homeland Security, 26 September 2024).

Members also recorded the spread. Subcommittee Chairman Andrew Garbarino noted reporting of impacts on "emergency services, flights", and on "federal agencies such as the FCC, Social Security, CBP, and even CISA". For an insurer, "distributed to all customers in one session" is the accumulation in five words: every insured running that product on Windows was in the event at the same moment, regardless of sector or geography.

The updates were distributed to all customers in one session.

CrowdStrike’s witness to the House Homeland Security subcommittee, September 2024

Why a market loss figure would not answer your question

Because your book is not the market. A market estimate blends insurers with very different mixes of sector, wording and waiting period; it cannot tell you whether your own dependency data named the right insureds, or whether your policies' system-failure terms behaved as your pricing assumed. Two insurers with the same premium can have had very different 19 Julys.

The UK conduct regulator's review of how firms coped makes the same point from the policyholder side. Firms that had already mapped their third- and fourth-party relationships understood their exposure quickly and acted on it, the FCA found, while firms hit by the outage that themselves served other regulated firms passed the disruption along and made it worse (FCA, CrowdStrike outage: lessons for operational resilience, 31 October 2024; the banking guide to the critical third parties regime quotes the review). An insurer's book behaves the same way: dependencies through a provider are where the surprises sit.

How can insurers test accumulation models? Replay a real day on closed files

Replay the event as of the day before, then compare. The BIS's Financial Stability Institute and the IAIS describe the family of methods: counterfactual analysis "starts from a real event and examines how losses might have evolved if key parameters such as duration of disruption or number of affected systems had differed" (FSI Insights No 75). A replay is the first step of that: before asking what a longer outage would have cost, check that the method reproduces the outage that happened.

The discipline is in the dates. A replay of 19 July 2024 may use only scans, applications and provider disclosures dated on or before 18 July, and only the policy wording in force on 19 July. Anything learned from the claims themselves belongs on the comparison side. Then the gaps are honest: insureds the method named who never claimed (often because their waiting period held), and claimants the method never named (a missing dependency, usually through a provider).

The estimate a replay compares: loss by outage length and cause, insured by insured

What a replay usually exposes

Three gaps come up again and again when a method is tested against a real day. The first is missing dependencies: insureds who claimed but had no evidence on file, usually because they depended on the vendor through a managed service provider or a software supplier. The PRA's 2022 stress test found that three standalone cyber policies in four had no named cloud provider at all, so a gap here is the norm, not the exception.

The second is recovery time. A method that assumes the insured is back when the vendor is back will undercount hours past the waiting period, and 19 July is the clearest case of a fix that came fast while recovery took days. The third is cause: an event that is non-malicious on day one can be reclassified later, or bring malicious follow-on activity with it, as CISA warned within hours. Each gap points at a specific change: an evidence source to add, a recovery assumption to raise, a cause rule to write down.

The named list a replay starts from, with evidence and terms on every row

A replay is also the cheapest way to evaluate any accumulation tool before buying it: ask the vendor to run your last real event against your in-force book and compare. What to ask of each kind of tool is covered in three methods compared on one vendor event, and the first hour of a live event in cloud outage scenario analysis.

Questions people ask

Is there an official estimate of insured losses from the CrowdStrike outage?

No. CISA, the House Homeland Security Committee, Treasury and the FCA described the event's cause, scope and lessons, but none published an insured-loss figure. Estimates in circulation come from commercial modelling firms and brokers.

How many devices did the CrowdStrike outage affect?

CISA's alert passed on Microsoft's estimate of 8.5 million Windows devices, which Microsoft said was less than one percent of all Windows machines. Mac and Linux hosts were not affected.

What is system failure coverage in cyber insurance?

It is cover for business interruption caused by an unplanned, non-malicious failure of systems, as opposed to a cyber attack. When it extends to providers the insured depends on, it is the cover that responds to an event like 19 July 2024; many policies include it only for the insured's own systems, or not at all.

Why did the outage last longer for some businesses than others?

The vendor's fix was deployed on 19 July, but crashed Windows machines had to be repaired, and CISA reported a USB-based recovery tool on 21 July. Organisations with many affected endpoints were down for as long as their own recovery took, which is what a waiting period is measured against.

How often should an insurer replay a past event?

After every material vendor event, and at least once a year on the largest past one. Each replay tests the dependency data and the recovery and cause assumptions; findings should change versioned assumptions, signed by the portfolio manager.

Can a replay use what we learned from the claims?

Only on the comparison side. The estimate side must use evidence and wording dated before the event, or the replay measures hindsight rather than the method.