CyphrQ
Menu

Breach Detection Tools Explained: EDR, XDR, NDR, MDR and SIEM

What EDR, XDR, NDR, MDR, SIEM and deception tools each see, what they miss, and the telemetry and staff they need. With CISA and NIST sources.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

Breach detection tools watch your systems for signs an attacker is already inside. EDR watches laptops and servers, NDR watches network traffic, a SIEM collects logs from everything, XDR bundles several of these, deception plants traps, and MDR is a service where someone else runs the watching for you. No single tool sees everything. Each has blind spots, and every one of them needs people to act on what it finds.

That last point is the one most buying decisions skip. A detection tool produces alerts. Whether those alerts stop a breach depends on who reads them, how fast, and what they're allowed to do next.

What are breach detection tools, and why is there no single one?

An attacker inside your network leaves traces in three places: on devices (programs starting, files changing), on the network (connections, DNS lookups, data moving), and in logs (logins, permission changes, cloud admin actions). Each tool family specialises in one or two of those.

  • EDR (endpoint detection and response): software on each laptop and server that records what runs and can isolate the machine.
  • NDR (network detection and response): sensors that analyse network traffic for suspicious patterns.
  • SIEM (security information and event management): a platform that collects and correlates logs from many sources.
  • XDR (extended detection and response): a vendor's combination of endpoint, network, identity, email or cloud signals in one console.
  • MDR (managed detection and response): a service. An outside team watches your alerts around the clock and responds.
  • Deception: decoy systems, accounts or files that no legitimate user should touch, so any use is a strong signal.

Where these fit in the bigger picture of how breaches unfold is covered in our data breach lifecycle hub.

What does EDR see on laptops and servers, and what does it miss?

EDR is the closest thing to a security camera on each machine. It records which programs start, what they launch, which network connections they open and which files they change. When something looks wrong, an analyst can isolate the device from the network with one action while keeping remote access to investigate.

The US government treats it as a baseline. OMB memorandum M-22-01 (8 October 2021) notes that Executive Order 14028 "directs the Federal Government to adopt a robust Endpoint Detection and Response (EDR) solution", and set up a government-wide EDR initiative run by CISA.

What EDR misses:

  • Devices it can't be installed on. Firewalls, VPN appliances, routers, printers, building systems, many cloud services.
  • Machines without the agent. Old servers, unmanaged laptops, contractors' devices.
  • Activity that looks legitimate. An attacker using a stolen admin password through normal tools may look like an admin.

In practice: in a red team assessment of a US critical infrastructure organisation, published as CISA advisory AA24-326A on 21 November 2024, CISA found the organisation "was too reliant on its host-based tools and lacked network layer protections, such as well-configured web proxies or intrusion prevention systems". It "completely lacked any EDR solution in a legacy environment", and "Network defenders failed to detect red team activity in the organization's Windows environment."

The edge-device gap shows up in incident data too. Mandiant's M-Trends 2026 describes threat groups that "deliberately target edge and core network devices, such as virtual private networks (VPNs) and routers, that typically lack standard endpoint detection and response (EDR) telemetry." Why those devices are targeted, and what replacing them changes, is in our ZTNA vs VPN guide.

What does NDR add by watching network traffic?

NDR looks at traffic instead of devices. It can see a device with no agent talking to a server it never contacts, a workstation scanning its neighbours, or large volumes of data leaving at 3am. That makes it the natural complement to EDR's blind spots.

NIST's long-standing reference, SP 800-94, Guide to Intrusion Detection and Prevention Systems (February 2007), describes four classes of system: network-based, wireless, network behavior analysis software, and host-based. In my reading, modern NDR descends from the network-based and network behavior analysis classes. NIST notes that a 2012 draft revision "never became a final publication and has been retired", so the guide is old; use it for concepts, not product features.

What NDR misses:

  • Encrypted content. Most traffic is encrypted, so NDR usually sees who talked to whom, when and how much, not what was said.
  • Traffic it can't reach. Cloud-to-cloud traffic, home workers off the VPN, and segments without a sensor.
  • What happened on the device. NDR sees the connection, not the program that made it.

