Why Network Segmentation Fails Even When VLANs Exist

VLANs are useful for reducing broadcast domains, separating groups of devices logically, simplifying network design, and creating a foundation for access control. But assigning different VLAN IDs does not automatically create meaningful security boundaries. Consider a typical enterprise environment containing user workstations, application and infrastructure servers, network management systems, wireless users, guest devices, cameras and other special-purpose devices. Placing these groups into separate VLANs is a reasonable starting point. The security question begins when communication between those VLANs is required.

If unrestricted Layer 3 routing exists between them, a workstation in one VLAN may still be able to communicate directly with systems in several others. The network may look segmented on a diagram while remaining broadly reachable in practice. This is the distinction between network organisation and security segmentation. A VLAN creates a boundary. Policy determines whether that boundary has security value.

Segmentation often becomes weaker over time rather than failing during the initial design. A new application needs access to a server, so an exception is created. A support team needs access to a management interface, so another rule is added. A legacy application stops working after restrictions are introduced, and a broader rule is created to restore service. A temporary troubleshooting requirement appears and is never removed.

Individually, each decision may appear reasonable. Collectively, they can turn a segmented architecture into a permissive access model. Common warning signs include broad source and destination networks, services defined as “any”, user networks with direct access to management interfaces, unnecessary communication between endpoint groups, permanent temporary exceptions, and old rules with no clear owner.

The VLAN structure still exists, but the trust boundaries become unclear. The problem is not that VLANs have failed technically. The problem is that connectivity has grown faster than policy discipline.

The most important part of segmentation is what happens when traffic crosses from one trust zone to another. That traffic should pass through a deliberate enforcement point. Depending on the architecture, this may be a firewall, a Layer 3 switch with appropriate access controls, or another policy enforcement mechanism. The specific technology is less important than the principle: crossing a security boundary should require an explicit decision.

A common mistake is to create VLANs while allowing unrestricted inter-VLAN routing elsewhere. Technically, the VLANs exist. Operationally, most of the environment can still communicate freely.

A stronger policy follows a simple rule: permit what the service actually needs, not what is easiest to configure. If a user network needs access to a specific application server over HTTPS, that does not justify access from the entire user subnet to the entire server network. A useful access rule should define source, destination, required service, direction, operational purpose and logging requirement.

The objective of segmentation is not to guarantee that no endpoint will ever be compromised. It is to prevent a compromise in one area from automatically becoming unrestricted access to the rest of the environment.

Management traffic should normally exist within a stronger trust boundary than ordinary user traffic. Switches, firewalls, hypervisors, wireless controllers, storage systems and server management interfaces provide privileged access to the environment. If the same workstation used for email, web browsing and everyday office activity can directly access those interfaces, the management VLAN has limited value as a security boundary.

Administrative interfaces should not be generally reachable from user networks. Access should originate only from approved systems or controlled paths, only required management protocols should be permitted, and authentication and administrative activity should be logged. Guest or untrusted networks should have no route to the management plane.

Creating a VLAN named “Management” is not enough. The security benefit comes from creating a different trust model around the systems inside it.

A guest SSID may use a dedicated VLAN and subnet, but the real question is where that network is permitted to communicate. In most environments, a guest device requires very little:

Guest client → Internet

It normally does not need direct access to staff workstations, internal servers, directory services, management interfaces or other trusted networks.

The same logic applies to cameras, IoT devices, printers, test systems and unmanaged endpoints. Segmentation becomes more useful when device groups are separated according to function and trust rather than simply according to physical location.

The important question is not only where a device is connected, but what that device is expected to communicate with.

A well-designed security boundary should not only restrict traffic. It should also provide useful evidence about what attempted to cross that boundary.

There is a significant difference between saying “These networks are separated” and being able to say “This workstation attempted to reach this server over this service at this time, and the connection was denied.”

Useful segmentation should therefore produce visibility through firewall allow and deny logs, authentication events, endpoint telemetry, network connection metadata, DNS activity, administrative access logs and alerts for unusual cross-segment communication.

During an incident, investigators need to understand where activity began, which systems were reachable, which connections were attempted, which attempts succeeded and which controls prevented further movement.

A network boundary that cannot be observed may still reduce risk, but it becomes much harder to understand whether it worked as intended.

Segmentation and visibility should therefore be designed together.

A practical enterprise environment does not need dozens of security zones on the first day. It needs trust boundaries that can be understood and maintained.

A simple model might include:

• Users — managed workstations used for normal business activity.
• Servers — application and infrastructure services accessed only as required.
• Management — administrative interfaces and privileged infrastructure access.
• Guest — untrusted devices requiring Internet access without access to internal systems.
• Special-purpose devices — cameras, IoT, printers, operational equipment and other systems with narrow communication requirements.

A simplified policy model could be:

• Users → required application services: allow
• Users → management interfaces: deny
• Guest → internal networks: deny
• Guest → Internet: allow
• Special-purpose devices → required servers: allow only required services
• Management systems → infrastructure interfaces: allow only from approved administrative sources
• Unnecessary cross-segment traffic: deny and log

The exact model will vary between organisations. What matters is that every boundary has a reason and every permitted path can be explained.

If nobody can explain why two segments are allowed to communicate, that rule deserves review.

Network segmentation is easy to recognise on a diagram.

Effective segmentation is harder.

It requires logical separation, routing design, policy enforcement, appropriate trust boundaries, visibility and continuous review to work together.

A network with five well-defined zones and disciplined access control may be considerably more defensible than one containing thirty VLANs connected through broad rules.

For that reason, VLAN count is a poor measure of segmentation maturity.

A more useful question is:

If one device is compromised, what can it reach next — and why?

The quality of that answer reveals far more about the network's real security boundaries than the number of VLANs ever will.