Building Aegis Sovereign — Our proprietary platform, actively deployed and improving daily. See the platform →
Home/Guides/Self-Hosted EDR Guide
Buyer's Guide

The Self-Hosted EDR &
XDR Buyer's Guide

A practical, vendor-neutral framework for evaluating endpoint detection & response — the real trade-offs of self-hosted vs cloud, the criteria that actually matter, and the questions every vendor should be able to answer.

Updated June 2026 ~9 min read Vendor-neutral
What's inside
  1. EDR vs XDR, briefly
  2. Why self-hosting is back
  3. Self-hosted vs cloud
  4. 10 evaluation criteria
  5. Questions to ask vendors
  6. Decoding the pricing
  7. Deployment-readiness checklist
  8. Making the decision

1. EDR vs XDR, briefly

EDR (Endpoint Detection & Response) watches what happens on laptops, servers and workstations — processes, files, network connections, scripts — and detects and responds to malicious behavior. XDR (Extended Detection & Response) widens the lens, correlating those endpoint signals with identity, network, cloud and email telemetry so an attack that crosses domains is seen as one incident rather than scattered alerts.

In practice the line is blurry, and what matters for a buyer isn't the acronym — it's whether the platform can detect modern attacker behavior, correlate it into a story, and let you respond fast, ideally without a per-seat tax for the privilege.

2. Why self-hosting is back

For a decade the industry pushed everything to vendor clouds. That's reversing for a few concrete reasons:

  • Data sovereignty. Healthcare, finance, government and EU/Canadian organizations increasingly must keep security telemetry inside a jurisdiction — sometimes inside their own walls.
  • The cloud-EDR is itself a target. If your security vendor's cloud is breached, your most sensitive telemetry goes with it. Keeping data local shrinks that blast radius.
  • Cost. Per-endpoint, per-module cloud pricing scales painfully with your fleet. Flat or self-hosted models decouple price from headcount.
  • Air-gapped & OT environments. Manufacturing, utilities and defense often can't phone home to a vendor cloud at all.

3. Self-hosted vs cloud: the honest trade-offs

Neither model is universally "better." Here's the unvarnished comparison:

DimensionSelf-hostedVendor cloud
Data residencyYou control it fullyVendor's regions
Breach blast radiusContained to youShared vendor risk
Pricing at scaleFlat / infra costPer-endpoint, grows
Ops burdenYou run the brain/consoleVendor runs it
Time to first valueHours (deploy infra)Minutes (sign up)
Global threat telemetryFeeds you pull inVendor's proprietary graph
Air-gap / OT supportNativeUsually not possible
Rule of thumb. If data sovereignty, cost-at-scale, or air-gapped environments are real constraints for you, self-hosted wins decisively. If you have a tiny team, no infra appetite, and value a vendor's global telemetry above all, managed cloud may suit you. Many mature teams land on self-hosted with the option to let the vendor host it — keeping ownership while offloading ops.

4. Ten evaluation criteria that actually matter

  • Behavioral detection, not just signatures. Can it catch living-off-the-land (PowerShell, certutil, rundll32) and map detections to MITRE ATT&CK?
  • Real response, not just alerts. Live shell, process kill, host isolation, file quarantine — across the whole fleet, fast.
  • Correlation into incidents. Does it fold a flood of alerts into a handful of real incidents with a timeline and kill-chain?
  • Exposure that means something. Which CVEs are actually running and reachable — not a CVSS list of everything installed.
  • Identity coverage. MFA, conditional access, and visibility into non-human identities (keys, tokens, service accounts).
  • Automation (SOAR). Can you build trigger → condition → action playbooks without professional services?
  • Resilience. Does the agent keep recording during a network outage and reconcile on reconnect?
  • AI-era coverage. Prompt-injection / data-leak inspection and shadow-AI discovery are becoming table stakes.
  • Open data & API. Can you query your own telemetry (e.g. a real query language) and pull data via API? Avoid black boxes.
  • Honest total cost. Base + every module you actually need + overage. Watch for "contact sales" pricing that balloons at renewal.

5. Questions to ask any vendor

Copy these into your RFP. The answers separate marketing from substance:

"Where does our telemetry physically live, and can we keep it entirely on our own infrastructure?"Self-hosted vendors answer instantly; cloud-only vendors hedge.
"Show me one real incident reconstructed end-to-end — process tree, kill-chain, and the response you'd take."Tests correlation, not just alerting.
"What's the all-in annual price for our exact fleet size, with every module we need — in writing?"Flushes out per-endpoint × per-module surprises.
"What happens to detection and recording during a network outage?"Resilience is where many agents quietly fail.
"How are remote response actions authenticated, so a compromised channel can't issue kill/isolate commands?"Signed commands (e.g. ECDSA) are the strong answer.
"Can we cancel and keep our data? Is there any lock-in?"Trust correlates with willingness to let you leave.

6. Decoding the pricing

Most EDR/XDR pricing pain comes from three multipliers stacked together: per endpoint × per module × per year, often hidden behind "contact sales." A fleet that doubles, doubles your bill; turning on identity or exposure is another line item.

When you compare, normalize everything to a single number: all-in annual cost for your real fleet with every capability you need. Then ask what that number looks like at 2× and 5× your current size. Flat-per-org and self-hosted models hold steady; per-endpoint models don't. (Our own take on this is the Kaimz pricing model — unlimited endpoints, never per-seat — but the principle applies to whoever you choose.)

7. Deployment-readiness checklist

Before you roll out any self-hosted EDR/XDR, make sure you have:

  • A host for the brain + console (modest: a few vCPUs, 8 GB RAM to start) behind your reverse proxy.
  • An inventory of endpoints and operating systems to cover (and any air-gapped segments).
  • MFA enabled on the console from day one, with RBAC roles mapped to your team.
  • A pilot group (10–50 endpoints) to validate detections and response before fleet-wide rollout.
  • A couple of response playbooks ready (isolate-on-critical, notify-on-new-admin) to prove automation.
  • A backup/retention plan for the telemetry store that matches your compliance needs.

8. Making the decision

Score each vendor against the ten criteria, normalize the pricing to one all-in number, and weight the answers to the six questions. The right choice is the one that detects real behavior, tells you the story, lets you respond fast, keeps your data where you need it, and doesn't punish you for growing.

If self-hosted is your direction, the fastest way to learn is to deploy a free, full-featured edition against a pilot group and see the telemetry for yourself.

Try it yourself. Kaimz Community is free forever, self-hosted, with unlimited endpoints and every module included. Read the deployment docs → or see the platform →

Next step

Evaluate Kaimz on your own infra

Deploy free More guides