Is XDR a product or a promise?

XDR is a vendor category, not a standard. Research for this post found no definition of XDR from NIST, CISA or another standards body. Vendors use the term for platforms that combine their own endpoint agent with some mix of identity, email, cloud and network signals, then correlate them in one console.

The appeal is real: fewer consoles, correlation done for you. The questions to ask are practical. Which data sources does it ingest from other vendors, and at what depth? Can you export the raw data? What happens to detection if you replace one component? An XDR that only sees its own vendor's products is EDR with extras.

What does a SIEM do that EDR and NDR don't?

A SIEM is the central store and correlation engine for logs from everything: identity systems, firewalls, VPNs, cloud admin consoles, email, applications, and the EDR and NDR alerts themselves. It's often the only place where a login from an unusual country, a new admin account and a large file download can be joined into one story.

The 2025 joint guidance led by CISA and Australia's ASD, Guidance for SIEM and SOAR Implementation (27 May 2025), is blunt about the effort. Its executive guidance says "Most SIEM pricing models are based on the quantity of data the SIEM ingests", and that executives "should expect that multiple personnel will need to work on implementing the SIEM and/or SOAR on a full-time basis."

Choosing log sources, retention and who runs the platform are big enough topics for their own post: SIEM vs SOC separates the platform from the team that operates it.

What is MDR, and when do you buy detection as a service?

MDR is detection and response as a service. The provider runs or connects to your EDR (and often other sources), triages alerts, investigates, and takes agreed response actions such as isolating a device or disabling an account.

It suits organisations that can't staff a security team around the clock, which is most of them. The trade-offs:

  • Response authority. Agree in writing what the provider can do without calling you first.
  • Coverage. Many services centre on their own endpoint agent. Ask what they see from identity, cloud and edge devices.
  • Data. Who keeps the raw telemetry, for how long, and whether you get it back.
  • Responsibility. Regulators hold you, not the provider, accountable. The US SOC regulations guide shows how NYDFS and PCI DSS put that in writing.

The trade-offs between running detection yourself, outsourcing it, or splitting the work are weighed in the SIEM vs SOC guide.

Where do deception tools and honeytokens fit?

Deception plants things no legitimate user needs: a fake admin account, a decoy file share, a dummy credential left in memory, a fake API key in a code repository. Nobody should ever touch them, so any touch is a high-confidence alert with very few false positives.

Deception is cheap to start and easy to forget. Decoys need to look real, stay current, and be wired to an alert someone will see.

How do the breach detection tools compare side by side?

Tool What it sees What it misses What it needs
EDR Processes, command lines, file and registry changes, per-process network connections on managed devices Devices without the agent: edge appliances, legacy systems, unmanaged and IoT devices Agent on every supported device, tuning, someone to triage and isolate
NDR Traffic patterns, east-west movement, DNS, connection metadata, data volumes Encrypted content, unsensored segments, cloud-to-cloud traffic, which program made a connection Sensors at chokepoints and in cloud, a baseline of normal traffic
SIEM Logs from identity, cloud, network, endpoints and apps, correlated over time Anything not sent to it, anything past retention Log onboarding, parsing, detection rules, storage budget, analysts
XDR One vendor's mix of endpoint, identity, email, cloud and network signals Sources the vendor doesn't integrate well Commitment to one vendor's stack; check data export
MDR Whatever sources the provider ingests, plus their analysts' judgement Sources outside the contract, business context they lack Clear response authority, onboarding, a named contact on your side
Deception Any interaction with decoys and honeytokens Attackers who never touch a decoy Realistic decoys, upkeep, alert routing

Which breach detection tools should a smaller organisation start with?

A sensible order for a team without a dedicated security staff, in my view:

  1. EDR on every laptop and server you can install it on, ideally monitored by an MDR provider so alerts get answered at night.
  2. Turn on the logs you already pay for: identity provider sign-in logs, email and cloud admin audit logs, firewall and VPN logs. Keep them centrally, even before you buy a SIEM.
  3. A few honeytokens: a decoy admin account and a fake credential, alerting to someone's phone.
  4. NDR or a SIEM when you have someone to own it, not before.

