EDR Telemetry vs Full Packet Capture: Which Evidence Answers Your Investigation

Investigators routinely discover, halfway through an incident, that the evidence they kept cannot answer the question they now need answered. Endpoint detection and response (EDR) telemetry tells you which process did what on a managed host; full packet capture (FPC) tells you exactly what crossed a network link, but only for as long as you can afford to keep it and only as far as encryption allows. This guide compares the two as investigative evidence: questions answered, encryption and retention limits, blind spots, cost, privacy and worked scenarios. It is written for incident responders, forensic analysts and security architects deciding where to spend collection budget. Collection design is covered in the EDR Telemetry Guide and the Network Monitoring and Packet Capture Guide; this page is about which evidence to reach for, and why.

Key takeaways

• EDR answers "who and how" on a host: process lineage, command lines, user context and which binary opened a connection, but rarely what the connection carried.
• Packet capture answers "what and how much" on the wire: payload contents, protocol behaviour and exact byte counts, but encryption hides content and it says nothing about which process sent it.
• Retention decides which evidence exists: packet capture is usually measured in days, EDR telemetry in weeks or months, and dwell time is often longer than both.
• Each has a structural blind spot: EDR cannot see unmanaged devices, appliances or a host where the agent was disabled; packet capture cannot see traffic that never crosses a sensor.
• Privacy law applies to both: packet capture collects content, including personal and special category data, so it needs a documented purpose, a DPIA and strict access control.

The short answer

If your investigations mostly start from a suspicious host and need to know how an attacker got there and what they ran, EDR telemetry is the higher value source. If they turn on what left the network, whether data was exfiltrated, or what happened on devices you do not manage, network evidence is essential, and full packet capture is the deepest form of it. Most teams get the best return from complete EDR coverage, long retention of network metadata (flow records and protocol logs), and targeted full packet capture at a few chokepoints with short retention. The Incident Response vs Digital Forensics comparison explains how these sources feed the response and forensic tracks.

EDR telemetry as evidence: threat model, architecture and limits

What it is built to catch: host-centric attacker behaviour. Execution through scripting interpreters (ATT&CK T1059), credential access, persistence, lateral movement tools launched on a host, and the parent and child process chains that tie them together. MITRE D3FEND describes the analytical techniques this enables as Process Analysis (D3-PA) and Process Lineage Analysis (D3-PLA).

Architecture in words: the agent subscribes to kernel and operating system event sources (on Windows, kernel callbacks and Event Tracing for Windows; on macOS, the Endpoint Security framework; on Linux, eBPF or audit subsystems), normalises the events and ships them to a cloud console or an on premises store. Sysmon is a useful illustration of the event model: Event ID 1 records process creation, Event ID 3 records network connections linked to the originating process, and Event ID 22 records DNS queries. Sysmon's network connection event is disabled by default and needs an explicit configuration filter, which shows how easily the one event that links hosts to network activity can be missing.

Questions EDR answers well:

• Which process launched the malicious binary, under which account, from which parent?
• When did the attacker first execute code on this host, and what did they run next?
• Which process opened a connection to this external IP address, and how often?

Limits:

• No content: EDR can show that rclone.exe connected to a cloud storage endpoint and sent traffic, but not which files were inside the encrypted session. Some products report bytes sent per connection; many do not.
• Filtering: vendors drop or aggregate events to manage volume. What the console shows is the vendor's selection, so confirm what is recorded before relying on absence of evidence.
• Tampering: an attacker with local admin rights may stop or blind the agent. See the EDR Evasion and Defence Guide.

Full packet capture as evidence: threat model, architecture and limits

What it is built to catch: network-centric behaviour. Exfiltration over the command and control channel (T1041) or an alternative protocol (T1048), command and control over application layer protocols (T1071), exploitation of public facing applications (T1190) where the request itself is the evidence, and network sniffing (T1040) on segments where credentials travel in clear. D3FEND groups the analysis under Network Traffic Analysis (D3-NTA).

