How does ARP work?

How ARP translates between IP and link-layer addressing

ARP sits at the boundary between network-layer addressing and local link delivery. On an Ethernet LAN, a host knows the destination IP address but still needs the destination MAC address before it can place the frame on the wire. ARP provides that mapping on the local subnet, and the result is cached so the host does not need to ask every time.

That mapping is only valid within the local broadcast domain. If the target IP is off-subnet, the host ARPs for the default gateway’s MAC address instead of the remote host’s MAC address. This is why ARP is a local discovery mechanism, not a routing protocol, and why it becomes visible and useful mainly on shared layer-2 segments.

ARP is also deliberately simple, which makes it fast but weakly authenticated. The protocol trusts replies and updates the sender’s local cache based on what it hears on the network. That design is what lets devices communicate with low overhead, but it also creates room for cache poisoning when a hostile device can send forged replies faster than the legitimate peer.

Why ARP is useful, and why it is brittle

For normal operations, ARP removes the need for static address tables on every device and allows endpoints to discover neighbors dynamically. That helps with plug-and-play networking, printer discovery, DHCP-driven environments, and general LAN mobility. The trade-off is that the protocol assumes the local segment is trusted enough that mapping replies can be accepted without strong validation.

Because ARP is chatty and broadcast-driven, it can also be noisy at scale. Large flat networks produce more ARP traffic, more opportunities for cache conflicts, and more blast radius when a device starts emitting incorrect mappings. That is why network segmentation matters: it reduces both routine broadcast load and the number of hosts that can be reached or misled through the same layer-2 path.

In defensive practice, ARP is best understood as a convenience protocol that carries trust assumptions, not as a security control. If you need stronger assurance about neighbor identity or path integrity, you generally have to layer that on through switch controls, segmentation, static bindings where practical, and monitoring for unexpected mapping changes.

What happens when ARP is abused

Attackers abuse ARP by convincing hosts that a different MAC address belongs to a critical IP address, often the default gateway or another high-value local peer. That can let them intercept traffic, redirect flows through a malicious device, or create a denial-of-service condition by blackholing packets. The attack works because the victim updates its cache based on what it sees on the wire, not on a cryptographic proof.

The most common failure pattern is conflicting mappings. A host may learn one MAC for an IP, then quickly see another. When that conflict involves a gateway or server, sessions can degrade, fail, or silently detour through the attacker. Even when the attacker does not read the traffic, the disruption alone can break authentication handshakes, application sessions, and time-sensitive business flows.

ARP abuse is especially effective on shared or poorly segmented networks because the attacker only needs local layer-2 reachability. Once local traffic can be intercepted, the attacker may use the position for credential capture, session theft, lateral movement, or selective blocking. Practical detection therefore focuses on inconsistency, unexpected MAC changes, and traffic that no longer follows the normal local path.

Risk and Threat Considerations

ARP weaknesses matter most where a local network segment carries sensitive traffic or where many systems share the same broadcast domain. A poisoned cache can redirect traffic without touching the routing layer, which means monitoring that only watches upstream perimeter paths can miss the abuse entirely.

Failure mechanism: A forged ARP reply overwrites the victim’s local cache, so packets meant for a trusted IP are sent to the attacker’s MAC address or are dropped.

Impact: The result can be interception, session disruption, or local denial of service, and the same foothold can support follow-on lateral movement if the attacker gains visibility into unencrypted traffic or internal trust flows.

Practitioner Guidance

What to verify: Treat repeated MAC changes for a stable IP as a signal, not noise. Verify the default gateway, critical servers, and other high-value peers against known-good mappings, especially after switch changes, outages, or unexplained latency.

What to prioritise: Use static ARP entries only where the operational cost is acceptable, and reserve them for the small set of assets where mapping stability matters most. For broader coverage, rely on network segmentation and switch-level protections rather than trying to hard-code everything.

Common mistake: Teams often assume ARP is too low-level to matter once perimeter firewalls are in place. In reality, the attack surface is inside the subnet, so internal monitoring and local trust controls are what make the difference.

Practitioner takeaway: ARP is simple infrastructure glue, but its lack of authentication means the real control is the trust boundary around the segment, not the protocol itself.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?