EDR Guide: Deployment, Tuning and Operations

Endpoint detection and response (EDR) only protects the endpoints it is installed on, in the mode it is configured for, watched by people who act on what it reports. Most EDR failures in real incidents are not product failures: the sensor was missing from the server that mattered, running in detect-only mode, disabled by an attacker with local admin rights, or its alert sat unread in a queue of noise. This guide covers how EDR works, how to deploy it with full coverage, how to set a policy baseline, how to run response and protect the sensor itself, and how to measure whether it is working. It is written for security engineers, SOC leads and endpoint teams, and it uses Microsoft Defender for Endpoint and Elastic Defend documentation as worked examples without recommending any product.

Key takeaways

Coverage beats features. An unmanaged or inactive device is a blind spot no detection logic can fix, so reconcile the sensor inventory against the asset inventory every week.
Detect-only is a stage, not a destination. Run a pilot in audit or detect mode, then move to blocking and automated response, with a documented rollback.
Tamper protection is mandatory. Attackers disable or modify security tools (ATT&CK T1685) before encrypting or exfiltrating; lock settings and exclusions centrally and alert on every change.
Tuning decides whether alerts are read. Joint CISA, NSA and FBI guidance warns that untuned EDR may not alert on living off the land activity; tune with narrow suppressions, never broad exclusions.
The EDR console is a privileged system. Live response and isolation rights can run code on every endpoint, so treat console roles and API credentials as tier 0 access.

What EDR does and where it stops

An EDR platform has four parts: a sensor on each endpoint that records process, file, registry, network and authentication events; a telemetry pipeline to a cloud or on-premises back end; analytics (behavioural rules, machine learning, threat intelligence and custom queries) that raise alerts; and response actions such as killing a process, quarantining a file, isolating a host or opening a remote shell. The defining difference from traditional antivirus is that EDR keeps a searchable record of what happened, so an analyst can reconstruct a process tree after the fact and hunt across the estate.

Capability	Primary job	Typical data	Gap it leaves
Antivirus / NGAV	Block known and suspicious files before or at execution	File verdicts, scan results	Little history; weak against hands-on-keyboard attackers using built-in tools
EDR	Record endpoint behaviour, detect, investigate and respond	Process lineage, command lines, file, registry, network and logon events	Only sees hosts with a healthy sensor; no view of network devices or SaaS
XDR	Correlate EDR with identity, email, cloud and network signals	Cross-domain incidents	Depth varies by integrated source; still depends on endpoint coverage
MDR	A provider operates detection and response for you	Whatever the underlying tools collect	Response authority and context about your business must be agreed in writing
SIEM	Central log retention, correlation and compliance reporting	Logs from many sources, including EDR alerts or raw telemetry	No native prevention on the endpoint

See the Next-Generation Antivirus (NGAV) Guide, the XDR Guide and the MDR Guide for those layers. MITRE D3FEND describes the defensive techniques EDR implements, including Process Spawn Analysis (D3-PSA), Process Lineage Analysis (D3-PLA), System Call Analysis (D3-SCA) and File Access Pattern Analysis (D3-FAPA).

Deployment architecture and coverage

Coverage targets: every Windows, macOS and Linux workstation and server, virtual desktops (including non-persistent images), cloud virtual machines and, where supported, container hosts. Domain controllers, hypervisor management servers, backup servers and jump hosts come first, because attackers go there first.
Sensor health states: products distinguish healthy devices from those that stopped reporting. Microsoft Defender for Endpoint, for example, marks a device Inactive after more than 7 days without signals and reports Misconfigured: impaired communications or Misconfigured: no sensor data when a device talks to the service but sends only partial telemetry. Treat each of these as a coverage incident, not a dashboard statistic.
Coexistence with another antivirus: two products both blocking in real time cause performance problems and instability. Microsoft documents three Defender Antivirus modes (active, passive, disabled) and recommends passive mode, not removal, when a non-Microsoft product is primary; on Windows Server passive mode is set with the ForceDefenderPassiveMode registry value before onboarding, and Get-MpComputerStatus reports AMRunningMode. Each product must exclude the other's binaries, and that is one of the few exclusions every estate genuinely needs.
Remediation behind a third-party antivirus: Microsoft's EDR in block mode lets Defender remediate post-breach behavioural detections while in passive mode. It honours antivirus exclusions but not indicators, which matters when you tune.
Network path: sensors need outbound access to the vendor's service endpoints, often through a proxy. A proxy change that breaks this silently produces impaired communications across a whole site.
Telemetry destination: decide early whether raw telemetry, alerts only, or both go to the SIEM. Raw telemetry is costly but supports long retention and cross-source hunting. See the SIEM Guide and the Endpoint Telemetry Guide.