Architecture in words: a TAP or SPAN port copies traffic to a sensor, which writes packets to disk in pcap or pcapng format and usually indexes session metadata for search. Arkime, an open source full packet capture system, is a good reference for the economics: its documentation estimates that 1 Gbps of uncompressed traffic consumes around 11 TB of disk per day, gives 2.5 Gbps for 7 days as roughly 192.5 TB, and estimates the session metadata index at about 5 percent of packet storage for the same period. Packet data is deleted as capture disks fill, oldest first. See the Arkime Full Packet Capture Guide and the TAPs and packet brokers guide.

Questions packet capture answers well:

• What exactly did the attacker send in the exploit request, and what did the server return?
• How many bytes left for this destination, over which protocol, at what times?
• Was data in a clear text protocol (FTP, HTTP, SMB without encryption, some OT protocols) and can it be reconstructed?

Limits:

• Encryption: RFC 8446 states that in TLS 1.3 all handshake messages after ServerHello are encrypted, including the server certificate, and static RSA key exchange was removed, so traffic cannot be decrypted later with the server's private key. The ClientHello, including the server name extension, remained visible until Encrypted Client Hello, published as RFC 9849 in March 2026, which encrypts the ClientHello including the server name. As ECH adoption grows, packet capture of encrypted traffic is reduced to IP addresses, ports, timing and sizes.
• Retention: at multi gigabit rates, days of capture is already expensive. US federal guidance in OMB M-21-31 requires full packet capture to be stored for only 72 hours, against 12 months active and 18 months cold storage for most other log types, which reflects the cost.
• No process context: a flow from a host's IP address does not say whether it came from a browser, a backup agent or malware.
• Placement: an edge sensor cannot see internal lateral movement.

Encryption and retention: what each source still tells you

The practical consequence: for incidents discovered weeks or months after initial access, full packet capture is usually irrelevant to the early timeline, and EDR plus network metadata carry the investigation. Packet capture earns its cost for incidents detected quickly, clear text content questions, and targeted live capture after detection. See the TLS Inspection vs Encrypted Traffic Analysis comparison and the Log Management and Retention Guide.

Unmanaged device blind spots

EDR is only as complete as agent deployment. The devices most often involved in serious intrusions are frequently the ones with no agent: VPN concentrators and firewalls, load balancers, hypervisor hosts, storage appliances, printers, building management systems and OT controllers. For these, network evidence is the main source, supplemented by the device's own logs.

• Edge appliances: capture or log traffic on both sides, so activity from a compromised appliance can be traced inward.
• OT and IoT: passive network monitoring is often the only safe collection method, because agents and active scans may disrupt controllers. See the OT Network Security Monitoring Guide.
• Personal and contractor devices: under a BYOD model, the organisation may not have the right to deploy EDR at all; network and identity provider logs are the evidence. See the BYOD Security Programme.
• Disabled agents: a host whose agent stopped reporting is effectively unmanaged for that period. Network evidence becomes the only independent record.

Where identity fits

Many intrusions use valid credentials: service account passwords, API keys and tokens. EDR shows which process used a credential on a host; packet capture of clear text protocols can expose the credential itself, which turns the capture store into a sensitive secret repository. Restrict access to captures as you would to a secrets vault, and if an investigation finds credentials in captured traffic, treat them as compromised and rotate them. For cloud and SaaS token misuse, identity provider and audit logs are the primary evidence. See the Identity Telemetry Requirements guide.

Storage cost

Cost levers: exclude known bulk flows (backups, software updates, streaming) from packet capture; truncate encrypted sessions after the handshake (Arkime notes that excluding full TLS sessions can significantly reduce storage); keep metadata far longer than packets; and for EDR, export only the event types investigations depend on (process creation, network connection, DNS, authentication, file creation in sensitive paths) to cheaper long term storage.

Legal and privacy issues

Packet capture collects communication content: emails, documents, web sessions, potentially health data or trade union correspondence. EDR telemetry collects detailed records of user activity on a device. In the UK, the ICO's guidance on monitoring workers (currently under review following the Data (Use and Access) Act) expects a documented lawful basis, a data protection impact assessment before high risk monitoring, transparency to workers before monitoring starts, a specific purpose rather than monitoring "just in case", the least intrusive effective method, and retention no longer than necessary under a retention schedule. Where special category data is likely to be captured, a processing condition is needed as well as a lawful basis.

