Overview

Endpoint Detection and Response (EDR) is a security solution category focused on detecting, investigating, and responding to threats on endpoint devices. Unlike traditional antivirus (AV) which relies primarily on signature-based detection, EDR continuously monitors endpoint telemetry to identify suspicious behaviour, provides deep visibility into attacker activity, and enables rapid containment and remediation.

EDR emerged in response to the limitations of signature-based AV against sophisticated threats: fileless malware, living-off-the-land (LotL) attacks, and advanced persistent threats (APTs) that evade static detection entirely.

Core Capabilities

Modern EDR platforms are built on four foundational capabilities.

Continuous Telemetry Collection — EDR agents capture a continuous stream of endpoint activity: process creation, network connections, file operations, registry modifications, and memory events. This telemetry is stored locally or streamed to a central platform for analysis and historical investigation.

Threat Detection — Multiple detection techniques operate simultaneously across the telemetry stream. Behavioural analysis identifies sequences of events that match known attack patterns (TTPs) mapped to MITRE ATT&CK. Machine learning models detect anomalies against baseline endpoint behaviour. Threat intelligence correlation matches observed indicators against external feeds. Custom rules (YARA, Sigma, or platform-native) address organisation-specific requirements.

Investigation and Forensics — When an alert fires, EDR provides the historical context needed to reconstruct the full attack chain. Analysts traverse process trees, examine parent-child relationships, review file write sequences, and replay network activity across a configurable retention window — typically 30–365 days.

Containment and Response — EDR enables direct response actions from the analyst console without physical access to the endpoint: network isolation, process termination, file quarantine, registry key removal, remote shell access, and custom remediation scripts.

Architecture

Endpoint Agent

The EDR agent is a lightweight component installed on each monitored endpoint. It operates at or near kernel level to intercept system calls and capture telemetry with minimal performance overhead. Implementation varies by platform:

• Windows — kernel minifilter drivers, ETW (Event Tracing for Windows) providers, user-space API hooks
• Linux — eBPF probes, kernel modules, auditd integration
• macOS — Apple Endpoint Security Framework (replacing deprecated kernel extensions)

Local on-agent detection enables immediate response without cloud round-trip latency — critical for fast-moving ransomware and lateral movement scenarios.

Telemetry Sources

Detection Engines

The platform applies multiple detection layers simultaneously:

• Rules-based engine — evaluates structured detection logic against the event stream in near-real-time, mapped to MITRE ATT&CK techniques
• Behavioural AI/ML — models trained to identify anomalous process graphs, network communication patterns, and command sequences deviating from established baselines
• Threat intelligence matching — IoC feeds from internal and external sources enriched against each event: file hashes, IPs, domain names, certificate fingerprints
• Deception — canary files, registry keys, and credentials that generate high-fidelity alerts when accessed; no false positives by design

Detection and Response Lifecycle

Telemetry flows from the endpoint through a multi-stage pipeline:

1. Collection — Agent sensors capture raw system events at kernel and user-space level
2. Normalisation — Events are parsed into a common schema and enriched with context: user identity, process lineage, network geolocation, asset metadata
3. Correlation — Related events are grouped into activity chains spanning configurable time windows. A single attack may generate thousands of individual raw events; correlation assembles them into a coherent narrative.
4. Detection — Behavioural rules, ML models, and threat intelligence matching evaluate activity chains and assign confidence scores
5. Alert Management — Matched activity is surfaced as a detection with severity scoring, MITRE ATT&CK technique mapping, and recommended response actions
6. Triage — Alerts are prioritised: low-confidence findings are auto-resolved, medium-confidence route to the analyst queue, high-confidence trigger immediate response workflows
7. Investigation — Analysts drill into the event timeline and process tree to determine scope, root cause, and patient zero
8. Response — Containment and remediation actions are executed directly from the console

Detection Techniques

MITRE ATT&CK Alignment

Modern EDR platforms map every detection to the MITRE ATT&CK framework, providing a structured taxonomy of adversary techniques across the full attack lifecycle. This alignment enables:

• Coverage gap analysis — identify which ATT&CK techniques have no detection coverage in your environment
• Detection tuning by tactic — disable or refine detections within a specific category (e.g., suppress noisy Execution sub-techniques in a specific process context)
• Purple team exercises — target specific ATT&CK techniques to validate detections fire as expected against real adversary tooling

Behavioural Indicators of Compromise (BIoCs)

Unlike static IoCs (file hashes, IP addresses that attackers rotate frequently), BIoCs describe patterns of behaviour that are structurally difficult for attackers to modify without abandoning their technique entirely:

• cmd.exe spawned as a child of winword.exe — macro execution pattern
• powershell.exe with base64-encoded parameters making outbound network calls
• lsass.exe memory read by an untrusted process — Mimikatz-style credential dumping
• Lateral movement via psexec, wmic /node:, or remote scheduled task creation
• New service registration followed by immediate start from a non-standard binary path

Living-Off-the-Land (LotL) Detection

LotL attacks abuse legitimate system tools (LOLBins) to avoid introducing malicious binaries, making signature-based detection impossible. EDR detects LotL by evaluating the context and argument patterns of legitimate system tools:

Response Capabilities

Network Isolation

Network isolation is the most common immediate response action. The agent blocks all network traffic except EDR management plane communications, severing the compromised endpoint from the network within seconds of detection — across a global fleet if needed. Most platforms maintain the management connection even under full isolation, allowing continued remote investigation and eventual release without requiring physical access.

Active Response Actions

EDR vs Traditional Antivirus

Deployment Considerations

Coverage Policy

EDR is only effective where the agent is deployed. Define and enforce coverage across:

• Workstations and laptops — primary attack surface for phishing and credential theft
• Servers — production, development, and build systems. CI/CD pipeline compromise is a significant supply-chain threat vector.
• Cloud VMs — most EDR vendors provide cloud-native Linux agents for AWS, GCP, and Azure workloads
• OT/ICS systems — EDR support is limited; assess vendor guidance carefully and prioritise passive monitoring over active agents where stability requirements prohibit instrumentation

Performance Impact

EDR agents impose measurable overhead on I/O-intensive workloads (build servers, databases, video rendering). Mitigate by:

• Configuring process and directory exclusions for known-safe, high-throughput operations
• Monitoring agent CPU and memory consumption in a representative environment before broad rollout
• Preferring path-plus-process-specific exclusions over broad directory exclusions that create visibility gaps

Exclusions as a Risk Decision

Every exclusion is a potential blind spot — one that sophisticated attackers actively probe for. Treat exclusions as explicit risk acceptance decisions:

• Document each exclusion with a business justification, technical owner, and expiry date
• Prefer narrow exclusions (specific process + specific path) over broad ones (entire drive letters or system directories)
• Review all exclusions on a quarterly cadence and remove any without a current operational justification

Integrations

Evaluation Criteria

1. Detection efficacy — Prioritise independent test results: MITRE ATT&CK Evaluations, AV-Comparatives EDR reviews, SE Labs assessments. Evaluate detection breadth, not just prevention rate.
2. False positive rate — A noisy platform trains analysts to ignore alerts. Evaluate signal-to-noise in a trial against your real environment, not a vendor-controlled demo environment.
3. Telemetry depth and retention — How far back can you query raw telemetry? Can analysts write ad-hoc queries across the full event stream, or only view pre-aggregated summaries?
4. Response latency — Time from detection trigger to available containment action. Matters significantly for fast-moving ransomware scenarios.
5. Platform coverage — Windows, macOS, Linux (kernel versions supported), containers, cloud VMs. Confirm coverage for your entire estate before purchasing.
6. Integration ecosystem — Evaluate the quality of the API and native connectors for your SIEM, SOAR, and ticketing system — not just their existence.
7. Managed detection and response (MDR) — Does the vendor offer 24/7 SOC coverage backed by the platform? Useful if the internal team cannot provide continuous coverage.

Best Practices

Deploy before you need it. EDR telemetry is only available from the moment the agent is installed — there is no retroactive visibility. Deploy broadly and early. A fully covered estate of 500 endpoints outperforms a 5,000-endpoint estate with 60% coverage for investigation purposes.

Enable all telemetry sources. Resist pressure to reduce telemetry volume to cut storage costs. Every disabled telemetry source is a category of attack that becomes invisible. Storage for EDR telemetry is cheap relative to the cost of an undetected breach.

Tune on false positives, not detection coverage. When reducing alert volume, suppress specific noisy rule instances rather than disabling entire detection categories. A precisely tuned rule is far more valuable than a silenced category.

Use threat hunting proactively. EDR platforms are not purely reactive tools. Proactively hunt for known IoCs and behavioural patterns across the fleet using the query interface — especially after public threat intelligence reports of campaigns targeting your sector.

Validate your detections regularly. Use adversary simulation tools (Atomic Red Team, CALDERA, or a commercial breach-and-attack simulation platform) to verify that detection coverage fires as expected. An untested detection rule is an assumption, not a security control.

Integrate with your SOC workflow. EDR alerts that arrive in a separate console — disconnected from your SIEM and ticketing system — will be missed. Ensure detections flow into the same triage queue analysts use for everything else.

Review exclusions quarterly. Exclusions accumulate over time and are rarely revisited. Build a scheduled review into your security programme cadence and remove anything lacking a documented, current operational justification.