How EDR Works: Detection, Investigation, and Response

EDR works by turning endpoint activity into evidence that a security team can investigate and act on. A sensor records selected events from supported devices. A central service stores and analyzes that telemetry. Detection and investigation tools connect related activity, while response controls let an authorized person contain a device or remove a confirmed threat.

The product can support these steps, but it does not supply the operating process. A business still needs complete device coverage, healthy sensors, named alert owners, response authority, and a way to test that the full chain works.

The three main parts of an EDR system

1. The endpoint sensor

An agent or built-in operating-system component observes activity on each enrolled workstation or server. Depending on the product and operating system, it may record process starts, command lines, file changes, registry or configuration changes, user logons, loaded modules, network connections, and security-control status.

Collection is selective. An EDR product does not record every byte of every action, and collection can differ between Windows, macOS, and Linux. The sensor filters, summarizes, and sends security-relevant events to the service. It may also enforce local prevention policies and retain some capability when the device is temporarily offline.

2. The analysis and storage service

The central service receives telemetry, adds device and user context, and applies several detection methods. These may include known indicators, vendor intelligence, behaviour rules, statistical models, and sequences associated with attacker techniques. The service can group related alerts into an incident and let an analyst search for the same indicator or behaviour across enrolled devices.

Retention matters. If detailed telemetry is kept for only a short period, an investigation discovered weeks later may have less evidence. Ask what is stored, at what level of detail, for how long, in which region, and whether retention or advanced hunting requires another licence.

3. The analyst console and response controls

The console presents alerts, device timelines, process relationships, files, users, and related events. An analyst uses that context to decide whether activity is benign, suspicious, or confirmed malicious. Available actions may include isolating a device from the network, stopping a process, quarantining a file, collecting an investigation package, or starting a scan.

The most disruptive actions should have clear authority and a reversal procedure. Isolating the wrong server can interrupt the business. Waiting for approval during an active ransomware event can also increase harm. The response policy should distinguish workstations, critical servers, executive devices, and systems where automatic containment would be unsafe.

The EDR lifecycle

1. Collect activity. A sensor on a supported device records selected process, file, user, configuration, and network events.
2. Enrich and analyze. The service adds asset, user, reputation, and threat context, then applies indicators, rules, and behavioural detections.
3. Create and correlate alerts. Related signals may be grouped into an incident so an analyst can see a sequence instead of isolated events.
4. Investigate context. The analyst reviews the device, user, process tree, command lines, files, network destinations, and similar activity elsewhere.
5. Contain and remediate. Under an approved policy, responders may isolate a device, stop a process, quarantine a file, or use a connected identity tool to disable an account.
6. Recover and improve. The incident team restores safe operations, records evidence, closes coverage gaps, and adjusts detections or policies when needed.

A process-tree example

Suppose a user opens a spreadsheet received by email. The spreadsheet starts a scripting interpreter, which runs an encoded command, connects to an unfamiliar internet address, and creates a scheduled task.

Looking at the network connection alone may not prove malicious activity. The process tree gives the analyst a chain:

email client → spreadsheet → script interpreter → network connection → scheduled task

The analyst can inspect the command line, file hash, destination, signed-in user, and surrounding events. A search can show whether the same command or destination appeared on other devices. The response decision may be to isolate the laptop, preserve evidence, reset an exposed account through the identity process, and investigate the original message.

This is why EDR is more than a malware scanner. It preserves relationships between events. It also shows an important limit: the endpoint view should be combined with email and identity records when the incident crosses those systems.

How EDR detects suspicious activity

EDR products commonly use several methods at once:

• Indicators: a file hash, internet address, domain, certificate, or other value is associated with known malicious activity.
• Behaviour rules: a sequence such as an office application launching a script, a process accessing credential material, or a tool changing recovery settings matches a detection rule.
• Reputation and intelligence: the platform evaluates file prevalence, publisher information, age, and vendor threat intelligence.
• Behaviour analytics: the service identifies activity that differs from expected use or resembles attacker techniques.
• Custom detections: the customer or service provider defines a query or rule for risks specific to the environment.

