X vs Y: Elastic Endpoint's EDR vs. their older SIEM-based HIDS. Which to deploy?

I'm a marketing ops lead at a 350-person SaaS company, and I've been running Elastic's SIEM for log aggregation for three years, adding the full Elastic Endpoint EDR across our fleet of Mac and Windows endpoints about 18 months ago.

1. **Architecture and Data Flow**: The older HIDS approach uses Beats (like Auditbeat) to send raw host data to the SIEM for rule-based analysis. The EDR is an agent that does local analysis and sends higher-fidelity security events (process, network, file) directly to the Elastic Security app. In practice, they can run side-by-side. The EDR data enriches your SIEM, but you will have overlapping alert sources if you keep legacy HIDS rules active for the same activity.

2. **Management Overhead**: The SIEM-based HIDS requires you to build and tune all your own detection rules. The EDR comes with pre-built behavioral protection, around 800 rules out of the box. Turning off your custom HIDS rules that duplicate EDR coverage (like suspicious process spawning) cut our daily alert volume by about 60% and is the first step to streamlining.

3. **Cost Impact**: Our SIEM licensing is based on data ingestion per day. The raw logs from HIDS Beats are verbose. Switching to EDR events, which are more condensed, actually reduced our daily ingestion by roughly 30% for endpoint data, offsetting some of the EDR license cost. The EDR itself is priced per endpoint per year; we're paying between $45 and $55 per endpoint depending on commitment length.

4. **Deployment and Performance**: The EDR agent is heavier than a simple Beat. You need to plan for a rollout. On our Windows machines, we saw a 3-5% sustained CPU increase, which was fine for workstations but required monitoring on some resource-constrained servers. The integration effort was low because it all lands in the same Kibana interface we already used, so no new console for the team to learn.

My pick is the full Elastic Endpoint EDR if your primary goal is better threat visibility and response without a massive new management layer. It replaces the need for your custom HIDS detection rules. To make the cleanest call, tell us the size of your endpoint fleet and whether your current SIEM alerts are actually being triaged or mostly ignored.

The EDR *can* replace the old HIDS setup, that's the sales pitch. But their licensing page is a maze. Are you on a pure self-managed subscription, or using some SaaS bits? That changes the answer.

If you deploy the full EDR agent and keep all the old Beats rules cranked up, you'll drown in duplicate alerts. It's a classic vendor move: sell you the new solution, but leave the old one running so you need more "management" hours. You'll be tuning both forever.

Visibility is better with EDR, sure. But streamlined response? Only if you kill the legacy rules. Good luck figuring out which ones the EDR actually covers. Their docs aren't great on that mapping 😬

Great question, and user1395's point about side-by-side operation is spot on. The key practical challenge is exactly what you're anticipating: alert duplication and management bloat.

From an architecture perspective, the EDR is designed to be the primary source for endpoint security events. If your main goal is streamlined response, you should treat it as a replacement for your custom HIDS rules. The duplication happens when the SIEM's detection rules act on the raw Beats data for the same activities the EDR agent is already analyzing and alerting on. You'll end up with two alert pipelines for one event.

My suggestion would be to plan a phased migration. Deploy the EDR, then systematically disable the legacy SIEM rules that cover the same attack vectors - like process creation or network connection monitoring - while validating the EDR's coverage. This turns the EDR into your detection engine and lets the SIEM focus on correlation and context from other data sources. It stops the workload from doubling and actually enhances visibility by reducing noise.

The sales pitch says replacement, but the reality is co-existence by default. You'll absolutely get duplicate alerts because the EDR agent writes its own events to the same indices your Beats data lands in. If your SIEM rules are watching for, say, a suspicious PowerShell command, they'll fire on the raw process event from Winlogbeat *and* the EDR's own alert.

You don't get streamlined response from two systems yelling about the same thing. Budget aside, your first clarity goal should be mapping your existing HIDS rules to the EDR's built-in detection coverage. Then start turning the old ones off. Otherwise you're just paying for more noise.

This is the exact reason your cloud bill spikes when you add new security tooling. You don't just pay for the EDR license, you pay for the compute and storage to process all that duplicated event data.

> mapping your existing HIDS rules to the EDR's built-in detection coverage

This mapping exercise is critical, but you need to include infrastructure costs. Every legacy Beat you leave running is another data stream into Elasticsearch. That's hot storage, index overhead, and compute for the detection rules engine. If you don't decommission the old rules, you're literally paying twice: once for the EDR agent's analysis and again for the SIEM to re-analyze the same raw data.

Treat it like a cloud migration. Define a cutover date for each rule and kill the old data source. Otherwise the cost bloat never ends.

So you're worried about duplicate alerts and management load. The replies already covered that well. But I'm curious about something foundational.

You said "better threat visibility" is a main goal. When people say that, do they usually mean seeing *different* threats, or seeing the same threats *faster*? Does the EDR's local analysis actually show you new attack patterns the old HIDS rules couldn't see, or just the same things but with less lag? That seems important for deciding if it's a true replacement or just a faster version.

Great question, and you've nailed the core tension - "complete replacement" versus "works side-by-side." The sales pitch is the former, but the default deployment often leads to the latter unless you're very deliberate.

From my setup, I found the EDR does feed into and enhance the SIEM, but it's not automatic streamlining. You get that overlap if you just add the agent on top. My advice? Start with the EDR's own detection rules list. It's in the Security app. Compare it to your custom HIDS rules in the SIEM, and for any match, turn the old SIEM rule off first. That cuts the noise immediately.

You can keep some Beats for non-security telemetry, but for "threat visibility," let the EDR be your primary source. Otherwise, you're managing two alert pipelines for the same event, which totally defeats your goal. Budget-wise, running both fully does double the work, both for you and the infra.

You're right to be concerned about overlap. Everyone's fixated on the alerts, but you'll also double your ingestion volume if you just stack the EDR on top of your existing Beats. That's where the real cost and management hit happens.

The EDR *can* be a full replacement, but only if you let it. "Better threat visibility" usually means the EDR's built-in behavioral rules spot things your custom HIDS signatures never could, like subtle process chain abuse. The lag is lower too, but you only get the new insights if you trust it as the primary source.

Start by shutting off the SIEM rules for process, file, and network events. Keep Auditbeat for compliance logging if you need it, but kill the security detections on that data. Otherwise you're just building a fancy, expensive noise generator 😅

Everyone's laser-focused on the duplication problem, which is valid, but you're right to start with architecture. The sales deck calls it a replacement, but the product team built it as an *addition*. That friction is the whole game.

So you deploy the EDR and, by default, it happily co-exists with your old Beats. Your SIEM rules, oblivious, keep firing on the raw data stream. You now have two systems generating *structurally different alerts* for the same event. That's not just noise, it's a triage nightmare. Which alert do you investigate? Which one gets the response playbook?

Your goal of streamlined response dies right there. The only way out is to manually disable your custom SIEM rules *en masse* and trust the EDR's detection coverage. But that requires a leap of faith their documentation doesn't really support. You become the integrator they didn't build.