The short version. On July 19, 2024, a single security agent took down millions of machines at once. Not because it was hacked, but because it updated. Every endpoint agent that runs in the kernel and updates fast is, by construction, a correlated single point of failure across your whole fleet. The industry has spent thirty years measuring detection and almost none measuring this. It is time to treat the security agent itself as a risk, and to ask whether it needs to be in the kernel at all.
The day the defense became the outage
The CrowdStrike incident is the clearest lesson the industry has had in years, and most postmortems drew the wrong conclusion from it. A content update to a kernel-mode driver hit a bad state and crashed roughly eight and a half million Windows machines into boot loops, worldwide, within minutes. Airlines grounded. Hospitals diverted. Payment systems stopped. No attacker was involved. The security software did this to itself, and because it lived in the kernel and updated on a fast channel, every machine that trusted it failed at the same time.
That last clause is the whole story. The damage was not that one agent had a bug. Software has bugs. The damage was that the same agent, in the same privileged place, with the same rapid update, was running on millions of hosts, so a single bad change became a single global failure. This is not a CrowdStrike property. It is a property of the architecture that nearly every endpoint vendor shares.
Why kernel agents are correlated failure by design
A modern EDR earns its visibility by living in the kernel. From there it sees every process, every file, every network connection, before user space can hide anything. That is genuinely powerful, and it is why the design won.
It also means three things are true at once, and together they are a time bomb:
- A bug in the agent can crash the whole machine, not just the agent. Kernel code that faults takes the operating system with it. There is no sandbox around it.
- The agent updates constantly, because detection content has to keep up with threats. Fast updates are a security requirement and an availability hazard in the same breath.
- The same agent runs everywhere, which is the point of a fleet. Monoculture is efficient right up until the moment it is catastrophic.
Put those together and you have a system where one bad update, one malformed content file, one edge case in a parser, becomes a correlated outage across every host that shares the agent. We have decades of systems research on exactly this failure mode: drivers are the leading cause of OS crashes, and correlated failure across a monoculture is how small faults become large ones. The security industry optimized hard for detection and treated availability as someone else's problem. July 2024 was the bill coming due.
The question almost nobody asks
For thirty years the endpoint conversation has been about one axis: does it catch the threat. Detection rate, block rate, MITRE coverage. All real, all necessary, all incomplete. The missing axis is the one the CrowdStrike outage measured for us: what does this agent cost me in availability, and what is the blast radius when it, not the attacker, is what goes wrong.
You should be able to answer, for any endpoint tool you run:
- If the agent hits a bad update, does the machine keep working, or does it blue-screen?
- How correlated is failure across the fleet? Can one change take everything down at once?
- Does the agent fail open into "unprotected but running," or fail closed into "protected but dead"?
Most teams cannot answer these, because their vendor never framed them as questions. That is the gap.
The driverless alternative
Here is the part the industry treats as heresy: you may not need to be in the kernel to get the telemetry. Every major operating system now exposes a sanctioned, in-kernel event stream to user space. Apple's Endpoint Security framework on macOS, eBPF on Linux, ETW on Windows. These give you the process, file, and network events you actually need, sourced from the kernel, without you shipping a kernel driver of your own.
Move the agent to user space and the risk math inverts. A bug in a user-space agent crashes the agent, and the operating system keeps running. The blast radius of a bad update collapses from "the whole machine" to "the security tool restarts." You give up nothing on the events that matter for detection, and you remove the single worst failure mode of the entire category.
There is a second design choice that follows naturally. If the agent can be silenced or killed, that silence should itself be an alarm. A cryptographically fresh, out-of-band heartbeat means that an attacker who kills the agent does not go dark. They trip a bounded-latency alert precisely by succeeding. You concede that a determined adversary can stop the agent, and you make stopping it loud.
How Nemesis Blue is designed
Nemesis Blue is an endpoint defense platform built driverless from the start. It sources its telemetry from the operating system's own sanctioned streams, Endpoint Security on macOS, eBPF on Linux, ETW on Windows, so a fault in the agent does not take the host with it. Detection runs on a gradient-boosted model over EMBER-style features with signed, versioned model bundles, so content updates are verifiable artifacts rather than unsigned channel files pushed into the kernel.
Two design commitments come straight out of the CrowdStrike lesson. First, the agent is built to fail into "running but unprotected" rather than "protected but crashed," because for most of the fleet an unmonitored hour is survivable and a global outage is not. Second, tamper is treated as an alarm: an out-of-band heartbeat means that killing the agent is itself a detectable event, not a blind spot.
We are candid about the trade. A driverless design gives up a narrow set of kernel-only enforcement primitives in exchange for removing correlated-outage risk. For most organizations that is a good trade, and the ones for whom it is not should make that choice with the availability cost in front of them, not hidden.
What to put in your next endpoint evaluation
Add the questions the last thirty years left out:
- Blast radius. If a content update is bad, what is the worst case, one agent restart or a fleet-wide outage?
- Kernel footprint. Does the vendor ship its own kernel driver, or source telemetry from the OS's sanctioned streams?
- Fail direction. On agent failure, does the machine keep running?
- Update integrity. Are detection updates signed, versioned artifacts you can roll back, or opaque channel files?
- Tamper visibility. If the agent is killed, do you find out, and how fast?
Detection is table stakes. After July 2024, availability is the axis that separates a security tool from a liability. The safest agent is the one that cannot take the patient down while trying to cure them.
Nemesis Blue is the driverless endpoint defense platform from Nemesis Labs: kernel-sourced telemetry without a kernel driver, signed model bundles, and tamper-as-alarm. nemesislabs.xyz