EDR vs XDR vs SIEM vs MDR: what each does and which a mid-size company needs

EDR vs XDR vs SIEM vs MDR: the differences in short

EDR (endpoint detection and response) uses an agent on each workstation and server to record activity, detect attacks and contain them on that machine. XDR (extended detection and response) extends an EDR with sensors for email, network, identity or cloud, usually from the same vendor, and correlates their alerts into one incident. A SIEM (security information and event management) collects logs from any source, correlates them and keeps them for investigation, and SOAR (security orchestration, automation and response) automates response steps on its alerts. MDR (managed detection and response) is a service in which a provider’s analysts watch the alerts and respond.

OMB memorandum M-22-01 (2021); ASD and CISA guidance on SIEM and SOAR (May 2025); NIST SP 800-92 (2006). The XDR and MDR rows and the strength and limit columns are our assessment.

The NIST CSF 2.0 document of 26 February 2024 does not mention SIEM, EDR or XDR, and its abstract says: “The CSF does not prescribe how outcomes should be achieved.” EDR is one way to meet DE.CM-09, the monitoring of computing hardware and software, and NIST SP 800-61 Rev. 3 (April 2025) names SIEM and SOAR as example tools for event analysis and correlation (DE.AE-02 and DE.AE-03). Under DE.AE-08, incidents are declared when events meet the defined criteria, and the incident response plan should name who decides.

What EDR records on workstations and servers, and where it stops

OMB memorandum M-22-01, which set EDR requirements for US federal agencies in October 2021, says EDR combines “continuous monitoring and collection of endpoint data” with “rules-based automated response and analysis capabilities”. In the ASD and CISA list of priority logs for SIEM ingestion, the EDR data includes signature detections, network connections and ports, recently run commands and unsuccessful attempts to access files. For containment, NIST SP 800-61 Rev. 3 suggests letting tools act automatically in some cases, for example by “transferring a compromised endpoint to an isolated remediation network”.

EDR sees only the machines that run its agent. Firewalls, switches, BMCs and most OT controllers run none, and ransomware that encrypts virtual machines from the hypervisor, as our guide to hardening ESXi and vCenter against ransomware describes, works outside the guests where the agents run. An agent that goes silent is a signal as well: the ASD and CISA practitioner guidance says organisations “should have processes in place to identify when systems have stopped generating logs and telemetry”.

EDR vs XDR: more sensors, mostly from one vendor

EDR covers the endpoints, while XDR starts from an EDR and adds sensors for email, network, identity or cloud, usually from the same vendor, so one incident shows the activity across those layers. We found no definition of XDR from NIST, ENISA or ASD. ENISA’s technical implementation guidance (June 2025) lists “Endpoint detection and response (EDR) and Extended Detection and Response (XDR) tools in place” among the examples of evidence for automated monitoring under point 3.2.2 of Implementing Regulation (EU) 2024/2690.

Depending on the product, one incident can lead to a response in each layer: removing a phishing message from mailboxes, disabling the account and isolating the laptop that opened the attachment. Other vendors’ sources arrive through integrations, so ask which ones it ingests, in what detail, and whether they feed the correlation or are only stored.

SIEM vs XDR and EDR: every log source, kept for investigation

The guidance on SIEM and SOAR that ASD’s Australian Cyber Security Centre and CISA published with partners on 27 May 2025 defines a SIEM as “a type of software platform that collects, centralises, and analyses log data”. NIST’s SP 800-92 of 2006, whose 2023 revision is still a draft, describes a SIEM server that “correlates events among the log entries, identifies and prioritizes significant events, and initiates responses to events if desired”.

The difference from XDR lies in the sources and the time span. A SIEM takes logs from any system, whether an XDR covers it or not: firewalls and VPN gateways, domain controllers and the directory service, hypervisors and vCenter, backup servers, cloud and SaaS audit logs. The ASD and CISA list of priority logs starts with EDR and network devices, then domain controllers and the directory service, in what it calls “a loose prioritisation by category of data source”, and its authors “discourage logging for the sake of logging”. A GPU server’s utilisation counters and XID errors, covered in our guide to GPU server monitoring with DCGM, belong in operational monitoring, while its sign-ins and administrator actions belong in the SIEM.

For organisations new to detection, the practitioner guidance suggests as a starting point “a minimum of one year for logs that record administrative and security-related events” and 90 days for informational logs. Implementing Regulation 2024/2690 requires the providers it covers to keep and back up logs for a predefined period, protected from unauthorised access or changes (Annex point 3.2.5), and our article on NIS2 incident reporting deadlines shows why the reports depend on them.

The executive guidance notes that most SIEM pricing models “are based on the quantity of data the SIEM ingests” and expects “multiple personnel” to work on implementing a SIEM or SOAR “on a full-time basis”. For an IT team of four, that decides whether the SIEM runs in-house, at a provider or later.

