EDR/XDR Fundamentals: CrowdStrike vs SentinelOne vs Defender

MDM tells you a device is configured correctly. EDR tells you whether something bad is happening on it right now. The two are complementary halves of endpoint security: configuration management hardens the device, while endpoint detection and response watches the device for the attacks that get through anyway. As a GRC Engineer, you need to understand EDR well enough to evaluate whether an organization's detection coverage is real — deployed everywhere, monitored, and tied to a response process — or whether it is a logo on a contract with blind spots no one is watching.

This lesson explains what EDR does that antivirus does not, untangles the EDR / XDR / MDR acronyms, and compares the three platforms you will see most: CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint.

From antivirus to EDR

Traditional antivirus was signature-based: it compared files against a database of known-bad hashes and patterns. If the malware was in the database, AV caught it. If it was new, repacked, or fileless, AV missed it. Attackers learned to evade signatures trivially — change a byte, the hash changes, the signature no longer matches.

Endpoint Detection and Response is behavior-based. Instead of asking "is this file on my bad list?", EDR asks "is this process doing something an attacker does?" It continuously records endpoint telemetry — process creation, command-line arguments, network connections, file and registry changes, parent-child process relationships — and looks for malicious behavior: a Word document spawning PowerShell, PowerShell reaching out to an unknown IP and downloading a payload, a process trying to dump credentials from memory, mass file encryption in seconds.

That behavioral lens is why EDR catches things AV cannot:

• Fileless attacks that live in memory and abuse legitimate tools (PowerShell, WMI, living-off-the-land binaries) leave no file to signature, but their behavior is anomalous.
• Novel malware with no known signature still has to act — and the actions trip behavioral detections.
• Hands-on-keyboard intrusions where a human attacker moves laterally show up as a chain of suspicious behaviors even when no single step is obviously malware.

Crucially, EDR adds the R — response. When something is detected, EDR can act: kill the process, quarantine the file, isolate the host from the network (so it can talk only to the EDR console), and on some platforms roll the device back to a pre-attack state. And every bit of telemetry is retained, so responders can reconstruct exactly what happened — the forensic timeline.

EDR vs XDR vs MDR

These three letters cause endless confusion. They are not competing products so much as different scopes and operating models.

• EDR — Endpoint Detection and Response. Scope is the endpoint: laptops, servers, sometimes mobile. It detects and responds to threats on the device.
• XDR — Extended Detection and Response. Scope is broader than the endpoint: it correlates endpoint signals with identity, email, cloud, and network telemetry into a single detection surface. The value is correlation — a suspicious login (identity) plus a malicious process (endpoint) plus an odd outbound connection (network) become one linked incident instead of three disconnected alerts.
• MDR — Managed Detection and Response. Not a different technology but a different operating model: a vendor's security team monitors and responds on your behalf, 24/7. Organizations without a round-the-clock SOC buy MDR so that a 3 a.m. alert gets a human response instead of sitting in a queue until morning.

The decision logic is about who watches and how broadly:

SCOPE  ───────────────────────────────────────────────►  broader

 EDR                         XDR
 ┌─────────────────┐         ┌──────────────────────────────┐
 │ Endpoint only   │         │ Endpoint + identity + email  │
 │ detect/respond  │         │ + cloud + network, correlated│
 └─────────────────┘         └──────────────────────────────┘

 WHO OPERATES IT  ─────────────────────────────────────►

 Self-managed                 MDR (vendor-operated)
 ┌─────────────────┐         ┌──────────────────────────────┐
 │ Your team gets  │         │ Vendor SOC monitors 24/7 and │
 │ the alerts      │         │ responds on your behalf      │
 └─────────────────┘         └──────────────────────────────┘

 A small company often = XDR delivered as MDR (broad scope, someone else watches).

The three platforms

You will most often encounter CrowdStrike, SentinelOne, and Microsoft Defender. All three are credible, modern EDR/XDR platforms; the differences are about ecosystem fit, operating model, and cost.

For a GRC Engineer, the product name on the contract matters far less than three operational questions, which apply to all three:

1. Coverage — what percentage of endpoints actually run the agent, and which are missing? Servers? Contractors' machines? The forgotten build server? Gaps in coverage are gaps in the control.
2. Operating model — self-managed or MDR? Who responds at 3 a.m.?
3. SKU/license reality — "we have CrowdStrike" or "we have Defender" can mean wildly different capabilities depending on the module or license tier. Confirm which features are actually licensed and enabled.

Coverage is the control

The most common real-world finding is not "the EDR is bad" — it is "the EDR is not everywhere." An endpoint without the agent is invisible to detection. Servers get forgotten. A contractor's laptop never gets enrolled. A new VM image ships without the agent baked in. Each one is a hole an attacker can operate inside without tripping a single alert.

So the headline metric is deployment coverage: agents installed and reporting, as a percentage of the known asset inventory. This is why endpoint security depends on having an accurate asset inventory in the first place — you cannot measure coverage against a fleet you have not fully enumerated. When you evaluate an EDR program, the first question is not "which vendor?" but "show me the coverage report against the asset inventory, and explain every gap."

What an auditor wants to see

When detection-and-response controls are tested (SOC 2 CC7.1–CC7.4 on monitoring and incident handling; ISO 27001 controls on logging, monitoring, and response), the EDR program should be able to produce:

• Coverage report — agents deployed vs asset inventory, with gaps explained.
• Alerting and routing — where alerts go and who owns them, including off-hours.
• Response evidence — for real detections, the timeline: detected at, triaged at, contained at, resolved at.
• Tuning and review — that someone reviews detections and tunes noisy rules, so the system is actually watched rather than drowning in ignored alerts.

These artifacts are reusable across frameworks and feed directly into the incident-response work in later phases. The EDR is both a security control and an evidence generator — which is why understanding it pays off twice.

What to carry forward

EDR moved endpoint defense from "match known-bad files" to "detect malicious behavior and respond." XDR widens the lens to correlate across identity, email, cloud, and network; MDR adds a human team to operate it around the clock. CrowdStrike, SentinelOne, and Defender are all strong — what determines whether the control is real is coverage against the asset inventory, a response model that covers off-hours, and clarity about which features are actually licensed.

Next, you will look at the other half of endpoint hardening: configuring the operating system itself against CIS Benchmarks, so there is less for the EDR to catch in the first place.