After July 2024, what does your agent update policy actually say?

The CrowdStrike content update on 19 July 2024 took down a large number of Windows hosts worldwide, and it was a defective update rather than an attack. Two years on I want to know what people actually wrote into policy afterwards, not what they said at the time.

Ours now: sensor versions staged N-1 with a 200-host canary ring for 72 hours. What I have never resolved is content channel updates, which are not staged the same way by any EDR vendor I have asked. If you have language in a contract that covers this, I would like to see how it is worded.

We landed in the same place. Sensor N-1, canary ring, and an explicit acceptance that rapid content updates are not under our control. Our reasoning: the whole value of the product is that content ships faster than we could approve it. If we gate that, we are buying a slower product.

What we did add was a tested recovery runbook for mass boot failure, including the BitLocker key retrieval path, because that was the part that actually hurt organisations that day.

MSSP view. We asked every EDR vendor on our list the same question during renewals and got three different answers, none of them contractual. The most honest was the one who said the SLA is on availability of the console, not on the quality of an individual content release.

What we do now is stagger client tenants so no two big clients get a new sensor build in the same 24 hours.

The recovery runbook is the underrated part of this. Detection quality arguments are fun but the organisations that recovered fastest were the ones who could get a technician to a boot prompt with a recovery key. That is an asset management and helpdesk problem, not a security product problem.

Agreed, and that is roughly where I have ended up. I will take the faster content and invest in the recovery path. Thanks both.