Phased rollout

Inventory and scope. Export the asset inventory (CMDB, MDM, cloud accounts, directory) and agree the target list, including servers owned by other teams and operational technology that must be excluded or handled separately.
Prepare the platform. Define device groups by risk tier and function, role-based access for the console, proxy and firewall rules, and integration with the SIEM and ticketing system.
Pilot ring (2 to 4 weeks). Deploy to IT, security and a sample of each major application owner in detect or audit mode. Record performance complaints, application conflicts and alert volume per rule.
Baseline tuning. Resolve pilot issues with the narrowest control available (alert suppression or a scoped allow indicator), document every exclusion with an owner and expiry, and fix noisy custom rules. See the EDR Tuning and Exclusions Management Guide.
Enable protection. Turn on blocking, tamper protection and automated remediation for the pilot, then confirm with a controlled test (for example the industry-standard EICAR test file and a scripted benign behaviour test) that detections fire and actions run.
Expand by ring. Workstations broadly, then general servers, then critical servers with application owners on standby. Hold each ring for a defined period and a defined error threshold before the next.
Close the gaps. Reconcile sensor inventory against the asset list, chase the remainder, and record formal risk acceptances for devices that cannot run a sensor.
Rollback plan. For each ring, keep a tested way to switch a device group back to detect-only or to remove a faulty policy within minutes, and agree who may authorise it. Never roll back by disabling tamper protection estate-wide.

Policy baseline

Names differ by product; the table uses generic terms with Microsoft examples where they help.

Setting	Recommended baseline	Why
Prevention mode	Block, after pilot	Detect-only lets ransomware finish while the alert waits
Cloud-delivered protection	On	Microsoft notes the default policy is Not configured and recommends turning it on
Tamper protection	On for all devices, managed centrally	Stops local changes to real-time protection, behaviour monitoring and exclusions
Local admin merge of exclusions	Disabled (Intune: Disable local admin merge; GPO: Configure local administrator merge behavior for lists)	Stops a local administrator adding their own exclusions
Automated investigation and remediation	Full automation for most groups	Microsoft advises against turning it off because of a false positive; use allow indicators instead
Attack surface reduction or behaviour rules	Audit first, then block per rule	Some business apps trigger them; per-rule exclusions are narrower than global ones
Potentially unwanted applications	Block, audit on a subset if noisy	Catches bundled adware and remote tools
Host isolation	Allowed for SOC tier 2 and above	Containment in minutes, with a documented release process
Live response	Restricted role, unsigned scripts blocked, sessions logged	It is remote code execution on every endpoint

Detection engineering and triage

Know where the vendor stops: the joint CISA, NSA and FBI guidance on living off the land states that these techniques may avoid triggering EDR products, and that administrators often request permissive configurations for built-in binaries. Write custom detections for your own environment: unusual parents of powershell.exe (T1059.001), proxy execution through signed binaries (T1218), and access to LSASS memory (T1003.001).
Baseline first: the same guidance tells defenders to baseline installed tools, normal command lines and privileged account behaviour, and to avoid overly broad rules such as CommandLine=*. See the Living off the Land Guide.
Classify every closed alert: true positive, benign true positive (expected activity) or false positive. Classification is the raw material for tuning and for measuring rule quality.
Hunt in the telemetry: a scheduled hunt programme finds what rules miss. See the Threat Hunting Guide and the KQL for Threat Hunting Guide.
Route alerts by severity and asset tier: a medium alert on a domain controller outranks a high alert on a kiosk. See the SOC Guide.