• Proportionality: default to metadata; capture content only for defined segments or investigations.
• Access and audit: limit who can open packet data, log every search and export, and require a case reference.
• Evidence integrity: when captures or EDR exports may be used in disciplinary or legal proceedings, hash them on export and record custody. See the Evidence Handling and Chain of Custody Guide.

This is not legal advice; involve your data protection officer and legal counsel before deploying content capture, as NIST SP 800-86 also advises for forensic practices generally.

Investigation scenarios

Worked scenario in detail: a manufacturer's SOC sees an EDR alert for a credential dumping tool on a jump server. EDR lineage shows the tool was launched from a remote desktop session by a service account that normally only runs scheduled jobs. EDR on the jump server shows the inbound remote desktop session came from the IP address of the VPN appliance, which runs no agent. The appliance's own logs show a session for a contractor account with no MFA. Packet capture at the internet edge, kept for five days, covers the last three days of the intrusion and shows a 40 GB TLS 1.3 transfer from a file server to a cloud storage IP address. EDR on the file server attributes that connection to a renamed sync utility started by the same service account. The capture cannot show which files were in the transfer, but EDR file events show which directories the utility read. Together they give scope, volume and attribution; neither source alone gives all three.

Decision guidance

Implementing a balanced evidence strategy

1. List your investigation questions: review the last ten incidents and record which evidence answered each question and which questions went unanswered.
2. Close EDR coverage gaps first: reconcile the agent list against the asset inventory, alert on hosts that stop reporting, and enable the network connection and DNS events if your product or Sysmon configuration leaves them off.
3. Set retention by question, not by default: align EDR export and network metadata retention with realistic dwell time; keep packet capture only where its days of coverage still answer questions.
4. Place packet sensors at chokepoints: internet egress, data centre core and both sides of edge appliances. Pilot one link and measure volume before sizing.
5. Complete the privacy assessment before go-live: DPIA, worker notice, access policy and retention schedule.
6. Test with a purple team exercise: simulate exfiltration and lateral movement, then check that both sources recorded what was expected and that analysts can correlate them by time and IP address.

Detection and measurement

• EDR coverage: percentage of inventoried endpoints with a healthy agent reporting in the last 24 hours.
• Retention versus dwell time: EDR and metadata retention days compared with the median dwell time of your own incidents.
• Packet capture effective window: actual days of capture available per sensor, measured weekly, since it shrinks as traffic grows.
• Unanswered questions rate: investigation questions closed as "insufficient evidence" per quarter, by missing source.
• Correlation time: median time to link a network event to a process and user during investigations.
• Capture access audit: packet data accesses without a case reference, which should be zero.

Framework mapping

Common failure patterns

• Buying packet capture for exfiltration questions on encrypted traffic: without decryption, captured TLS 1.3 sessions answer no more than flow records do, at many times the storage.
• Assuming the EDR console keeps everything: filtering and short default retention mean the early timeline is missing when the incident is found late.
• No network evidence around edge appliances: the device that let the attacker in has no agent and no capture, so initial access cannot be scoped.
• Treating captures as ordinary logs: broad access to content that includes personal data and credentials, with no DPIA or audit trail.
• Disabled agent, no alert: the attacker stops the agent and nobody notices the silence until the investigation.

Practitioner checklist

• Map your recurring investigation questions to the evidence source that answers each one.
• Measure EDR coverage against the asset inventory and alert on silent agents.
• Confirm network connection and DNS events are recorded on endpoints.
• Export key EDR event types to storage that outlasts typical dwell time.
• Keep network metadata for months and full packets for days, at chokepoints.
• Cover both sides of edge appliances and other agentless devices with network evidence.
• Complete a DPIA, worker notice and access policy before content capture goes live.
• Restrict and audit access to packet stores; rotate any credentials found in captures.
• Test correlation between host and network evidence in an exercise.

Standards and references

• NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• OMB: M-21-31 Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents
• IETF: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
• IETF: TLS Encrypted Client Hello (RFC 9849)
• ICO: Data protection and monitoring workers
• ASD's ACSC and partners: Best Practices for Event Logging and Threat Detection
• Microsoft Sysinternals: Sysmon
• Arkime: FAQ

Related NHI Mgmt Group resources: Incident Response vs Digital Forensics, Network Forensics Guide, Endpoint Telemetry Guide, Zeek Network Monitoring Guide, Data Exfiltration Guide.