Ask an enterprise security team how far along their Zero Trust program is and the answer is usually specific and confident. Remote access was addressed first, and the architecture there is well understood. The WAN edge followed, and policy at that boundary is now enforced continuously. Both were substantial pieces of work, and both are complete.
Then ask what happens when someone plugs a laptop into a conference room port, or when a building management controller comes online in a wiring closet, and the answer becomes noticeably less specific. In most enterprises the physical campus network is the part of the estate that the Zero Trust program has not reached. It is also, by device count and by the breadth of what it can reach, the largest high-trust zone the organization operates.
Where Zero Trust Programs Actually Stop
For most organizations, the campus fell behind for structural reasons, and not for lack of priority. Remote access and the WAN edge each had a single point of entry to instrument, like a VPN gateway or an SD-WAN edge, so covering that one point did most of the job. However, the campus does not work in the same way. Every wall jack and access port is its own control point, so there was never one place to enforce policy from. The devices connecting to those ports were also all over the map, and a lot of them could not be centrally managed. Furthermore, the campus already had VLANs and port-based authentication, which looked enough like segmentation that it was easy to call the problem solved and move on.
The result is a gap: while an employee gets constantly re-checked, identity-verified access when working from a hotel room, that same employee has much looser access once they are sitting at a desk in the office.
Why the Flat Network Persists
Flat and coarsely segmented campus LANs are not the product of oversight. They are the product of an architecture design goal that was, for a long time, entirely correct: the LAN existed to make things reachable. Its job was to ensure that a device plugged into a port could get to what it needed with minimal configuration and minimal support, and it does that job well.
Segmentation runs against that grain. Every segmentation boundary added is a boundary someone has to design, document, test, and eventually explain when something legitimate stops working. In practice, the safe engineering choice at each individual decision point is the broader zone, because the broader zone generates fewer support tickets. Repeat that choice across a decade of incremental change and the outcome is a network with far fewer meaningful internal boundaries than its documentation suggests.
VLANs and Port Authentication Were Never a Segmentation Strategy
VLANs establish reachability boundaries. They are effective at that and remain a reasonable structural tool to meet the network’s original design goals. But what they do not provide is comprehensive and dynamic policy between endpoints within a zone, which is where the majority of east-west traffic actually flows. More specifically, a boundary drawn at the subnet level does not assess whether one device inside it should have lateral movement to reach another device within the subnet. VLANs only define the outer boundary in which devices may communicate.
Port-based authentication using NAC, similarly, does what it was architecturally designed to do. It makes an admission decision at connection time and answers the question of whether this device may join the network. While that decision is valuable, it occurs at a single point in time when the initial connection is attempted. In addition, an authenticated user is typically granted access to a segmented zone rather than to specific resources within it. Continuous assessment of identity, device posture, and application context with least privilege access is a different function, and treating a one-time admission check as a substitute for continuous checks is where the gap opens.
In an environment built this way, a device that is functioning normally and a device that has been compromised present the same profile to the network, because both were admitted correctly and both are operating inside a designated, segmented zone that permits broad internal reachability. The network is not failing at its job. It is doing exactly what it was designed to do.
Segmentation as a Property of the Fabric
Versa Secure SD-LAN solves this problem by embedding Zero Trust, microsegmentation, and policy-based access control directly into the LAN architecture, and enforcing them as close to the endpoint as the deployment allows. The distinction that matters is between segmentation as an overlay, and segmentation as a property of the fabric itself.
In an overlay model, the network provides reachability and a separate product restricts it. This means two systems hold two views of what should be permitted and someone has to keep them aligned. In the fabric model, enforcement is where the device connects, expressed in the same policy the organization has already written for the WAN, and running on the same operating system. There is no second place for the same intent to live, and therefore no drift between them.
Practically, this means device identification and IoT and OT visibility, microsegmentation, Layer 4 through Layer 7 controls, firewall, and intrusion prevention sit in one platform rather than in adjacent products connected by integration. Policy follows users and devices across LAN, WAN, and cloud, so enforcement does not vary according to where someone happens to be working. Real-time visibility across users and IoT and OT devices comes from a single console, which matters as much as the enforcement itself, since a segmentation policy that cannot be observed is a policy nobody will tighten.
What Changes When Enforcement Reaches the Edge
The immediate effect is on east-west movement. When policy is enforced at the point of connection and expressed per device and per application rather than per subnet, the reachable surface available from any single endpoint narrows substantially. Unauthorized lateral movement stops because detection and containment is happening quickly and starts based on the architecture.
The second effect is operational, and it tends to be the one that decides these programs. A single policy model across WAN and LAN removes the reconciliation work that separate systems create, which is where a disproportionate share of troubleshooting time goes. Configuration is automated rather than hand-maintained, so the design stops depending on the small number of people who remember why the exceptions exist. Mean time to resolve improves for a fairly unglamorous reason, which is that there is one system to look at.
Finishing the Program You Already Started
For organizations that have completed the remote access and WAN edge phases of a Zero Trust program, extending the same model into the campus with Versa Secure SD-LAN is a continuation rather than a new initiative. The principle is already agreed, the sponsorship already exists, and the policy model has already been written and tested. What has been missing is a control point in the LAN capable of enforcing it.
For an organization already running the Versa fabric in the WAN, that control point is an extension of what is in production rather than a parallel architecture to procure, staff, and learn. The segmentation requirement gets met from the platform already deployed, which is a shorter path than any evaluation, and it closes the one zone in the enterprise where the Zero Trust model has, until now, stopped at the door.
