Address Resolution Protocol (ARP) maps an IPv4 address to a local network hardware address by broadcasting a request and receiving a reply from the device that owns that IP. Hosts cache the result for later use. Defenders monitor for spoofed replies, duplicate IPs and unexpected ARP changes because attackers can poison caches and intercept traffic.
How ARP turns an IPv4 address into a local link-layer address
ARP sits between IP and the local network hardware layer. A host first checks whether it already has a cached mapping for the target IPv4 address. If not, it sends a broadcast request on the local segment asking which device owns that IP, then accepts the reply from the owner and stores the result for later use. That cache is what makes repeated local delivery efficient.
ARP is intentionally local-scoped, so it only works within the broadcast domain where the target can hear the request. The protocol does not route across networks and it does not verify that the responder is trustworthy by itself. That design keeps it simple, but it also means the surrounding network controls determine how much you can trust the mapping.
What ARP caches, timeouts, and broadcasts change operationally
Because ARP is stateful, the quality of the cache matters as much as the initial lookup. Hosts reuse prior answers until the entry expires or is refreshed, which reduces traffic but can preserve a bad mapping long enough to disrupt connectivity or steer traffic incorrectly. In practice, a stale entry, an overlapping address, or an unexpected reply can affect only a few flows at first, then spread as more hosts refresh their tables.
Broadcast behavior also matters at scale. Every unresolved IPv4 destination generates a local query, so large flat networks create more ARP chatter and more opportunity for inconsistent observations during troubleshooting. Segmentation, accurate addressing, and consistent duplicate-IP handling reduce confusion when operators are trying to separate a normal resolution event from an abnormal one.
IANA is the right reference point when you need authoritative registry context for protocol parameters and internet identifiers that sit around ARP-dependent operations.
Why ARP is a common target for spoofing and traffic interception
ARP trust is based on who can speak first on the local segment, not on strong identity proofs. That makes cache poisoning, duplicate-IP confusion, and unsolicited replies useful to attackers who want to redirect traffic, intercept sessions, or create intermittent outages. The protocol’s simplicity is the reason defenders have to rely on monitoring, segmentation, and host or switch protections rather than on ARP itself to prove authenticity.
Unexpected ARP changes are therefore a useful early warning signal. A sudden shift in the hardware address associated with a sensitive host, especially when it does not match the expected port or device inventory, can indicate spoofing or a misconfiguration that deserves immediate validation. On managed networks, it is the combination of ARP observations, switch telemetry, and endpoint context that tells you whether the change is routine or suspicious.
Risk and Threat Considerations
ARP is a low-friction attack surface because any host on the same local segment can try to influence cache state. The main risk is not just wrong forwarding, but the downstream ability to intercept, degrade, or selectively blackhole traffic while appearing to be a normal local response.
Failure mechanism: An attacker sends forged replies or exploits duplicate addressing so that one or more hosts update their cache with the wrong hardware address, which diverts or disrupts traffic until the cache is corrected.
Impact: The result can be session interception, denial of service, hard-to-trace intermittent failures, and misleading diagnostics when operators trust the cache more than the underlying path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1040 — Network Sniffing | ARP poisoning can redirect local traffic for interception on the segment. |
| Recommendation — Monitor local broadcast anomalies and correlate them with suspicious traffic redirection. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | ARP trust failures can subvert intended local traffic flow controls. |
| SI-4 — System Monitoring | Unexpected ARP changes are a detection signal for spoofing or misconfiguration. | |
| Recommendation — Enforce path controls that limit unauthorized local traffic redirection. Alert on cache churn, duplicate IPs, and unexpected MAC-to-IP changes. | ||
Practitioner Guidance
What to verify: Treat a new ARP entry as trustworthy only when it matches the expected IP-to-MAC mapping, switch port, and device owner. If the mapping changes unexpectedly, validate it against inventory and recent change activity before assuming a network fault.
What to measure: Watch for repeated cache churn, duplicate-IP alerts, and sudden MAC moves for critical hosts. Those signals are more useful than a single anomaly because they show whether the issue is isolated noise or an active poisoning attempt.
Practitioner takeaway: ARP is simple by design, so the security question is never “can it resolve an address” but “how quickly can you detect and contain a forged local mapping before it affects traffic.”