The first EDR tuning review we ran in 2026 began with a frustrated CISO and a six-month-old detection platform that had not produced a single confirmed incident. The CISO assumed the vendor had oversold the product. The review showed something more uncomfortable: the platform had been deployed with default configurations, default exclusions, default response actions, and default thresholds, and the attacker behavior in their environment had been carefully designed by an unaffiliated red team to live within exactly those defaults. The platform was working as designed. The design had been generic. The attacker had been specific.
This is the modern endpoint detection problem. The platforms have matured. The defaults have not. The Mandiant M-Trends reports consistently observe that organizations with mature endpoint platforms still suffer breaches when the platforms are deployed without environmental tuning. The default rule set is necessarily generic because the platform vendor has to ship a configuration that works across thousands of environments. The cost of that genericness is that the configuration is optimized for the median environment, which is, by definition, not yours. The attacker who has studied the defaults knows where the blind spots are.
Why Default EDR Configurations Produce Worse Outcomes Than Most Organizations Realize
The default configuration of a modern EDR is a compromise. It is calibrated to produce acceptable false positive rates across a wide range of environments. The cost of that calibration is sensitivity. The defaults underdetect by design. The vendor expects the customer to tune. The customer often assumes the vendor has tuned. The gap between those two assumptions is where attackers live. We routinely find environments where the platform is correctly licensed, fully deployed, and effectively asleep.
“The EDR platforms in 2026 are capable of producing remarkable detection coverage. They almost never do so out of the box. The platform is a violin. The default configuration is the violin in its case. Music requires someone to take it out and play it, and that requires a player.”
Senior endpoint detection, iSECTECH engagement notes
The tuning conversation is also a staffing conversation. Tuning is a continuous activity, not a deployment task. The mature programs we work with have a named role for endpoint detection content engineering, with a backlog, a release cadence, and a measurable output. The immature programs treat tuning as something that happens during deployment and then never again. The first model produces an endpoint capability that compounds in value. The second produces a platform that depreciates in value the day it is deployed.
Three Engagements That Defined Our EDR Tuning Playbook
Engagement One: The Exclusion That Owned the Environment
A financial services client engaged us after a red team had moved laterally undetected across the entire production environment. The investigation traced the success to a path exclusion that had been added at deployment time three years earlier, to accommodate a backup software vendor that no longer existed. The exclusion had covered approximately twelve percent of the environment by file path. The red team had operated entirely within that twelve percent. The exclusion had been correct on the day it was added and was a catastrophic blind spot every day after.
Engagement Two: The Response Action That Was Never Configured
A retail client asked us to review why an obvious malicious behavior had triggered an alert but not a containment. The platform had detected the activity, generated a high-severity alert, and waited. The automatic response policy had been left at the default of “alert only” because the deployment team had been concerned about false-positive containment during initial rollout. The concern had been reasonable in week one. It had been left in place for nineteen months. The attacker had eleven minutes of free movement after the first alert.
Engagement Three: The Tuning Cycle That Caught the Next Breach
A technology client asked us to design a tuning cadence after a near-miss. We co-built a monthly tuning cycle: one named engineer owns the tuning backlog, one peer review session per month evaluates proposed changes, one rollback gate is in place for every change, and one quarterly maturity review measures the percentage of detections that have produced an incident in the prior period. Six months later, the platform detected a credential theft attempt early enough to contain it. The cost of the tuning cycle was approximately one engineer-month. The benefit of the prevented breach exceeded $4 million.
Why Deployment-Centric Programs Underperform Tuning-Centric Programs
The deployment-centric program treats the EDR as a product. Buy it, install it, attest it, move on. The tuning-centric program treats the EDR as a capability that requires continuous engineering investment to retain value. The first model produces a flat capability curve that bends downward over time as the environment changes and the platform does not. The second produces a capability curve that bends upward as the team learns the environment and tunes for it. The two programs look identical in procurement and very different in incident outcomes.
“The endpoint platforms that produce real detection are the ones that have been tuned by a team that knows the environment. The platforms that have been deployed and left alone are running a generic configuration in a specific environment, and the attacker has the home-field advantage.”
Mark Russinovich, public commentary on endpoint security
The Playbook We Run With Every Client on EDR Tuning
The playbook rests on four pillars. The first is exclusion inventory and review. Every exclusion has a documented purpose, a named owner, and an expiration date. The exclusion catalog is reviewed quarterly with a default of removal. The second is response policy maturation. The platform transitions from alert-only to graduated automatic response across well-tested detection families, with rollback procedures and clear escalation. The third is environmental tuning. The platform is calibrated to the actual baselines of the environment, with named owners for each detection family and a tuning backlog managed like software. The fourth is detection efficacy measurement. The program reports on the count of detections that have produced an incident in the past year, the median time from detection to containment, and the ratio of automated to manual response. The NIST guidance on detection capability has, in its most recent revision, leaned explicitly on tuning maturity rather than coverage.
What Boards Should Demand This Quarter
The board questions that produce real change are not the ones about EDR deployment percentages. They are the ones about exclusion count and age, about response policy automation coverage, and about the count of detections that have produced an incident in the prior period. Boards that ask these questions get programs that answer them.
“The endpoint programs that produced measurable defense were the ones whose boards stopped asking about deployment coverage and started asking about tuning maturity. The metric shaped the program, and the program produced the outcome.”
iSECTECH endpoint detection review summary
How This Connects to the Rest of Your Security Program
EDR tuning is not a standalone capability. It connects to the alert fatigue conversation we have written about, to the privileged access architecture that determines what an attacker can do once inside, and to the backup recovery discipline that determines whether a detection failure becomes a catastrophic one. The integrated program is the durable one.
What to Do This Week
Three concrete actions, in order. Pull the exclusion list from your EDR and identify every exclusion older than twelve months without a named owner. Audit your response policies and identify every detection family still configured as alert-only after the initial deployment window. Build a single dashboard that reports monthly on the count of detections that have produced an incident in the prior twelve months by detection family.
Talk to a Senior endpoint detection Practitioner
If your organization is working through an EDR maturity review, a platform migration, or a detection tuning program design, our senior practitioners can help. Talk to a senior iSECTECH practitioner about a confidential review of your endpoint detection posture and the three changes that would most improve incident detection this quarter. The CISA guidance on endpoint defense continues to emphasize tuning over coverage as the defining maturity marker.
Why the Tuning Backlog Should Live in Engineering Rather Than Operations
The organizations that have made the most progress on endpoint tuning have treated the backlog the way an engineering team treats a product backlog. Stories, priorities, peer review, release notes, and a deprecation policy. The operations-team model of tuning treats each change as a one-off ticket that ages out of memory the day it is closed. The engineering-team model produces an institutional knowledge base that survives staff turnover. The model is the program.
Continue Reading: Week 5 Field Notes
For the broader operational picture of how endpoint detection interacts with detection engineering and response, continue with our notes on alert fatigue and detection collapse, privileged access, and Kerberoasting from the internal pentest. The recurring pattern is that tools produce value only when a named team owns the continuous engineering of the configuration.