Cloud-Native Environments Have Rendered Traditional ARP Spoofing Defenses Largely Ineffective — Here Is What Security Teams Must Do Instead

The conventional playbook for ARP spoofing mitigation is well established. Deploy Dynamic ARP Inspection on managed switches. Bind IP addresses to MAC addresses through DHCP snooping. Segment broadcast domains aggressively. These controls, implemented correctly in a traditional on-premises environment, provide meaningful protection against a well-understood class of attack.

The problem is that the infrastructure assumptions underlying every one of those controls have been quietly dismantled by the shift to cloud-native architecture. Organizations that have moved workloads into containerized environments, serverless platforms, or multi-cloud configurations are applying Layer 2 security thinking to infrastructure that no longer operates at Layer 2 in any conventional sense. The result is a compliance posture that looks defensible on paper and provides substantially less protection than security teams believe.

This article examines the specific points at which traditional ARP defenses break down in modern environments — and identifies the controls that have demonstrably replaced them.

Why Legacy Defenses Were Built for a World That No Longer Exists

Dynamic ARP Inspection, the most widely deployed ARP spoofing control in enterprise environments, operates at the switch port level. It intercepts ARP packets, validates them against a trusted binding database populated by DHCP snooping, and drops packets that do not match. This is an elegant and effective control — for environments where traffic traverses physical or virtual managed switches that the security team controls.

In a Kubernetes cluster, traffic between pods within the same node typically never touches a switch. It moves through virtual network interfaces managed by the container runtime and the CNI (Container Network Interface) plugin. In AWS VPCs, ARP is not even used for inter-instance communication within the same subnet in the traditional sense — Amazon's network virtualization layer handles address resolution through a centralized mapping service that operates outside the visibility of conventional ARP monitoring tools.

In serverless environments, the concept of a persistent network identity attached to a MAC address is essentially absent. Functions spin up, execute, and terminate — often on infrastructure shared with workloads from other customers — with no stable Layer 2 identity to monitor or protect.

Applying DAI to these environments is not merely ineffective. It is, in most cases, architecturally impossible.

The Attack Surface That Has Moved, Not Disappeared

It would be a mistake to conclude that ARP-level threats are irrelevant in cloud-native environments. The attack surface has shifted, but it has not closed.

In Kubernetes environments, ARP spoofing remains a viable attack vector at the node level. A compromised container with sufficient privileges can manipulate ARP tables on the host node, enabling man-in-the-middle positioning against other pods running on the same node. This is particularly concerning in multi-tenant clusters where workload isolation is assumed but not enforced through hardware-level controls.

In hybrid environments — where on-premises infrastructure connects to cloud VPCs through VPN tunnels or Direct Connect links — the trust boundary between the two environments creates exploitable ambiguity. An attacker who has established a foothold on the on-premises side can use ARP manipulation to intercept traffic destined for cloud-hosted resources, particularly when routing between the environments relies on assumptions about Layer 2 identity that the cloud side cannot validate.

In multi-cloud scenarios involving cross-account network peering, the absence of a shared control plane means that neither cloud environment can enforce binding policies that the other recognizes. This creates gaps that sophisticated threat actors have begun to exploit deliberately.

What Modern Detection and Containment Actually Looks Like

Effective ARP security in cloud-native environments requires abandoning the switch-centric control model and replacing it with a set of controls that operate at the layers where modern infrastructure is actually visible and manageable.

CNI-Level Policy Enforcement in Kubernetes. Network policies enforced at the CNI layer — using tools such as Cilium, which operates at the eBPF level — can enforce identity-based communication controls that do not rely on MAC address validation. By cryptographically attesting workload identity and enforcing allow-list communication policies, these tools eliminate the conditions under which ARP spoofing between pods can produce meaningful interception.

Cloud-Native Flow Log Analysis. AWS VPC Flow Logs, Azure Network Watcher, and GCP VPC Flow Logs capture network communication metadata that can be analyzed for behavioral anomalies consistent with man-in-the-middle positioning — unusual traffic redirection, asymmetric flow patterns, and communication between hosts that have no documented relationship. While these logs do not capture ARP traffic directly, the behavioral signatures of ARP spoofing attacks are visible in the flow data they produce.

Node-Level ARP Monitoring in Kubernetes Clusters. For Kubernetes environments where node-level ARP manipulation is a credible threat, security teams should implement host-based monitoring that captures ARP table changes at the operating system level on each node. Tools such as arpwatch, deployed as a DaemonSet, can alert on unexpected ARP binding changes without requiring access to physical switch infrastructure.

Zero-Trust Mutual Authentication for Cross-Environment Communication. In hybrid and multi-cloud environments, the most durable protection against ARP-based interception of inter-environment traffic is the elimination of implicit trust based on network address. Mutual TLS authentication between services — where both endpoints cryptographically verify the other's identity before exchanging data — renders successful ARP spoofing attacks largely irrelevant, because the intercepted traffic cannot be decrypted or injected without the appropriate certificate material.

Service Mesh Adoption for East-West Traffic. Service mesh implementations such as Istio and Linkerd enforce mutual TLS for all service-to-service communication within a cluster, provide granular observability into traffic flows, and apply policy at the application layer rather than the network layer. For organizations running containerized workloads, service mesh adoption is currently the single most effective structural control against the class of attacks that ARP spoofing enables.

The Credential Gap This Creates

Security professionals who built their expertise around on-premises Layer 2 controls face a specific challenge in cloud-native environments: the conceptual vocabulary of ARP security is relevant, but the implementation knowledge is almost entirely different. Understanding why ARP spoofing is dangerous — the man-in-the-middle positioning it enables, the traffic interception it facilitates, the lateral movement it supports — remains directly applicable. But knowing how to configure DAI on a Cisco Catalyst switch provides no operational guidance for securing a Kubernetes cluster or a multi-cloud network topology.

Structured training programs that address ARP security across both traditional and cloud-native contexts are increasingly important for practitioners who need to remain effective across the full range of environments their organizations operate. The underlying threat model is consistent. The technical implementation of controls is not.

Organizations reviewing their current ARP security posture should begin by honestly assessing what percentage of their workloads reside in environments where their existing controls actually apply — and treating the remainder as an uncontrolled risk that requires a different approach entirely.