Zero-Trust Has a Layer 2 Blind Spot — And ARP Is Standing Right in It

Zero-trust architecture has become the dominant security framework for enterprise IT in the United States, and for good reason. By eliminating implicit trust and requiring continuous verification at every access point, zero-trust models have meaningfully reduced the blast radius of credential-based attacks and lateral movement exploits. Yet a persistent and underappreciated vulnerability remains in many of these deployments: the Address Resolution Protocol.

For all the rigor applied at Layers 3 through 7 — identity federation, encrypted tunnels, micro-perimeters, software-defined access policies — Layer 2 often operates under a set of assumptions that would be unacceptable anywhere else in a zero-trust model. ARP, by its original design, is unauthenticated and stateless. It trusts the network. And a framework built on the principle of trusting nothing cannot afford to leave that contradiction unaddressed.

Why Microsegmentation Alone Is Not Enough

Microsegmentation has become a cornerstone of zero-trust implementation. By dividing a network into granular zones and enforcing strict east-west traffic controls between workloads, security teams can contain threats that would otherwise move freely once inside a perimeter. The logic is sound. The execution, however, frequently leaves a gap.

The problem is that microsegmentation tools — whether implemented through software-defined networking platforms, hypervisor-based controls, or next-generation firewalls — typically operate at Layer 3 and above. They inspect IP headers, evaluate identity attributes, and enforce policy based on application context. What they do not consistently address is how IP addresses are resolved to MAC addresses within each segment.

Within any given microsegment, ARP traffic continues to flow. Devices still broadcast ARP requests, and neighbors still respond. If an attacker gains a foothold within a segment — through a compromised endpoint, a misconfigured workload, or a rogue device — they retain the ability to manipulate ARP tables, redirect traffic, and intercept communications that the microsegmentation policy was designed to protect. The segment boundary holds; the segment interior does not.

The Compliance Dimension: NIST and CIS Benchmarks

For organizations operating under NIST SP 800-53 or aligning with CIS Controls, the implications extend beyond operational risk. Both frameworks call for controls that address network-level integrity, and neither treats Layer 2 as an afterthought.

NIST SP 800-53 Revision 5 includes controls under the System and Communications Protection (SC) family that require organizations to implement boundary protection and prevent unauthorized information transfer. When ARP poisoning can redirect traffic silently within a segment, those controls are functionally incomplete regardless of what the architecture diagram shows.

The CIS Controls, particularly Control 12 (Network Infrastructure Management) and Control 13 (Network Monitoring and Defense), similarly expect organizations to understand and govern the behavior of traffic at all layers. An ARP table that can be freely manipulated by any device within a subnet is not a governed network — it is a network with a governance-shaped gap.

Security teams pursuing formal compliance attestations should treat ARP validation as a required component of their microsegmentation documentation, not an edge case to be addressed after the fact.

Practical Strategies for Protocol-Level ARP Controls

Integrating ARP validation into a zero-trust microsegmentation strategy does not require a wholesale redesign of existing infrastructure. Several targeted approaches can meaningfully close the Layer 2 gap.

Dynamic ARP Inspection (DAI) remains one of the most direct controls available on managed switching infrastructure. By validating ARP packets against a trusted DHCP snooping binding table, DAI prevents unauthorized devices from issuing ARP replies that could poison neighboring caches. Within a microsegmented environment, DAI should be configured on a per-VLAN basis and treated as a baseline requirement rather than an optional hardening step.

Static ARP entries for high-value assets — servers, gateways, security appliances — eliminate the attack surface entirely for those endpoints. While impractical at scale, static bindings for critical infrastructure components are a defensible and auditable control that aligns well with zero-trust principles of explicit verification.

ARP traffic monitoring and anomaly detection should be integrated into the broader network detection and response posture. Unusual volumes of ARP replies, unsolicited gratuitous ARP broadcasts, or MAC address changes on previously stable bindings are all signals that warrant investigation. Organizations that have deployed SIEM platforms should verify that ARP-level telemetry is being ingested and correlated — many default configurations do not capture this data.

Network Access Control (NAC) integration can further enforce ARP hygiene by ensuring that only authenticated and authorized devices are permitted to participate in ARP exchanges within a given segment. When NAC policies are extended to validate device identity before allowing Layer 2 communication, the trust model becomes genuinely consistent from the physical layer upward.

Credential Gaps in the Security Workforce

One reason ARP controls remain underdeveloped within zero-trust deployments is that the professionals designing and implementing these architectures frequently lack deep familiarity with Layer 2 protocol behavior. Network security certifications that emphasize policy frameworks, cloud-native tools, and identity management do not always require practitioners to understand how ARP operates, where it can be manipulated, and what controls exist to govern it.

This is a structural gap in the industry's approach to credentialing. An engineer who can configure a zero-trust policy engine but cannot explain how ARP requests propagate within a VLAN — or how an attacker could exploit that propagation — is operating with an incomplete model of the environment they are responsible for protecting.

Protocol-level knowledge is not a niche specialty. It is foundational to the kind of rigorous, assumption-free thinking that zero-trust architecture demands. Organizations that invest in developing this competency across their security teams will find themselves better positioned to identify the gaps that compliance checklists miss and that adversaries reliably exploit.

Closing the Gap Before the Next Assessment

Zero-trust is not a product or a configuration. It is a philosophy that demands consistency — every asset verified, every communication validated, no layer trusted by default. ARP has survived as an exception to that philosophy for long enough.

For security teams preparing for their next compliance assessment, the question is straightforward: can you demonstrate that ARP behavior within each microsegment is governed, monitored, and validated? If the honest answer involves uncertainty, that uncertainty represents a finding waiting to be written.

Protocol-level controls at Layer 2 are not supplementary to zero-trust implementation. They are the part of the architecture that completes it.