What your EDR doesn't see: telemetry blind spots and the coverage you put on top

Every EDR has things it doesn’t see. That’s not a knock on any particular product, and it’s not usually a bug. It’s design, plus deployment reality, plus the fact that an endpoint sensor can only tell you about the endpoint. I’ve run detections on top of Microsoft Defender for Endpoint, and before that a couple of others, and the mistake I made early was treating the console as the whole picture. It isn’t. The useful question was never “is my EDR good,” it was “what does it go quiet on, and what do I put on top of the quiet parts.”

So this is a walk through where I’ve found the sensor goes dark in 2026, how I confirm it, and what covers each blind spot. Running the examples against MDE on Windows 11 24H2 with Sysmon 15 forwarding to the SIEM, nothing exotic.

The sensor only sees where it’s installed

Start with the most boring blind spot, because it’s the one that actually gets people. The EDR sees the hosts the EDR is on. Your contractor’s unmanaged laptop, the appliance running someone else’s Linux, the OT segment nobody’s allowed to touch, the personal phone with a mail token on it. None of that is in the console, and none of it throws an alert when it’s the thing that got hit.

I keep a running list of where the agent isn’t. It’s less satisfying than a detection rule and it catches more. If an attacker lands on an unmanaged box and moves laterally to a managed one, the first event you see is the second hop, and you’ll read it as the origin unless you already knew the unmanaged host was reachable. Coverage math beats rule-writing here. Know your denominator.

Defense evasion: the sensor can be told to stop talking

The second blind spot is the one attackers reach for on purpose. If they get code execution with enough privilege, a lot of tradecraft goes into making the EDR stop reporting. Bring-your-own-vulnerable-driver is the loud version: load a signed but vulnerable driver, use it to unhook or blind the sensor from kernel space, and the telemetry after that point is whatever the attacker allows. That whole family is MITRE ATT&CK T1562.001, impairing defenses, and the frustrating part is that the moment it works, the sensor that would have told you about it is the sensor that stopped talking.

You don’t catch this in the EDR’s own event stream, because that stream is what got cut. You catch it at the edges: the driver load event before the blinding (Sysmon event 6, or the Defender-side driver-load telemetry if it fired in time), a sudden and unexplained gap in agent check-ins, the host that was chatty on Tuesday and silent Wednesday with no ticket explaining why. Silence is a signal. You have to be collecting agent-health telemetry centrally to see it, because the absence of events is invisible if the only place you’d notice is the agent that went dark.

The network intent the endpoint can’t interpret

The EDR sees the process that opened a socket. It often can’t tell you what that socket was for. Command and control over DNS (T1071.004) or tunneled inside something that looks like normal web traffic (T1572) shows up on the endpoint as “a legitimate-looking process made a network connection,” which describes approximately everything. When the C2 rides DNS-over-HTTPS, even the DNS content that would have given it away is inside a TLS session the endpoint sensor isn’t unwrapping.

This is the clearest case for a second telemetry source. Network security monitoring with Zeek, or your firewall’s DNS logs, sees volume and rhythm and destination that the endpoint can’t. Beaconing has a shape. A process making the same-sized request to the same host every sixty seconds is a shape the network sees plainly and the endpoint mostly doesn’t. I’ve never regretted having the DNS logs. Two sources looking at one connection from different angles is how you get intent, not just occurrence.

The identity plane, where the endpoint stops

Here’s the one that’s grown the most. A lot of 2026 intrusions barely touch the disk. Someone phishes a session token or an OAuth grant, replays it, and operates as the user in the cloud tenant without ever dropping a payload on a managed endpoint. Stealing the token is T1528; using it to authenticate as the user is T1550. Your EDR might see the initial phish if it happened on a managed host. Everything after, the token replay from a foreign address, the mailbox rules, the app consent, happens in Entra ID and the SaaS logs, which the endpoint agent has no window into at all.

If you’re only watching endpoints, this class is invisible start to finish when the phish lands on an unmanaged device. The cover is the identity logs: Entra ID sign-in logs, the audit logs from your identity provider, impossible-travel and token-anomaly signals correlated against what the endpoints did or didn’t see. This was the single biggest addition to our coverage in the last two years, and it’s telemetry that has nothing to do with the EDR.

The data’s there, the detection isn’t

The last category is different. Sometimes the sensor sees the whole thing and just doesn’t flag it, because the behavior is indistinguishable from legitimate work until you write the rule. Living-off-the-land binaries (T1218), RMM tools an attacker installed that look exactly like the RMM tool your helpdesk uses, a scheduled task that’s malicious only because of what it runs. The telemetry is in the console. The detection is on you.

Look, this is the good kind of blind spot, because it’s the one you can close with work you control. The other categories need a whole second data source. This one needs a tuned rule and the context to know your own environment’s baseline. (Yes, that context is the hard part, and yes it’s why the same rule that’s clean in one org is unusable in another.) It’s also the reason I don’t trust a detection I imported without tuning it to what normal looks like here first.

Nobody watches all of it at 3am

Put those together and you get an honest picture: covering an EDR’s blind spots means running identity telemetry, network monitoring, DNS logs, and agent-health monitoring alongside the endpoint console, and correlating across all of them. That’s four or five data sources, each with its own noise floor, each needing someone to actually look when something fires. On a normal team that someone is also doing three other jobs, and the coverage quietly thins out overnight and on weekends, which is exactly when the token replays and the driver loads tend to show up.

This is the point where being honest about capacity matters more than buying another tool. Some teams run all of it in-house around the clock, and if you can staff that, good. A lot can’t, and the sane move there is to hand the after-hours and weekend watch to a managed SOC team that’s staffed for the hours you aren’t, while you keep the detection engineering and the environment knowledge that no outside party will ever have for your network. The LOLDrivers project cataloguing known-vulnerable drivers and the MITRE ATT&CK defense-evasion tactic pages are both good starting points for deciding which of these blind spots is worth covering first in your environment, because you will not cover all of them at once and the order should follow your own risk, not a vendor’s feature list.

The point

The EDR isn’t the picture. It’s one layer of it, and a good one, and it has blind spots that are mostly structural. The teams I’ve watched handle this well weren’t the ones with the most expensive sensor. They were the ones who could name their own blind spots out loud: here’s where the agent isn’t installed, here’s what happens if it gets blinded, here’s the identity traffic it can’t see, here’s the overnight window nobody’s watching. Once you can say those four sentences about your own environment, you know what to put on top. Until you can, the console is telling you a reassuring story about the part of the network it can see.