Endpoint Detection and Response — EDR vs XDR vs MDR vs SIEM

EDR is software on a device that records what happens on it — processes started, command lines, registry and file changes, network connections — and detects patterns in that record. The recording is as important as the detection: it is what allows someone to reconstruct afterwards what an attacker actually did, which antivirus alone cannot support.

They answer different questions. Antivirus asks whether a file is known to be malicious and blocks it, which is valuable and cheap. EDR asks what happened on this machine and keeps enough detail to reconstruct it. Prevention without recording means that when something does get through — and eventually something does — you have no way to establish what it reached. Modern endpoint products usually do both; the distinction is about which capability you are actually paying for.

EDR is a technology that watches endpoints. XDR is a platform that correlates endpoint telemetry with other sources such as network, identity, email and cloud. MDR is a service — people who operate the technology, investigate what it produces and respond. The first two are things you buy; the third is someone doing the work. You can have MDR delivered on top of EDR alone, or on top of a genuinely broad XDR, and those are very different services sold under the same three letters.

A SIEM collects logs from anything that produces them, retains them and correlates them. Its strengths are breadth and evidence — it will hold the audit trail an investigation needs, including from systems no agent can reach. Its weakness is that it has no opinion and takes no action. Detection tools decide; a SIEM records. Most mature setups run both, and our managed SIEM page covers that side.

Which telemetry sources they will actually ingest for you. Not which product they use — which sources. A service watching only endpoints cannot detect an intrusion that runs entirely through your identity provider or your cloud tenant, no matter how good its endpoint tooling is. The grid above shows five real attacks and which sources would have seen each one; three of the five never meaningfully touch an endpoint.

Increasingly, yes, and it is the main reason endpoint-only coverage has become risky. Stolen session tokens replayed from an attacker’s own browser, OAuth consent abuse, mailbox rules that hide replies, and valid credentials used through legitimate remote access all leave clear traces in identity, cloud and email logs, and almost nothing on a managed laptop. Nothing needs to execute for significant damage to occur.

There is no standard, which is the honest answer. Some products correlate endpoint, network, identity, email and cloud genuinely. Others are endpoint tools with a couple of extra connectors and a newer name. Ask any vendor for the specific list of sources ingested in your environment, and compare that list rather than the category label.

There are always some: servers under strict change control, unsupported or legacy operating systems, network appliances, OT and industrial equipment, and contractor or unmanaged devices. It matters because that set is precisely where an attacker prefers to operate. The answer is usually network and identity telemetry covering what the agent cannot reach, plus a documented, accepted gap where even that is not possible.

Usually per endpoint or per user per month, sometimes per ingested data volume where a SIEM sits underneath. The variables that move it are how many telemetry sources are ingested, retention length, and how much response authority you grant. Compare quotes on the same source list — two MDR quotes covering different telemetry are not comparable numbers even when the per-endpoint price looks similar.

Commonly host isolation, killing a process, disabling an account and blocking a hash or domain. Each should be a named item on a written list with a stated authority level, agreed before go-live. “Response included” is not an answer — it is the phrase that hides the difference between a provider who acts at 3 a.m. and one who telephones you and waits.

Yes, and it is a common arrangement. Where you have already licensed a capable platform, the sensible engagement is people and process on top of it rather than a rip and replace. What we would want to establish first is which sources it covers and which it does not, because that determines whether anything else needs adding alongside it.

Managed SOC is the whole security operations function — monitoring, detection, investigation, reporting and the contract around all of it. This page is about the detection layer underneath: which technologies collect what, and therefore what any service built on them can possibly see. Many organisations buy MDR first and a fuller SOC engagement later, which is a reasonable order.

It is a separate discipline and we treat it as one rather than folding it into a detection product. Detection is automated and reactive; hunting is a person asking a question nobody wrote a rule for. Both are worth having and they are not substitutes — see threat hunting.

Deployment is quick; tuning is not, and tuning is what decides whether the service works. Expect a noisy first few weeks while normal behaviour on your estate is learned, then a steady fall in false positives as detections are adjusted. A provider who does not describe this phase honestly is either not doing it or has not run a deployment recently.