The practitioner guidance makes a parallel point about automation: "investing in the proper implementation of a SIEM platform and achieving effective log analysis is a higher priority than implementing a SOAR". The same logic applies to every tool here. Get the basics working before buying the next layer.

Going deeper: for security and IT teams

Map coverage to techniques, not product categories. For each tool, list the MITRE ATT&CK techniques it can detect in your environment, given the telemetry you actually collect. The fileless intrusion techniques in our living-off-the-land guide, such as T1059.001 PowerShell and T1003 OS Credential Dumping, are good test cases: EDR should see the process chain, the SIEM should see the logon pattern, NDR should see the lateral connection. Gaps show up as techniques where no tool has the data.

EDR telemetry to confirm is on. Process creation with full command line and parent process; network connections attributed to processes; module loads; file and registry changes in persistence locations; script content where the platform supports it. Check whether tamper protection is enabled and whether an agent going silent raises an alert. AA24-326A's legacy-environment finding is the failure mode: a segment where no agent ran at all.

Network telemetry. Flow records at internet egress and between major segments, DNS query logs from your resolvers, proxy logs, and VPN authentication logs. AA24-326A recommends you "Establish a security baseline of normal network traffic and tune network appliances to detect anomalous behavior." Without a baseline, NDR alerts on everything new, which in a changing network means everything.

Edge devices. Since they rarely support EDR, collect what they do emit: admin logins, configuration changes, firmware version, VPN session logs, and the device's own integrity checks where the vendor provides them. Forward them off the device, because an attacker with admin rights on the appliance can clear local logs.

SIEM economics. Because pricing is commonly tied to ingestion volume, decide what to filter before it arrives. Drop verbose debug logs, not authentication events. Which sources deserve the budget first is set out in our SIEM vs SOC guide, drawing on the joint logging guidance.

Deception design. Place honeytokens where an attacker doing discovery will find them: a service account with an attractive name in the directory, a credential in a script on a file share, a cloud access key in a repository. Alert on any authentication attempt or API call using them. Test monthly that the alert still fires.

Testing that detection works. Run benign simulations of specific techniques with written approval, and record which tool alerted, how fast, and whether a human acted. A purple team exercise formalises this. The stakes are measurable: in Mandiant's 2025 caseload, close to half of victims heard about the intrusion from an outside party rather than finding it themselves (internal discovery was 52%).

Questions for vendors and MDR providers: - Which of our asset types can your agent not cover, and what do you recommend for them? - Can we export raw telemetry in an open format, and how long do you keep it? - What response actions will you take without calling us, and in what time? - How do you detect an agent or log source going silent? - Which detections are on by default, and which need tuning by us? - If we leave, what happens to our data and detection content?

A breach detection tools buying checklist

  1. List your asset types: endpoints, servers, edge devices, cloud services, SaaS, OT.
  2. Mark which tool, if any, sees each one today.
  3. Fill the biggest gap first, usually endpoints without EDR or edge devices without logs.
  4. Decide who answers alerts at 3am before you buy anything that generates them.
  5. Confirm you can export your raw data and detection rules.
  6. Add two or three honeytokens this month; they cost almost nothing.
  7. Test detection against a handful of real techniques every quarter.

Key takeaways

  • EDR watches devices, NDR watches traffic, a SIEM correlates logs, XDR bundles a vendor's signals, deception sets traps, and MDR is people running detection for you.
  • Each tool has blind spots. Mandiant notes edge devices such as VPNs and routers typically lack EDR telemetry, and that some groups deliberately target them.
  • In CISA's AA24-326A red team, an organisation that relied too heavily on host-based tools and lacked network protections failed to detect the red team in its Windows environment.
  • The 2025 CISA and ASD guidance says most SIEM pricing is based on the quantity of data ingested, and that implementing a SIEM or SOAR takes multiple personnel working full-time.
  • No standards-body definition of XDR turned up in research for this post; judge it by data sources and export, not the label.
  • Decide who acts on alerts before buying a tool that generates them.

Sources