Response operations

Action	Use when	Precautions
Kill process / quarantine file	Single confirmed malicious artefact	Collect the file and process tree first; check the same hash elsewhere
Host isolation	Hands-on-keyboard activity, ransomware precursors, credential theft	Agree in advance which hosts need owner approval (for example clinical or production control systems)
Live response / remote shell	Evidence collection and targeted remediation	Log every command; actions taken this way may not be undoable
Block indicator (hash, certificate, domain)	Stop recurrence estate-wide	Scope to device groups where possible; note any quota limits
Restore from quarantine / undo	Confirmed false positive	Restore across all affected devices, then fix the root cause

Write these into the incident playbooks so analysts do not decide containment authority at 3 a.m. See the Incident Response Guide and the Ransomware Response and Recovery Guide.

Protecting the sensor

Ransomware operators and intrusion sets routinely try to blind EDR before acting. In ATT&CK v20 this sits under the Defense Impairment tactic as T1685 Disable or Modify Tools, with related techniques such as T1685.001 Disable or Modify Windows Event Log and T1685.005 Clear Windows Event Logs. Kernel-level attacks that load a vulnerable signed driver to kill the sensor rely on T1068 Exploitation for Privilege Escalation. See the EDR Evasion and Defence Guide and the Top 10 EDR Evasion Techniques.

Tamper protection on and centrally managed: in Defender, Group Policy changes to tamper-protected settings are ignored, and every tampering attempt raises an alert. Check state with Get-MpComputerStatus (IsTamperProtected).
Protect exclusions too: Defender only tamper-protects exclusions when a device is managed by Intune only or Configuration Manager only, runs platform 4.18.2211.5 or later and has local admin merge disabled; the registry value TPExclusions = 1 confirms it.
Remove local admin rights: most tampering needs administrator or SYSTEM. See the Endpoint Privilege Management Guide.
Block vulnerable drivers: enable the operating system's vulnerable driver blocklist and application control where feasible (D3FEND Executable Allowlisting, D3-EAL).
Alert on silence: a sensor that stops reporting minutes before a ransomware event is a signal. Alert when a high-value server drops out of healthy state.

Microsoft Defender Antivirus event ID	Meaning	Treat as
1116	Malware or potentially unwanted software detected	Detection to triage
1117	Action taken on the detection; Allow after a 1116 means not remediated	Verify remediation
5001	Real-time protection disabled	High priority unless a change ticket exists
5007	Antimalware platform configuration changed (logs old and new values)	Review; Microsoft notes an unexpected change may be malware. Watch for new exclusions
5010 / 5012	Scanning for malware / viruses disabled	High priority
5013	Tamper protection blocked a change	Investigate the process that tried
1121	Attack surface reduction rule fired in block mode	Triage, tuning input
2001 / 2003	Security intelligence / engine update failed	Health incident

Where identity fits

Console and API access: EDR administrators can push policy, run scripts and isolate any host. Put these roles behind phishing-resistant MFA, privileged access workstations and just-in-time elevation, and treat EDR API client secrets used by SOAR or MDR providers as high-value non-human identities with owners, scopes and rotation. See the EDR and XDR Buyer's Guide for questions to ask about role granularity.
Local administrator accounts: shared local admin passwords let one compromised host disable the sensor on many. Use unique, rotated passwords. See the Local Administrator Password Solution (LAPS) Guide.
Service accounts and scanners: the LOTL guidance notes that service accounts and vulnerability scanners generate large volumes of legitimate privileged activity; tag them so detections can distinguish expected from unexpected use, rather than excluding them.

Choosing an operating model

