An endpoint detection and response (EDR) platform is only as good as the signals it actually receives. So what happens when the console looks calm, the dashboards are green, and yet a workstation quietly stops sending telemetry? That gap between “the tool is installed” and “the tool is working” is where most EDR troubleshooting begins.
EDR platforms combine endpoint agents, behavioral analytics, and centralized response actions to catch threats that signature-based antivirus misses. The global endpoint security market has grown past $20 billion, according to Statista market research, which means a lot of organizations now depend on these tools. But deployment is the easy part. Keeping agents healthy, policies coherent, and telemetry flowing takes ongoing effort, and the failure modes are surprisingly consistent across vendors.
This guide walks through the practical side of EDR troubleshooting: what usually breaks, how to diagnose it in the right order, and which mistakes waste the most time.
Why EDR agents fail silently
The most dangerous EDR problem is not a crash. It is a silent failure where the agent process is running but no longer enforcing policy or shipping data. A stopped service usually triggers an alert somewhere. A degraded agent that still answers health pings but has an unloaded kernel component can go unnoticed for weeks.
Three conditions produce most silent failures:
- Kernel or system extension problems. On Windows, the agent depends on filter drivers. On macOS, it depends on approved system extensions. OS updates can disable or block these components, and the agent may keep running in a reduced state.
- Communication breakdowns. Agents report to cloud consoles or on-prem servers over specific ports and domains. A new TLS inspection appliance or firewall rule can cut that channel without touching the endpoint itself.
- Policy conflicts. Overly broad exclusions, overlapping policy groups, or a device that fell out of its assigned group can make the agent appear to “miss” detections that were never enabled for that device.
A useful mental model: EDR troubleshooting is a layered health check. You verify the agent, then the channel, then the policy, then the OS prerequisites, and only then look at detection logic. Skipping layers is the single most common reason investigations drag on.
Start with agent health, not with alerts
Before touching detection rules, confirm the basics. Most vendor support cases resolve at this layer, and it takes minutes instead of hours.
- Check the service state. Confirm the agent service is running and set to start automatically. On Windows, check the service manager. On macOS and Linux, check the system daemon.
- Confirm the agent version. Compare it against the vendor’s current release notes. Known issues are documented per version, and an outdated agent is a frequent root cause.
- Verify tamper protection status. If tamper protection or uninstall protection was toggled, the agent may be in a locked or partially disabled state that blocks remediation.
- Look at the last check-in time. A stale timestamp means the channel is broken, not the detection engine.
- Review the local agent log. Most agents write a local log or diagnostic bundle. Read the last errors before escalating.
Practical tip: build a saved console query that lists devices with a last check-in older than 24 hours. Run it weekly. This one habit catches more real problems than any dashboard.
Diagnosing communication and connectivity failures
If the agent is healthy but the console shows it offline, the problem lives in the network path. EDR agents typically need outbound access to specific cloud endpoints on defined ports, and those requirements change between versions and deployment modes.
Work through these in order:
- Proxy changes. A new proxy, PAC file, or authentication requirement will break agent traffic while browsers keep working fine. Users rarely notice.
- TLS inspection. Some security appliances intercept and re-sign traffic. If the agent does not trust the inspection certificate, connections fail quietly.
- Firewall and DNS filtering. Confirm the required domains resolve and are not blocked by category-based filtering.
- On-prem console routing. In on-prem deployments, verify the agent can reach the management server and that certificates have not expired.
Always cite the vendor’s current connectivity document rather than an old internal wiki page. Port and domain requirements differ by product and drift between releases, so an outdated runbook can send you chasing the wrong endpoint.
Policy, exclusions, and the detection gap
Here is a scenario that plays out constantly: the agent is healthy, telemetry flows, and yet a known test threat is not flagged. Nine times out of ten, policy is the culprit.
Exclusions are the usual suspect. EDR exclusions exist for good reasons, like performance-sensitive servers or incompatible applications. But exclusions accumulate. A folder excluded two years ago for a legacy app may now host user downloads. Audit exclusions quarterly and require a ticket and an expiry date for every new one.
Policy group assignment matters too. If a device was reimaged, renamed, or moved between organizational units, it may have landed in a default policy group with weaker settings. Cross-check the device’s group membership against what you expect.
Conflicting policies can also produce strange behavior. When multiple policy sets apply, the resolution order is not always intuitive. Test with a single known device and a single policy change at a time.
If you suspect the problem is not policy but content, the same diagnostic discipline applies to output as to input. Teams that verify what their tools actually produce, using guides like this walkthrough on how to spot AI generated content, tend to catch anomalies faster because they already know what “normal” looks like.
OS-level prerequisites that quietly break EDR
Endpoint agents sit deep in the operating system, which means OS-level changes can disable them without an obvious error.
| Platform | Common breakage point | What to verify |
|---|---|---|
| Windows | Filter drivers, ELAM, Secure Boot changes | Driver loaded, agent signed, no boot-time block |
| macOS | System extensions, Full Disk Access, SIP | Extension approved, permissions granted after updates |
| Linux | Kernel modules, eBPF support | Module builds against current kernel, headers installed |
Major OS upgrades are the classic trigger. A macOS point release can require the user or admin to re-approve a system extension. A Windows feature update can reset driver states. A Linux kernel update can leave a module unable to load until it is rebuilt.
Common mistake: assuming a green agent icon means full protection. Check the individual protection modules rather than the top-level status alone. Vendors usually expose module-level health in the console or via a command-line tool.
Performance problems: when the agent becomes the issue
Sometimes EDR troubleshooting runs in reverse: the agent works, but it is slowing machines down. High CPU or disk usage from an EDR agent usually traces to one of three causes: aggressive scan settings, reputation lookups on file-heavy workloads, or a specific module behaving badly on a particular OS build.
The fix is scoping, not uninstalling. Identify whether the load is constant or tied to specific activity like builds, backups, or large file copies. Then check the vendor’s performance-tuning guidance, which typically covers scan exclusions for known-heavy directories and CPU throttling settings.
Two practical rules:
- Exclude by process, not by folder, when possible. Process-based exclusions are narrower and easier to justify.
- Measure before and after. Capture baseline CPU and disk numbers so you can prove a change helped.
Response actions deserve separate testing. Network isolation, for example, can fail independently of detection if the network configuration blocks the isolation mechanism. Test isolation, live response, and file quarantine on a pilot device each quarter. A response action that fails during an incident is worse than one you never relied on. (Endpoint detection and response)
Logs, diagnostic bundles, and escalation
When local troubleshooting stalls, escalation speed depends on preparation. Vendors publish log-collection tools and specify exactly which data a support case needs.
Before opening a case, gather:
- Agent version, OS build, and console version
- Timestamps of the failure in the console’s timezone
- The local agent log covering the failure window
- The vendor’s diagnostic bundle output
- A description of what changed recently, including network and policy changes
The “what changed” question solves a shocking share of cases. New proxy, new OS patch, new policy push, new firewall rule. Change management and EDR troubleshooting are the same discipline wearing different hats.
For teams that also run SIEM tooling alongside EDR, correlation helps. A guide like this one on Wazuh SIEM detection workflows shows how endpoint and log telemetry combine, and the same layered logic applies when you are deciding whether a gap sits in the agent or in the pipeline downstream.
Building an EDR health routine that prevents fires
Reactive troubleshooting is expensive. A light preventive routine catches most of the failure modes above before they matter. (Cybersecurity Framework)
Weekly: review agents with stale check-ins, failed policy applications, and pending reboots after agent updates.
Monthly: audit exclusions, confirm policy group assignments match device inventory, and check that detection content is updating.
Quarterly: test response actions on pilot devices, review OS update impact on agent modules, and re-verify connectivity requirements against current vendor documentation.
Annually: re-baseline performance expectations and review whether the EDR tooling still fits the environment.
One more habit worth building: keep a short internal runbook per platform. Not a vendor manual, but a one-page checklist of where the logs live, which commands show module health, and who to call. During an incident, nobody wants to rediscover that information.
The same verification mindset applies to adjacent tooling. Teams that know how to validate what their monitoring stack reports, whether that means checking output quality or learning how to detect AI generated images in evidence workflows, tend to trust their dashboards appropriately instead of blindly.
Conclusion
EDR troubleshooting rewards order over instinct. Check the agent, then the channel, then the policy, then the OS prerequisites, and only then question the detection engine. Most failures live in the first three layers, and most of them are caused by something that changed: a patch, a proxy, a policy push, an exclusion added months ago and never removed.
The organizations that struggle least with EDR are not the ones with the fewest incidents. They are the ones with a routine: stale check-in reviews, exclusion audits, quarterly response-action tests, and diagnostic bundles ready before support is needed. None of that is glamorous. All of it is what keeps a detection platform actually detecting.
FAQ
Why does my EDR agent show as online but miss known threats?
Online status only confirms the communication channel. The agent may have unloaded a kernel component, landed in a policy group with broad exclusions, or had a detection module disabled by an OS update. Check module-level health and policy assignment rather than the check-in timestamp alone.
How often should EDR exclusions be reviewed?
Quarterly is a reasonable baseline for most organizations, with an expiry date required for every new exclusion. Exclusions added for a temporary application compatibility issue should be removed once the application is retired or updated.
What is the first thing to check when an EDR agent goes offline?
Compare the last check-in time with recent network changes. Proxy updates, TLS inspection appliances, and firewall rule changes are the most common causes. Confirm the agent service is running before assuming a network problem.
Can an OS update really disable EDR protection?
Yes. macOS updates can require re-approval of system extensions, Windows feature updates can affect filter drivers, and Linux kernel updates can break modules until they are rebuilt. Test agent health after every major OS rollout.
Why is the EDR agent using so much CPU?
Usually scan settings, reputation lookups on file-heavy workloads, or a module misbehaving on a specific OS build. Scope the load first, then apply vendor performance-tuning guidance such as process-based exclusions and CPU throttling.
What should be included in an EDR support case?
Agent and console versions, OS build, failure timestamps in the console’s timezone, the local agent log for the failure window, the vendor’s diagnostic bundle, and a summary of recent changes to network, policy, or OS configuration.
