NDR vs EDR: Network vs Endpoint Detection and Where Each Goes Blind

An endpoint agent can only report on devices it is installed on and still running on, and a network sensor can only report on traffic that crosses it in a form it can read. Endpoint detection and response (EDR) and network detection and response (NDR) are often presented as competing budget lines, but they fail in almost opposite places: EDR goes blind on unmanaged, IoT, OT and appliance assets and on any host where an attacker has disabled it, while NDR goes blind inside encrypted payloads and on traffic that never passes a sensor. This guide is for SOC leads and detection engineers deciding where each belongs, how attackers exploit the gap between them and how to correlate the two into one detection. For tool fundamentals see the EDR Guide and the NDR Guide; for the forensic evidence angle see EDR Telemetry vs Full Packet Capture.

Key takeaways

• EDR sees cause, NDR sees conversation. EDR knows which process, user and command line produced an action; NDR knows which hosts talked, how often, over what protocol and with what volume, including hosts that run no agent at all.
• Each one's blind spot is the other's strength. Unmanaged devices, network appliances, OT controllers and tampered hosts are invisible to EDR but visible on the wire; encrypted payloads and process attribution are invisible to NDR but visible on the host.
• Attackers deliberately work in the gap. ATT&CK T1685 Disable or Modify Tools lists EDR among the tools adversaries tamper with, and the 2024 joint advisory on Volt Typhoon describes intrusions through routers, VPNs and firewalls using built-in tools that can blend into normal activity.
• Encryption narrows NDR, it does not end it. TLS 1.3 encrypts the server certificate and Encrypted Client Hello (RFC 9849) hides the server name, but flow timing, volume, destinations, DNS and fingerprints still support beaconing, lateral movement and exfiltration detection.
• Correlation is the real product. A network alert enriched with the host's process tree, or an endpoint alert confirmed by matching east-west flows, is what lets an analyst act quickly and contain with confidence.

The short answer

If you have neither, buy EDR first for every laptop and server you manage, because it detects and contains the most common intrusion paths on the assets you control. Add NDR when any of these is true: a meaningful share of your estate cannot run an agent (OT, medical, IoT, printers, network and security appliances, legacy systems); you have had or fear EDR tampering; you need visibility of east-west traffic in data centres; or regulators and insurers expect independent network monitoring. NIST SP 800-94 has described host-based and network-based intrusion detection as complementary types for years, and the CISA #StopRansomware Guide asks for EDR on all assets and also for intrusion detection that can detect command and control activity. XDR products combine the two data sources with identity and email telemetry; they do not remove the need for a network sensor where no agent can run. See SIEM vs XDR and ITDR vs XDR.

NDR vs EDR compared

Threat model: where EDR is strongest and where it goes blind

EDR was built for the attacker who runs code on a managed host. It sees the phishing attachment spawning a script interpreter, the credential dumping tool opening the LSASS process, the scheduled task created for persistence and the burst of file renames as an encryptor runs. It attributes every network connection to a process and user, which NDR cannot do. See the EDR Telemetry Guide.

EDR goes blind in three predictable ways:

• No agent: routers, firewalls, VPN gateways, load balancers, storage arrays, hypervisor hosts that do not support the agent, printers, cameras, building systems and industrial controllers. CISA's microsegmentation guidance notes that agent-based solutions may not be available for legacy, OT and IoT devices; the same constraint applies to detection agents.
• Agent disabled or blinded: ATT&CK T1685 Disable or Modify Tools covers stopping services, killing processes, changing configuration and registry keys, blocking updates and abusing legitimate or vulnerable drivers to disable tools, and names groups and ransomware families that have done it. See Top 10 EDR Evasion Techniques and the Bring Your Own Vulnerable Driver and EDR Killers Guide.
• Activity that looks legitimate on the host: the Volt Typhoon advisory (CISA, NSA, FBI and partners, February 2024) describes living-off-the-land techniques that blend into normal system behaviour and can get past simplistic endpoint security, with initial access through internet-facing routers, VPNs and firewalls.

Threat model: where NDR is strongest and where it goes blind

NDR was built for the attacker who has to communicate. Even a fileless intrusion on a perfectly tuned endpoint must reach a controller, move to other hosts and move data out. NDR detects Application Layer Protocol (T1071) command and control by periodicity and rare destinations, Protocol Tunneling (T1572) such as DNS tunnelling, Proxy (T1090) chains through compromised devices, Network Service Discovery (T1046) sweeps, Remote Services (T1021) and Lateral Tool Transfer (T1570) over SMB between servers that never normally speak, and Exfiltration Over Alternative Protocol (T1048). It sees traffic to and from the appliances and agentless devices EDR cannot cover, and it keeps watching when a host's agent goes quiet. See the Beaconing and C2 Detection Guide.

