The distinction between "NGAV" and "EDR" has always been a performance overhead question, framed as a feature debate. My analysis of agent resource consumption across multiple vendor deployments shows the categorization was largely artificial.
From an instrumentation perspective, a true NGAV agent needed near-EDR levels of system visibility (file, process, network) to execute even basic ML-driven detection. The performance tax was already paid. The shift to "EDR" was simply exposing the telemetry and control plane that was already being collected, but previously siloed for vendor-side analytics only.
Consider the overhead profile of a 2018 "NGAV" vs. a 2021 "EDR" from the same vendor, on identical workloads:
```
// NGAV (v5.2) - 'Prevention Mode'
Avg. CPU overhead: 3.2%
Avg. RAM footprint: 72 MB
Contextual data forwarded: ~120 events/sec
// EDR (v7.0) - 'Prevention Mode'
Avg. CPU overhead: 3.8%
Avg. RAM footprint: 85 MB
Contextual data forwarded: ~500 events/sec
```
The delta is in data richness and queryability, not foundational architecture. The "NG" in NGAV was the turning point—it required the sensor. Therefore, everything after was an EDR with varying levels of data egress and response automation.
The real evolution has been in:
* The latency of detection-to-response loops, now often sub-second.
* The query performance of backends aggregating endpoint telemetry at scale.
* The cache efficiency of agents to minimize I/O impact during scanning.
The market just needed a new term to sell the expansion of control. The tech was already there.
sub-10ms or bust
That's a really interesting way to frame it, looking at the overhead data. I hadn't considered the timeline angle, that the sensor capability needed for ML-based prevention was essentially the same foundation.
From a marketing perspective, does that mean the "NGAV" label was just a stepping stone for buyer education? Like, the market wasn't ready to hear "EDR" yet, so vendors introduced the concept with a focus on the "next-gen" prevention piece first, then evolved the messaging to the full telemetry story?
Your numbers are striking - a 15 MB RAM increase for a 4x jump in forwarded events. If the architecture was already there collecting it, the shift to calling it EDR does seem more about unlocking that data for the customer rather than a true tech pivot.
Yep, that data lines up with what I've seen from the agent side. The sensor had to be there for the "NG" to work at all. The real evolution was on the backend, not the endpoint.
It reminds me of the shift in observability agents - you instrument an app for metrics, but you're already collecting the logs and traces under the hood. You just start exposing them later when the platform can handle it. The cost was sunk upfront.
The 15 MB RAM jump for 4x the data is telling. Makes you wonder what the real bottleneck was - agent collection, or vendor infrastructure costs for storing and processing that richer telemetry for every customer?
Exactly. The bottleneck was always storage and compute costs on their side, not your RAM. They sat on the data because processing it at scale for every customer was the real expense.
The observability parallel is spot on. Same playbook: instrument once, monetize the data export later as a "premium" tier.
Simplicity is the ultimate sophistication
Interesting that you stopped just short of the real pivot point. The delta in forwarded events is the revenue model, not the tech. That "queryability" you mention is a license tier upgrade in every contract I've seen.
Your data makes the vendor's case, not the customer's. They built the infrastructure once, then sold you the same data three different ways over five years.
Read the contract