EDR / Concepts and Key Features

Endpoint detection and response (EDR) collects and analyzes activity on PCs and servers to identify threats and support investigation and actions such as device isolation. Rather than examining only whether a file is malicious, it connects processes, communications and changes to establish what happened and how far the impact extends.

What EDR does and how it differs from antivirus

An endpoint is a device where data and applications are used, such as an employee’s laptop or a business server. EDR typically combines a device sensor or agent with centralized management and analysis. Check supported operating systems and coverage for servers and virtual environments against the product and contract.

Antivirus focuses on preventing and blocking malware execution; EDR emphasizes visibility into device activity and breach investigation and response. However, modern antivirus also uses behavioral and cloud analysis, so “antivirus uses signatures, EDR uses behavior” is an inaccurate dividing line. Both capabilities may be integrated into one product. Microsoft’s endpoint security overview describes next-generation antivirus and EDR as distinct, complementary capabilities.

PowerShell, for example, is a legitimate administration tool. Unexpected execution by a document application followed by communication with an unfamiliar address creates a reason to investigate. Examine the executable path, command line, account and subsequent activity together rather than judging by a program name. Even that combination does not by itself confirm a compromise.

What information does EDR collect and correlate?

The activity data collected for security analysis is called telemetry. The following are typical examples, not a guarantee that every product records every item on every device.

• Processes: executable paths, execution times, command lines and parent-child relationships. A process tree shows which application launched another.
• Files: creation, modification, execution and file hashes help trace suspicious files and affected paths. A hash identifies or compares a file; the value alone does not establish maliciousness.
• Network: linking processes with destination addresses and ports supports communication analysis. Connection records do not necessarily reveal complete traffic contents or all data that was exfiltrated.
• System changes: changes to the Windows registry or startup configuration can help investigate persistence. Available data differs by operating system.
• Account activity: logins and execution accounts can be correlated with other activity. Organization-wide authentication and email records may require additional logs or integrations.

A timeline and process tree help distinguish initial execution from later changes. However, Microsoft’s EDR overview explicitly says it is not an audit log of every operation. Missing evidence does not prove normal activity: check collection settings, sensor health, retention and additional logs.

Key detection, investigation and response capabilities

Product names vary, but EDR generally combines the following capabilities. Automation, approval requirements and available actions depend on the operating system, license and policy.

• Detection and prioritization: behavioral analysis and threat intelligence generate alerts. Grouping related alerts into an incident helps investigate impacts across devices. High severity does not remove the need to verify the evidence.
• Investigation and hunting: timelines, process trees and searches help establish cause and scope. Analysts can also hunt for the same file hash or communication destination on other devices.
• Containment: possible actions include network isolation, stopping a process and quarantining a file. File quarantine prevents execution; device isolation restricts network communications. Their targets and operational effects differ.
• Action records: record who requested an action and whether it succeeded, failed or remains pending. Clicking a button or triggering an automated policy is different from confirming completion.

Device isolation can limit spread but also interrupt remote access and business services. Check how management connectivity is preserved, restrictions involving virtual private networks (VPNs) or proxies, and the release procedure. Consult the relevant product documentation, such as Microsoft’s device response actions guide.

Example: investigating a suspicious document alert

This hypothetical workflow concerns an alert that a document application launched a scripting tool and contacted an external address. It is not a real incident report or a product test; adapt it to your approved incident response procedures.

1. Verify the target and time. Record the device, user, alert time and time zone, and confirm that the sensor is sending current data. Compare device identifiers to avoid investigating a different machine with the same name.
2. Connect the execution context. Examine the document application, child processes, command line and destinations on the timeline. Compare them with user activity and administrative change records to assess legitimate automation. Do not run suspicious files on a business PC.
3. Contain according to risk. If malicious activity continues or spread is likely, the responsible team should assess business impact and choose actions such as isolation. Preserve necessary evidence and verify action outcomes and failure reasons.
4. Investigate the wider scope. Search other devices for the same files, destinations and behavior, and correlate authentication and email records. An absence of alerts on one device does not prove that accounts and other systems are safe.
5. Verify recovery and recurrence. After removing the cause, applying necessary patches and account measures, and validating recovery, release isolation through the approved process. Check service operation and further alerts, and record the basis for decisions.

The outcome should be more than a closed alert. Document the evidence, affected devices and accounts, actions taken and remaining uncertainties so another responder can continue the work.

Limits and problems EDR does not solve

Uninstalled or stopped sensors, connectivity failures and short retention periods create investigation gaps. Legitimate administration can trigger alerts, and attacks can be missed. Excessive exclusions reduce visibility; manage their scope, justification and review date.

Isolation or file deletion does not retrieve stolen data or automatically restore encrypted files. EDR does not replace patching, least privilege, multifactor authentication (MFA) or backups. The CISA, FBI and partner ransomware guide (PDF) also recommends isolated backups, recovery testing and incident response planning.

People are still needed to investigate alerts and make decisions. If internal capacity is limited, assess an external managed detection and response (MDR) service. Define monitoring hours, action authority, incident handoff and recovery responsibilities in the contract. Buying EDR software does not automatically include those operational services.

What to check before deployment

Look beyond product lists and detection-rate claims to whether your organization can operate the system. Validate the following in a small, authorized test environment to identify gaps before rollout.

• Coverage: compare your PC and server inventory with supported operating systems and versions. Verify sensor health and last communication, not just installation.
• Business impact: check CPU, memory and disk use, latency and conflicts alongside actual business applications. Review coexistence requirements for other security products.
• Investigation data: verify collected fields, search and retention periods, export methods and log integrations. Because command lines and user information may be included, review access permissions and data storage locations.
• Action authority and recovery: define who approves isolation or termination and how critical servers are handled. Use vendor-provided safe tests to check alert generation, notification, action status and release from isolation.
• Operating cost: include alert review staff, training, additional log storage and external services alongside licensing. Named owners and handoff procedures turn detection into an actual response.