How SOAR automates the response, and when to add it

In the executive guidance’s words, a SOAR “automates some of the response to detected cyber security events and incidents” through predefined playbooks, such as isolating the source of an event in the network. The guidance says that, in general, “it is necessary to properly implement a SIEM and ensure it is accurately alerting cyber security events and incidents before implementing a SOAR”, and that automated actions “do not replace human incident responders but can complement them”.

For 200 to 2,000 staff we would start with a few tested steps in the SIEM or XDR rather than a separate platform: enrich the alert, open a ticket, isolate a laptop on a high-confidence detection and call the person on duty. Amid many false positives, the practitioner guidance warns, teams “may experience ‘alert fatigue’ and miss or delay their response”.

MDR vs EDR: a service that watches the tools

MDR is a managed service in which the provider’s analysts watch the alerts of an EDR or XDR, the provider’s own or yours, investigate them and respond with actions agreed in advance, such as isolating a host. Some contracts add SIEM alerts or cloud audit logs. We found no definition of MDR from NIST, ENISA or ASD either, so each contract sets the scope. NIST SP 800-61 Rev. 3 lists outsourcing a security operations centre (SOC) to a managed security services provider as one way to staff incident response, next to an internal team. NIS2 lists managed security service providers in Annex I, and Implementing Regulation 2024/2690 covers them.

The executive guidance recommends checking whether providers offer high-quality monitoring and incident response at all hours, have a good security posture, and are located in, or have offices in, other countries. In the contract it points to “the degree of visibility the service provider will provide back to your organisation” and “the division of responsibility and liability for detecting and responding to cyber security incidents”. It also notes that in-house staff can query users and start the response, while “outsourcing can produce visibility gaps, work duplication, and communication difficulties”. Ask, too, what happens to the telemetry and detection rules when the contract ends.

Who watches the alerts at night and at weekends

Alerts arrive at night and at weekends as well, and unless someone receives them, assesses them and acts, the tools only record what happened. For the digital providers it covers, Implementing Regulation 2024/2690 requires that “in case of an alarm, a qualified and appropriate response is initiated in a timely manner” (Annex point 3.2.4), with monitoring run “either continuously or in periodic intervals, subject to business capabilities” (point 3.2.2). Other companies can use the same wording as a reference.

Four arrangements can cover the hours outside the working day, alone or combined. Own staff on call can work when alerts are few and well tuned and the person on duty may isolate a server without asking. An MDR service handles the EDR or XDR alerts within its contract, while a SOC service working on the SIEM takes in more sources and needs access to your logs. Automated containment suits narrow, high-confidence cases, such as a laptop that starts encrypting file shares, with a review the next morning.

The choice is the company’s, and it needs writing down: who receives which alert, who stands in, who may isolate a server or disable an account at night, and whom that person calls when an incident looks significant. Those names and rights belong in the incident response plan, and our guide to what an incident response plan must contain sets out the rest.

Our cyber resilience service includes an incident response plan with roles, actions and deadlines. Tell us who receives security alerts today at night and at weekends, and what that person is allowed to switch off.

Typical combinations for 200 to 2,000 staff, and checks before you buy

The table is our recommendation for typical estates; sector, NIS2 status, OT and team size can shift it.

Our recommendation; the staffing remark follows ASD and CISA’s executive guidance on SIEM and SOAR (May 2025).

Before you buy or renew, check the following.

1. List every system and the tool that sees it, and mark the gaps, such as hypervisors, BMCs, OT gateways and SaaS admin portals.
2. Set retention per log type and compare it with what the EDR or XDR console keeps.
3. Alert when a log source or an EDR agent stops sending, and monitor the log platform from outside. For the providers it covers, the implementing regulation lists the stopping and pausing of logs among the events to log where appropriate (point 3.2.3), and point 3.2.6 requires synchronised time sources where feasible and redundant monitoring and logging systems, monitored “independent of the systems they are monitoring”.
4. Test detection with techniques from MITRE ATT&CK, MITRE’s public knowledge base of adversary tactics and techniques, in the “regular and repeated exercises” the practitioner guidance recommends.

Central logging and device posture are also steps in our zero trust roadmap for mid-size companies.

EDR/XDR on workstations and servers and event centralisation in a SIEM are part of our cyber resilience service. Send us your headcount, sites and current log sources through the form below.

What we do

Firewalls, intrusion prevention (IPS), email and web traffic filtering, EDR/XDR on workstations and servers and event centralisation in a SIEM, on Trend Micro, Cisco and other vendors’ solutions, are part of our Cyber Resilience service, with engineering by our partner Vixen.UNO. The same service includes an incident response plan with roles, actions and deadlines. Who acts on alerts outside office hours is a decision your company makes, and the plan should name that person and a deputy. The first call is free of charge, and the technical assessment gives you a risk map and a prioritised action plan, at a price fixed before work begins.

FAQ