In a three-part series for SDxCentral – Part 1, Part 2, Part 3 – Dell’Oro Group’s Mauricio Sanchez makes a compelling case for proxy-first branch architecture: eliminate private network extension; enforce identity and device posture at the control plane; and route traffic through cloud inspection. The argument is well-constructed, the governance framework is rigorous, and the market data is real. Café networking is not wrong. It is the right design for a well-defined class of enterprise sites.

The question this piece addresses is more specific: what happens to security inside the branch, among the devices and traffic the cloud proxy was never designed to reach.

Where the enforcement model has limits

Café networking secures the path from the user to the cloud: identity, device posture, and zero-trust access to applications reached over the internet. That is a strong answer to how a managed user safely reaches a software-as-a-service (SaaS) application. It is not an answer to what happens inside the branch, on the local network among devices that never send their traffic to the cloud at all.

When the enforcement model depends on agents, zero-trust policy doesn't bend to accommodate devices that don't have one: it simply doesn't apply. The result is exactly the blind spot that LAN microsegmentation and local zero-trust enforcement are designed to close.

A flat LAN, even one with cloud-enforced perimeter policy, remains a free-movement zone once a compromised endpoint, IoT device, or stolen credential is inside. Microsegmentation at the switch and access point (AP) port is what limits the blast radius, and it requires local enforcement infrastructure that the café model intentionally removes.

The café networking series does not ignore this. Part 3 makes the point that large campuses are a poor fit for a pure proxy-first model and lays out a thoughtful campus sequence: segmentation first, then proxy-first wherever feasible, with WLAN and switching handling local segments, and SD-WAN reserved for where local or media characteristics genuinely demand it. The disagreement is narrower. The series treats local enforcement as a time-boxed exception to be governed and ultimately retired. For a large class of enterprise branches, that local enforcement is not a temporary bridge. It is the permanent, load-bearing default.

When a proxy-first model generates so many exceptions that the exception register becomes the architecture, the register stops functioning as a governance tool. What remains is an honest accounting of architectural mismatch, not a failure of governance, but a signal that the model is being stretched beyond its natural fit.

Security has to reach inside the branch, not only above it

The most consequential gap is in security, and it follows directly from where the proxy-first model places enforcement. Two facts about real branches make that gap matter.

First, much of the enforcement in a proxy-first model depends on an endpoint agent, and a large and growing share of branch devices cannot run one. Cameras, sensors, point-of-sale terminals, medical and industrial equipment, printers, and other headless IoT and OT devices have no agent, no posture to evaluate, and no way to route through a client-based control plane. Without an on-premises perimeter and local inspection, those devices are simply unprotected and they are often the easiest point of entry.

Second, the branch LAN itself is east-west territory. When the internal network is treated as a single flat trust zone, a compromise of one device, one set of credentials, or one unmanaged bring-your-own-device (BYOD) endpoint lets an attacker move laterally to everything else on the segment. Ransomware spreads precisely this way: in traffic that never traverses the cloud proxy where the policy lives.

Containing that risk requires controls that live where the traffic is: microsegmentation that isolates users, guests, IoT, and OT into separate zones and permits only explicitly sanctioned flows between them; least-privilege enforcement at the switch port and access point; the ability to discover and fingerprint headless devices and quarantine high-risk ones automatically; and zero trust extended into the LAN, not only into the cloud.

This is the principle of edge-to-cloud enforcement: some inspection belongs in the cloud for scale and SaaS access, but some has to happen locally, at the branch, for the latency-sensitive and device-to-device traffic that never leaves the site. A model that can only enforce above the branch leaves the inside of the branch as the soft target. As branches take on more local services, more unmanaged devices, and more lateral traffic, that soft target grows.

A unified enforcement model

The practical implication is not that enterprises should abandon the café networking model. For microsites and SaaS-first branches, it delivers. The implication is that a complete branch security architecture requires enforcement at two layers: above the branch, in the cloud, through identity, posture, and proxy inspection, and inside the branch, through local segmentation, agentless device visibility, and LAN-level zero trust.

Most enterprises already operate both types of sites. The challenge is not choosing between cloud-delivered security and local enforcement. It is ensuring both layers work together under a unified policy model, one that applies consistently to users, devices, and workloads regardless of whether the traffic goes to the cloud or stays on-premises.

Sanchez's series makes a rigorous case for what cloud-delivered security can accomplish at the access and policy layer. The argument here is not that the model is wrong – it is that it is incomplete for the branch as it actually exists: full of headless devices, east-west traffic, and lateral movement risk that cloud enforcement cannot see. Closing that gap requires enforcement at both layers, above the branch and inside it, under a unified policy model that applies consistently to users, devices, and workloads regardless of whether the traffic goes to the cloud or stays on-premises. That is what it means to build security that follows the traffic all the way to where it lives.