What is eavesdropping in cybersecurity and how do you prevent it?

Eavesdropping is secretly listening to or capturing communications that you are not a party to. Online it usually means sniffing network traffic, intercepting wireless signals or positioning between two systems. Encrypting data in transit with current TLS, plus verifying who you are talking to, defeats most of it.

What forms does it take?

The word covers more than packet capture.

• Passive network sniffing. MITRE describes adversaries placing a network interface in promiscuous mode or using span ports to see traffic, and notes that captured data may include credentials sent over unencrypted protocols. See T1040.
• Adversary in the middle. The attacker abuses protocols such as ARP or DNS so traffic flows through a system they control, then reads or alters it. See T1557.
• Wireless interception. Radio signals travel beyond the building. Weak or absent encryption lets anyone in range read them.
• Rogue access points. A hotspot with a familiar name makes a phone connect to the wrong network.
• Logs and mirrors. Not every listener is outside. A debug log that records full request bodies is a quiet eavesdropper waiting to be read.
• Audio and video. Compromised meeting software or a smart speaker can capture speech. That is a device and consent problem more than a network one.

Why is passive listening hard to detect?

Passive capture sends nothing, so there is nothing to alert on. A listener on a mirrored port looks exactly like a monitoring tool. That is why prevention beats detection here: assume the path is observable and make the content unreadable.

Why does encryption change the picture?

TLS 1.3, specified in RFC 8446, was designed so that a network attacker can observe and tamper with traffic but still cannot read or silently change it, provided certificates are validated. An eavesdropper still sees metadata: who connected to whom, when, and roughly how much data. Plan for that residue.

Constructed example: a team builds an internal tool that posts login forms over plain HTTP because "it is only on the office network." A contractor's laptop on the same Wi-Fi runs a capture and reads usernames and passwords in clear text. Switching the service to HTTPS with HSTS closes it, with no change in network layout.

What does the metadata still give away?

Even with every byte encrypted, an observer can learn which servers you contact, how often, at what times and roughly how much data moves. DNS lookups, if sent in clear text, list the sites you visit. Server names in older TLS handshakes were visible too. For most businesses this residue is acceptable. For some, such as a health clinic or a legal team, the pattern of contact is itself sensitive, and it is worth asking whether encrypted DNS and a controlled network path are warranted.

How to check or apply this

1. Inventory every protocol that crosses a network and flag anything unencrypted: HTTP, FTP, Telnet, old SNMP versions, plain LDAP and plain SMTP between systems.
2. Require TLS on internal services as well as public ones. Use certificate validation and do not allow clients to skip it.
3. Use WPA3 or WPA2 Enterprise on wireless, and keep guest networks isolated.
4. Harden layer 2: dynamic ARP inspection, DHCP snooping and port security on switches.
5. Protect remote access with an encrypted tunnel or per application access, and verify the server's identity.
6. Review logs and traces for secrets and personal data, and redact at the source.
7. Test it. Capture traffic from a lab host and see what is readable.

What about end to end encryption?

TLS protects each hop between a client and a server. If a message passes through a relay that decrypts it, that relay can read it. End to end encryption keeps the plaintext visible only to the two endpoints. Choose it when you do not want your own infrastructure to be able to read the content.

Quick check

Sources

• MITRE ATT&CK T1040, Network Sniffing
• MITRE ATT&CK T1557, Adversary in the Middle
• RFC 8446, The Transport Layer Security Protocol Version 1.3

Last reviewed: 18 October 2026.