Small organisations (no 24x7 SOC): enable vendor-managed prevention and automated remediation at their strictest workable settings, and buy MDR or a managed alert service for out-of-hours response. An EDR nobody watches at weekends gives detection after the damage. See the MDR Buyer's Guide.
Mid-sized organisations: an in-house team owns policy, tuning and exclusions; a provider covers nights. Write down who may isolate a host.
Large organisations: dedicated detection engineering, custom rules as code, raw telemetry to a data lake, and device groups mapped to business units with delegated but audited administration.
Evaluating products: MITRE ATT&CK Evaluations run emulated adversary scenarios against participating products and publish the raw results; MITRE states they do not rank vendors. The 2025 enterprise round, for example, emulated Scattered Spider and Mustang Panda behaviour and placed more weight on protection. Use the published detail to see how a product reported each step, then run your own proof of concept on your own images.
Public sector: in the US, OMB memorandum M-22-01 (October 2021) requires federal agencies to coordinate EDR deployment with CISA, give CISA access for proactive threat hunting, and retain endpoint data as CISA's reference architecture defines.

Detection and measurement

Sensor coverage: healthy sensors divided by in-scope assets, by tier. Target 98 per cent or higher overall and 100 per cent for tier 0 servers.
Prevention mode share: percentage of devices in full block mode with tamper protection on.
Mean time to triage and to contain for high and critical alerts, measured from alert creation.
False positive rate per rule: from alert classification; rules above an agreed threshold go to the tuning backlog.
Exclusion count and age: total exclusions, percentage with an owner and expiry, and number past expiry.
Detection validation pass rate: share of scheduled atomic tests or purple team steps that produced the expected alert.

Framework mapping

Framework	Reference	EDR relevance
NIST CSF 2.0	DE.CM-09, DE.AE-02, DE.AE-03	Monitoring endpoints and runtime environments; analysing and correlating adverse events
NIST SP 800-53 Rev. 5	SI-3, SI-4, SI-4(2), IR-4, AU-6, CM-6	Malicious code protection, system monitoring, real-time analysis, incident handling, review, configuration settings
CIS Controls v8.1	10.1, 10.7, 13.2, 13.7	Anti-malware, behaviour-based anti-malware, host-based intrusion detection and prevention
ISO/IEC 27001:2022 Annex A	A.8.7, A.8.15, A.8.16	Protection against malware, logging, monitoring activities
MITRE ATT&CK v20	T1685, T1068, T1059.001, T1218, T1003.001	Sensor tampering and the techniques custom detections should cover
MITRE D3FEND	D3-PSA, D3-PLA, D3-SCA, D3-EAL	Defensive techniques EDR implements or depends on

See the MITRE ATT&CK Guide for Defenders.

Common failure patterns

Coverage assumed, not measured: the console shows thousands of healthy devices, but nobody compares it with the asset inventory, so the unmanaged file server or the newly built cloud VM is where the intrusion starts.
Stuck in detect-only: the pilot never ends because one application owner objected, and blocking is never enabled on servers.
Broad exclusions as a fix for performance: excluding C:\Users\* or powershell.exe to stop complaints creates exactly the space attackers use.
Tamper protection off for convenience: disabled during a troubleshooting session and never re-enabled, so a local admin can turn off real-time protection with one command.
Alert queue without classification: analysts close alerts without recording why, so the same false positives recur and real ones are closed by habit.
Unprotected console: a compromised EDR administrator account or API secret becomes an estate-wide remote execution tool for the attacker.

Practitioner checklist

Reconcile healthy sensors against the asset inventory weekly and chase every gap on tier 0 assets the same day.
Define device groups by risk tier and run every policy change through pilot rings.
Move all groups from detect-only to block, with a documented and tested rollback per ring.
Enable tamper protection everywhere, disable local admin merge and confirm exclusions are protected.
Alert on real-time protection disabled, configuration changed and sensors going silent on servers.
Write custom detections for living off the land techniques relevant to your estate and test them on a schedule.
Classify every closed alert and review the noisiest rules monthly.
Protect the EDR console with phishing-resistant MFA and just-in-time roles, and vault and rotate EDR API secrets.
Agree in writing who may isolate which hosts, including any MDR provider.
Report coverage, prevention share, time to contain and exclusion age to leadership each month.

Standards and references

Related NHI Mgmt Group resources: Endpoint Security Guide · EDR Tuning and Exclusions Management Guide · Microsoft Defender for Endpoint Guide · SOC Guide · MDR Guide