NDR goes blind in its own predictable ways:

• Encrypted content: NIST SP 800-94 states that network-based IDPS cannot detect attacks within encrypted traffic such as VPN, HTTPS and SSH sessions unless they see it before encryption or after decryption.
• No process context: NDR can say that a server opened 400 SMB sessions; it cannot say which binary did it or which user launched it.
• Sensor coverage: traffic within one host, between containers on one node, across a cloud network with no mirroring, or over a direct internet path from a remote laptop never reaches a sensor.
• Load and evasion: NIST SP 800-94 also notes that sensors may be unable to perform full analysis under high loads, may drop packets and can be flooded with alert-generating traffic to hide a real attack. See Securing the network detection and response (NDR) itself.

Encryption: what NDR still sees

TLS 1.3 (RFC 8446, since obsoleted by RFC 9846) encrypts every handshake message after ServerHello, so the server certificate is no longer readable on the wire. Encrypted Client Hello, published as RFC 9849 in March 2026, encrypts the ClientHello under the server's public key and so hides the server name indication and ALPN list, although the RFC page notes that DNS queries and server IP addresses can still reveal the destination. That removes some easy signals, but much remains.

Decryption at a proxy or with server keys restores content but makes the NDR a holder of very sensitive secrets and data. Decide deliberately which traffic to decrypt, document the privacy basis and protect the keys. Many teams decrypt only outbound web traffic through a proxy and rely on metadata for the rest.

Cloud, OT and unmanaged assets

• Cloud workloads: EDR agents cover virtual machines well and containers with a supported sensor; managed services and serverless functions take neither agent nor tap. Network evidence in cloud comes from provider flow logs, which record connection metadata rather than payloads, and, where packets are needed, provider traffic mirroring, which is usually limited to supported instance types and charged per session plus data transfer. Collect flow logs everywhere and mirror selectively.
• OT and IoT: controllers, HMIs on old operating systems, medical devices and building systems usually cannot run an agent, and vendors may not support one. Passive network monitoring is often the only safe detection option; pair it with zone and conduit segmentation. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• Network and security appliances: VPN gateways, firewalls and load balancers are prime targets and run no customer EDR. The CitrixBleed 2 (CVE-2025-5777) analysis shows hijacked sessions spotted from gateway and session telemetry, such as tokens reused across IP addresses, followed by directory reconnaissance that network monitoring can see. See the Edge Device Security Guide.
• Bring your own and guest devices: NDR plus network access control is the only way to see what an unmanaged laptop does once connected.

Where identity fits

Both tools see identity only indirectly. EDR records the user context of each process; NDR sees authentication protocols on the wire, such as Kerberos ticket requests and NTLM negotiation, and the hosts that service accounts connect from. That makes NDR useful for non-human identity misuse that never touches an interactive desktop: a backup service account suddenly authenticating to hosts outside its normal set, or an API key used from a new network location. Neither replaces identity provider and directory logs. See ITDR vs EDR.

Correlating the two

The value of running both comes from joining their data on host, address, time and user. Practical correlations to build in the SIEM or XDR layer:

1. Agent silence plus network activity: a host stops sending EDR heartbeats while NDR still sees it talking. This is the highest-value correlation for tampering; respond with network quarantine since the agent cannot be trusted. See the EDR Tampering and BYOVD Response Playbook.
2. Beacon to process: NDR flags a periodic outbound connection; the EDR network events for that host and time identify the process, its signer and its parent.
3. Lateral movement confirmation: EDR sees a remote service creation or admin share write; NDR confirms the SMB or RPC flow from the source and shows whether the same source touched other hosts that EDR does not cover.
4. Unknown device: NDR sees a host with no matching EDR asset record. Either it is unmanaged and needs an agent or network control, or it is a rogue device.
5. Exfiltration scoping: EDR identifies the archive tool and staging folder; NDR provides byte counts and destinations to scope what left.

Make the join reliable: synchronise time sources, keep DHCP and DNS logs so addresses map to hostnames, and maintain one asset inventory that both tools reference.

Worked scenario: a ransomware intrusion seen twice

A regional logistics firm runs EDR on 2,500 endpoints and servers and NDR sensors at the data centre core and the internet edge. An attacker exploits a VPN appliance, harvests a service account credential from its configuration and uses it to log in to a file server.

