The EDR Gap: Your Endpoint Tool Covers One Layer

CrowdStrike, SentinelOne, Defender for Endpoint: real products, real value, really good at stopping a specific class of endpoint threat. None of them is a security program.

The pattern we see every week: a mid-market company buys an EDR, their MSP deploys it, and the company believes they are covered. Then an attacker gets in through the three doors EDR does not watch, and suddenly the question is not whether the EDR works. It is whether anyone was watching the other doors.

EDR (Endpoint Detection and Response) is good at what it is built for:

• Known malware signatures and behavioral matches
• Ransomware encryption patterns
• Suspicious process trees (Office spawning PowerShell, etc.)
• Lateral movement that touches the endpoint filesystem
• Offline endpoints that get quarantined on reconnect

These matter. If you have no EDR, install one. If you already have one, it is doing real work. The gap is not that EDR fails. The gap is everything it was never designed to see.

1. Identity compromise

When an attacker phishes credentials and logs in as the user, the endpoint never sees anything unusual. The session is legitimate. Nothing on disk runs. Nothing spawns a suspicious process. The EDR stays green while the attacker harvests email, OneDrive, and whatever SaaS tools the user has SSO access to.

You need identity-layer telemetry for this: Entra ID sign-in logs, conditional access signals, impossible-travel detection, token replay protection. EDR cannot help.

2. Cloud misconfiguration and control-plane compromise

AWS access keys in a public GitHub repo. An overly permissive IAM role. An S3 bucket opened to the internet by a developer who does not realize. A Lambda with exfiltration logic. None of these touch any endpoint you have an EDR on.

Cloud attack surfaces require cloud-native detection: CloudTrail, GuardDuty, config drift monitoring, CSPM tooling. EDR cannot help.

3. Email-native attacks

Business Email Compromise, vendor invoice fraud, OAuth app abuse, Teams federation exploits. The attack happens inside the mail and collaboration platforms. Nothing downloads. Nothing executes. A wire transfer goes to the wrong account and the EDR was never involved.

You need email security and OAuth app governance for this: Defender for Office 365, Safe Links, OAuth consent governance, email authentication (SPF, DKIM, DMARC). EDR cannot help.

A real security program covers four layers: endpoint, identity, cloud, email. Each layer needs its own telemetry and its own response logic. Done well, the layers reinforce each other (a suspicious sign-in from identity + an unusual download on endpoint = higher-confidence detection than either alone).

Done badly, the layers are four separate dashboards no human correlates. That is the pattern we see at most mid-market companies.

A common package is an EDR deployment plus patch management, described as managed security and invoiced monthly. That is a real service and it covers a real layer. It is usually scoped as endpoint work rather than as a security program, and the difference matters once someone asks you to prove coverage.

A full managed security offering operates all four layers with trained analysts, correlates signals across them, owns the response workflow, and produces reporting that would satisfy a regulator or an enterprise buyer's questionnaire. That is a different staffing model, which is why plenty of capable providers subcontract it rather than build it. The question to ask is concrete: how would they detect a compromised Microsoft 365 account using only an EDR feed?

Do not rip out your EDR, and do not assume the gap means your provider is failing you. Audit whether anyone is covering the three other layers. If the answer is "our MSP, I think," ask them in writing what they monitor, detect, and respond to at the identity, cloud, and email layers. Sometimes the answer is that it was never in scope, which is a scoping conversation rather than a vendor change.