Each method can produce false positives or miss harmful activity. An uncommon administration script may look suspicious. A new attacker technique may not match an existing rule. Tuning should preserve the evidence, document why an alert is suppressed, limit the scope and duration of exclusions, and require review.

Response actions and their tradeoffs

Response action	Purpose	Main caution
Isolate device	Restrict network communication while preserving approved management access	Can interrupt work or a critical service; test release procedures
Stop process	End an active suspicious process	The process may restart or be part of a required application
Quarantine file	Prevent a file from running or being accessed	Validate business impact and retain evidence as required
Collect investigation package	Gather logs and device evidence for analysis	Collection can contain sensitive business or personal information
Run endpoint scan	Look for known threats and related artifacts	A clean scan does not prove the endpoint is safe
Search other endpoints	Determine whether an indicator or behaviour appears elsewhere	Results depend on coverage, retention, query quality, and operating-system support

Containment is not recovery. After an affected device is isolated, the incident process still needs to determine scope, remove persistence, address exposed credentials, restore or rebuild systems safely, monitor for recurrence, and record what changed.

What EDR cannot see or guarantee

EDR has no endpoint evidence from an unenrolled or unsupported device. It may have limited visibility into network appliances, personal devices, software-as-a-service activity, email delivery, or identity-provider events unless other tools are connected. Encrypted traffic may show a destination without showing the contents. Privacy settings and operating-system restrictions can also affect collection.

An EDR product does not make every decision automatically. Detection quality, available evidence, sensor health, operating-system support, product configuration, retention, and the response process all affect the outcome. Review documentation for the exact product and licence, then verify essential capabilities in a controlled test.

Endpoint telemetry can contain usernames, device names, command lines, file paths, internet destinations, and other sensitive information. Canadian organizations should involve privacy and legal owners when deciding collection, access, retention, cross-border processing, and incident-record handling. The appropriate requirements depend on the organization, data, jurisdiction, and contracts.

What to test

Run a controlled exercise that confirms:

1. The sensor installs without breaking a representative business application.
2. Coverage and sensor health are visible for workstations, servers, and remote devices.
3. A safe test event reaches the console with the expected process and user context.
4. The alert reaches a named owner during business hours and through the after-hours path.
5. The analyst can search for the same test indicator across enrolled devices.
6. Device isolation works for a test endpoint and the team can release it safely.
7. Evidence, decisions, timestamps, and approved exceptions are recorded.

Keep the result as an acceptance record. Revisit it when the product, licence, operating system, deployment method, service provider, or critical application changes. Track device inventory against EDR coverage so a successful test on one laptop does not hide missing servers or remote endpoints.

Frequently asked questions

Does EDR record everything an employee does?

No. It records selected security-relevant endpoint events according to the product, operating system, policy, and licence. Because that data may still be sensitive, define access, retention, and acceptable use.

Can EDR work when a laptop is offline?

Many agents can continue some local prevention and collection, but cloud analysis, alert delivery, and remote response may be delayed until the device reconnects. Confirm and test the exact product behaviour.

Does EDR automatically isolate infected devices?

It can in some configurations, but automatic isolation is a policy choice. Define which detections and device types qualify, who is notified, and how a mistaken isolation is reversed.

How is EDR different from a SIEM?

EDR is centred on endpoint telemetry, investigation, and response. A SIEM collects and analyzes logs from many systems. They can be integrated, but each needs a defined role so alerts and response actions are not duplicated or lost.

For the category definition, see the NIST EDR glossary. Return to the EDR pillar guide, then compare EDR and antivirus, use the deployment checklist, and plan connections with the EDR integration guide.

Need to test whether your endpoint process works in practice? Talk to Quantm.