• What NDR sees first: new RDP and SMB sessions from the VPN appliance's internal interface to servers it has never contacted, then an internal port sweep. EDR cannot see the appliance at all.
• What EDR sees next: on the file server, a remote logon by the service account, a remote management tool installed, and a driver load followed by the security agent going offline on two servers.
• Correlation: agent silence on those two servers while NDR still sees them initiating SMB to dozens of hosts triggers the tampering playbook.
• Containment: the SOC isolates healthy hosts through EDR, quarantines the two blinded servers through switch and firewall controls driven by NDR, disables the service account and takes the VPN appliance offline for rebuild.

With EDR alone the first warning would have been on the file server, after the appliance compromise; with NDR alone the team would have known which servers were involved but not which tool or driver to hunt for elsewhere.

Decision criteria

For product evaluation see the EDR and XDR Buyer's Guide and the NDR Buyer's Guide.

Rolling out the second control

1. Measure the gap: reconcile the EDR asset list with DHCP, switch and cloud inventories to count devices with no agent, by zone.
2. Place sensors where the gap is: data centre core, internet egress, OT boundaries and the VPN or ZTNA connector segment, before less critical user floors.
3. Baseline before alerting: run NDR in learning or alert-only mode for several weeks, as the #StopRansomware Guide advises when it asks for a baseline of normal network traffic.
4. Integrate early: send both to the SIEM, build the agent-silence correlation first, then beacon-to-process enrichment.
5. Automate cautiously: enable NDR-triggered EDR isolation for high-confidence detections only, with an allow list for critical servers and a tested manual release path.
6. Validate: run authorised adversary emulation covering lateral movement, C2 and an agent-stop event, and confirm that each control and the correlation fire.

Detection and measurement

• Agent coverage: percentage of known assets with a healthy EDR agent, by asset class.
• Network visibility coverage: percentage of critical segments and agentless zones with an NDR sensor or flow logs.
• Blind asset count: number of devices with neither an agent nor network visibility; aim for zero in critical zones.
• Agent silence detection time: minutes from an EDR heartbeat loss on an active host to an alert.
• Correlated alert share: proportion of high-severity incidents with both host and network evidence attached at triage.
• Sensor health: packet drop and capture loss rates per sensor, alerted from outside the NDR.

Framework mapping

Common failure patterns

• Treating EDR coverage as total coverage: the dashboard says 99% of endpoints are protected, but the denominator excludes appliances, OT and hypervisors, which is where intrusions like those in the Volt Typhoon advisory begin.
• NDR sensors at the perimeter only: the internet edge sees C2 but not server to server movement, which is where ransomware spends most of its time.
• No alert on agent silence: a disabled EDR agent looks like a quiet host. Without a heartbeat alert, tampering goes unnoticed until encryption starts.
• Running the two in separate consoles: analysts pivot by hand between tools, so the beacon-to-process join happens hours late or not at all.
• Decrypting everything without a plan: the NDR becomes a store of credentials and personal data with weak access control, adding risk instead of reducing it.
• Ignoring cloud networks: on-premises sensors are tuned for years while cloud flow logs are never collected, leaving east-west cloud traffic unmonitored.

Practitioner checklist

• Reconcile EDR asset records with network and cloud inventories and publish the blind asset count.
• Alert on EDR heartbeat loss from any host that NDR still sees active.
• Place NDR sensors at the data centre core, OT boundaries and remote access segments, not only at the internet edge.
• Collect cloud flow logs for every production network and mirror traffic only where packets are justified.
• Decide and document which traffic is decrypted, why, and who can read it.
• Join EDR and NDR data on host, address, user and time in one SIEM or XDR layer, with synchronised clocks and DHCP and DNS logs.
• Build beacon-to-process and lateral movement confirmation correlations, then test them with authorised emulation.
• Protect both platforms as tier 0: restricted administration, phishing-resistant MFA and change logging.
• Review sensor drop rates and agent health weekly.

Standards and references

• NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems
• CISA, NSA, FBI and partners: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24-038A)
• CISA: #StopRansomware Guide
• MITRE ATT&CK: Disable or Modify Tools
• IETF: TLS Encrypted Client Hello (RFC 9849)
• IETF: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
• CISA: Microsegmentation in Zero Trust, Part One: Introduction and Planning
• MITRE D3FEND: Network Traffic Analysis

Related NHI Mgmt Group resources: Microsegmentation vs ZTNA, Command and Control (C2) Guide, Lateral Movement Guide, XDR Guide.