Some time ago I posted an article about the differences between a good EDR product and a legacy AV. As we can see, AV products are not relevant anymore, but still more than 50% of companies use them as their main endpoint protection solution. Ok, so we know that AV is obsolete, so the next question is: which EDR product should we choose as our solution? As in any market, there are a lot of competitive products. The problem is that on paper they all look great — similar claims, same buzzwords. E/XDR can provide a lot of capabilities like in-house automation, access to threat intelligence modules (TIM), vulnerability management, and many more. But in general, a good EDR should be effective, should generate as few false positives as possible, and should be as easy as possible to use. Ok, so how to choose the right one? Simple — evaluate some chosen products and pick the best one. That’s theory, but in practice it’s an illusion. Why?
Effectiveness
To find out effectiveness we need to generate scenarios close to the real world — techniques actually used by threat actors. It requires a lot of effort to create such an environment and, what is more important, relevant resources — people who are familiar with attack techniques and can simulate similar scenarios in an isolated setup. In reality, who can do that? Majority of companies in the Polish market cannot. They simply do not have the knowledge to do that. What usually happens instead is that EDR is tested on one or two endpoints, sometimes even on an admin laptop, without any network visibility or proper telemetry. That’s not a test — that’s a demo.
False Positives
Measuring false positives is even more difficult than measuring effectiveness. Each environment is different — systems, processes, and user behavior vary too much to simulate. The only real way to measure it is to install the product in a production environment, but that’s no longer a PoC — it’s a production evaluation, only for brave people who don’t care too much about business impact. In some cases, there is a safer middle way — limited deployment on so-called canary endpoints or test users. A small group of machines that behave like normal users but are under control, with additional monitoring. This way you can see how much noise the product generates without real business risk. Still, even this needs planning and time, and that’s usually missing.
Ease of use
This is the only thing that can actually be identified during evaluation. You can click through the console, open a few dashboards, configure some detection rules. It looks nice and feels simple to use, but what we really test here is configuration, deployment, and basic management. Most teams stop there because it’s easy and gives quick results.
To make an EDR evaluation real, you need skills, time, and courage to measure what really matters — detection and noise, not UI color. That’s the main problem — we don’t test protection, we test presentations. Real validation takes effort, skills, and time, and that’s exactly what’s missing in most projects. EDR testing today is mostly illusion. Few can do it right, and even fewer try. I’ll get back to this topic later — proper testing deserves its own story.