Endpoint Telemetry Coverage Gaps: What Your EDR Cannot See

EDR agents are user-mode or kernel-mode processes that start after the operating system has booted. That single architectural fact creates a category of invisibility. Pre-OS components run before the agent exists: UEFI firmware, bootloaders, the Master Boot Record on legacy systems, and Option ROMs on peripherals. An implant in any of these layers, such as BlackLotus, MoonBounce, or LoJax, is loaded, executes its persistence logic, and hands off to the kernel before the EDR injects a single hook. The agent then reports a clean boot. Kernel-mode rootkits that subvert the same hooks the EDR depends on, particularly on systems with weak Kernel Patch Protection or vulnerable signed drivers loaded via BYOVD, can hide processes, files, and network connections from the agent itself. Then there is the unagentable estate: IoT sensors, OT controllers, network printers with embedded Linux, VOIP phones, ESXi hypervisors on older hardware, embedded Linux devices with no package manager, and increasingly the management planes of network appliances themselves. None of these can host an EDR agent, yet many sit on the same VLANs as your crown jewels and are reachable by adversaries who pivot through them precisely because they know you are not watching.

Build a coverage matrix with three columns: device exists, agent installed, agent reporting in the last 24 hours with the expected event volume. The first column comes from your authoritative inventory, which for most organizations is a union of Entra ID joined devices, Intune or Jamf, your CMDB, DHCP leases, and a network discovery scan such as Rumble or runZero. The second column comes from your EDR console export. The third requires a query against your SIEM for agent heartbeat events and a baseline of expected process or syscall volume per endpoint type. Devices in column one but not column two are unmanaged. Devices in column two but failing column three are silent agents, which is operationally worse than no agent because they create false assurance. Segment the matrix by device class: Windows workstation, Windows server, Linux server, macOS, ESXi host, network device, OT device. Expect the silent-agent rate to be five to ten times higher on servers than workstations and to spike during patch windows. Report the silent rate weekly to leadership; it is the single most useful EDR health metric and almost nobody tracks it.

For devices that cannot host an agent, network telemetry is the only practical detection surface. Three feeds matter. First, NetFlow or IPFIX from core switches and firewalls, ideally enriched with DNS query logs, gives you behavioral baselines for every speaker on the wire. A network printer that suddenly initiates outbound TLS to a residential ASN at 2 a.m. is detectable here even though it will never appear in your EDR. Second, DHCP logs with vendor class identifiers and option 55 fingerprints let you classify device types passively; a deviation from the expected fingerprint on a known MAC is a strong tampering signal. Third, span or tap traffic into a Zeek or Suricata sensor gives you protocol-aware visibility for lateral movement: SMB, RDP, WinRM, and LDAP connections originating from an OT device or a printer to a domain controller are nearly always malicious. Correlate these three feeds in your SIEM with the EDR coverage matrix to produce a single view: this asset has no agent, here is its behavioral baseline, here are the deviations. That is detection coverage for the unagentable estate.

Below the EDR you need attestation, not detection. Start with UEFI Secure Boot enforced in audit-and-reject mode across the fleet, with the Microsoft third-party CA disabled where business requirements allow, and the Forbidden Signature Database, DBX, kept current via Windows Update or vendor tooling. Verify enforcement programmatically; do not trust BIOS settings to remain set. Next, leverage the TPM. Platform Configuration Register values, particularly PCR 0 through 7, measure the boot chain. Collect PCR values at enrollment, store the known-good set in a configuration database, and verify on every boot via Windows Device Health Attestation or a comparable Linux IMA setup. Any deviation is a high-priority alert. For hardware-attested platforms, HP Sure Start, Dell SafeBIOS, and Lenovo ThinkShield perform continuous BIOS verification independent of the OS and surface tamper events to a management plane your SIEM can ingest. On servers, redfish telemetry from iDRAC, iLO, or XCC provides equivalent visibility. None of this is detection in the EDR sense; it is integrity verification, and it is the only practical answer to the pre-OS persistence problem.

Most EDR platforms were built Windows-first, and Linux coverage is consistently weaker in ways the vendor coverage dashboard will not surface. Hook depth is shallower; many agents rely on auditd or eBPF probes that produce a fraction of the event types the Windows kernel callbacks deliver. File integrity monitoring is often optional and off by default. Container visibility ranges from absent to surface-only, missing the namespace and cgroup context that makes Linux process events useful. Test your coverage explicitly. Pick a representative Linux server, run a controlled set of behaviors mapped to MITRE ATT&CK techniques for Linux: T1059.004 shell execution, T1055.009 proc memory injection, T1547.006 kernel module loading, T1543.002 systemd persistence, T1070.002 log clearing, T1021.004 SSH lateral movement. For each, record whether the EDR produced an event, what fields were populated, and how quickly. Compare to the same exercises on Windows. Document the gap and either layer in osquery, Falco, or Auditbeat to backfill the missing telemetry, or accept the gap and route detection responsibility to network-layer signals. Telling your leadership team you have EDR on Linux without this exercise is misrepresentation.

Coverage analysis only matters if it produces continuous, owned action. Assign an owner for each gap class: an endpoint engineer owns silent-agent remediation, a network engineer owns NetFlow and DHCP enrichment, a platform team owns UEFI and TPM attestation, and a detection engineer owns the Linux parity exercises. Set service-level objectives that are measurable: silent-agent rate below 2 percent within seven days of detection, 100 percent of Windows endpoints with PCR 0 to 7 baselines collected at enrollment, every unagented device class with at least one network-layer detection rule mapped to ATT&CK. Review the coverage matrix monthly in a forum that includes both detection and infrastructure leadership; gaps are usually infrastructure problems wearing a detection costume. Finally, feed coverage data into your threat modeling. When a new attacker technique drops, your first question should not be does our EDR catch it but rather where in our coverage matrix does this technique land, and do we have telemetry there at all. That reframing is what separates a mature detection program from a checkbox one.