Microsegmentation: From VLANs and Firewall Zones to Identity-Based Policy

The problem segmentation solves

Most intrusions do not end at the first machine. An attacker lands on one laptop or one exposed server, then looks for the next system to reach: a file server, a domain controller, a database, a backup host. In a flat network, every system can reach every other system, so the second step is easy. Segmentation puts walls between groups of systems so that the second step is blocked, logged, or at least slower. The same walls help in other ways. They keep a compromised vendor laptop away from a payment system, keep an infected printer away from a medical device, and give an auditor a clear answer to the question of which systems can reach the regulated data.

NIST SP 800-125B, which covers virtual network configuration, begins its segmentation discussion with an observation that holds for physical networks too. Network segmentation, it says, is often misunderstood. Some practitioners see it as a network-management technique, while others treat it as an integral part of defense in depth, and standards such as PCI DSS cite it as a requirement for data protection. It also states that treating segmentation as the same thing as the use of VLANs is inaccurate. That sentence is the right place to start, because many networks have VLANs and little segmentation.

Step 1: VLANs and subnets

A virtual LAN (IEEE 802.1Q) splits one physical switch fabric into separate broadcast domains. Each VLAN usually maps to one IP subnet. Devices in one VLAN reach each other at layer 2 without passing through a router. To reach another VLAN, traffic goes to a layer 3 gateway. That gateway is where policy can be applied, and if no access list or firewall sits there, the VLANs are separate for broadcasts only. A guest Wi-Fi VLAN that routes freely to the server VLAN is a common example.

NIST SP 800-125B lists the strengths and weaknesses of VLAN-based segmentation in a virtualized data center. On the plus side, VLAN segments can span several hosts and the technique scales further than virtual firewalls per host. On the minus side, it names tight coupling between virtual and physical switch configuration, VLAN sprawl that adds broadcast traffic and mismatches, a limit of just over 4,000 VLAN IDs because of the 12‑bit namespace, and the cost of keeping identical VLAN IDs when a segment spans sites. Overlay networks such as VXLAN, with a 24‑bit identifier, remove the ID limit and the physical coupling, and the same document discusses them as the more scalable approach.

VLANs remain the right first layer. They are cheap, understood by every network engineer, and they give a clean place to attach policy. The weakness is granularity. All systems inside one VLAN trust each other. A VLAN named servers holding fifty hosts is one blast radius of fifty.

Step 2: firewall zones

The next step is to treat groups of VLANs as zones and put a stateful firewall between them. A typical design has an outside zone, a DMZ for internet-facing services, an internal user zone, a server zone, and a management zone. Rules say which zone may talk to which, on which ports. This is the model NIST describes for traffic between virtual segments: all inter-segment traffic is subjected to policy-based inspection and filtering. NIST also gives the common reason, which is that applications are built in tiers (web, application, database) that sit in separate subnets and need controlled connectivity from each tier to the next.

Zones fix the biggest gap, the free-for-all between segments. Their limits are in how coarse the unit is. A rule that allows the user zone to reach the server zone on port 443 allows every user device to reach every server on that port. And traffic inside a zone is not inspected at all, which is where an intruder tends to move once inside. That east-west traffic, between workloads, is exactly what the third step addresses.

Step 3: microsegmentation

NIST SP 800-207, the zero trust architecture standard, describes one approach as ZTA using micro-segmentation. An enterprise places individual resources or small groups of related resources on a unique network segment protected by a gateway security component. The gateway can be an intelligent switch or router, a next-generation firewall or a special-purpose gateway, and it acts as the policy enforcement point (PEP) for that resource. Alternatively, or in addition, the enterprise can implement host-based micro-segmentation using software agents or firewalls on the endpoint. The gateways dynamically grant access to individual requests from a client, asset or service. NIST notes that this approach requires an identity governance program to function fully and relies on managed PEPs that shield resources from unauthorized access and discovery.

This is the shift in thinking. The unit is no longer the subnet, but the workload. Each database server, each file share, each build agent gets its own small perimeter, and the default rule is deny. A hypervisor-based distributed firewall, a host firewall managed centrally, a service mesh policy in Kubernetes, and cloud security groups are all ways to build it. They differ in where the enforcement sits and what they can see, but they share the idea that the rule follows the workload.

Step 4: identity-based policy

The last step is to change what the rules say. A rule that reads allow 10.20.4.0/24 to 10.30.1.15 on 5432 describes addresses. When the database moves, the rule is wrong. A rule that reads allow role app-billing in production to role db-billing on 5432 describes meaning. NIST SP 800-207 states the idea in its zero trust tenets. Access to resources is determined by dynamic policy, including the observable state of client identity, application or service, and the requesting asset, and it may include other behavioral and environmental attributes. Access is granted per session, with the least privileges needed, and network location alone does not imply trust: a request from inside the legacy perimeter must meet the same requirements as one from outside.

In practice, an identity-based design needs three things. First, an authoritative source of labels. Workloads get roles and environments from an inventory, an orchestrator or a cloud tag system; people and service accounts come from the identity provider. Second, a policy engine that turns labels into enforceable rules, and pushes them to each enforcement point. Third, a trustworthy way to bind a packet to an identity: the host agent knows which process and user sent it, a certificate or workload identity proves which service is calling, or a mutually authenticated tunnel carries the identity with the connection. The tenet that all communication is secured regardless of network location points to this: encrypt and authenticate service-to-service traffic so that the identity is real, not inferred from an address.

How CISA frames the journey

The CISA Zero Trust Maturity Model, version 2.0 of April 2023, organizes zero trust into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, and Governance) apply across all of them. Each function in each pillar has four stages: Traditional, Initial, Advanced and Optimal. For the Network segmentation function, the Traditional stage is a large perimeter with macro-segmentation and minimal restrictions on reachability within segments, with multi-service interconnections such as bulk VPN tunnels. Initial begins isolating critical workloads and constraining connectivity to least function, moving toward service-specific interconnections. Advanced expands endpoint and application profile isolation, with ingress and egress micro-perimeters. Optimal is fully distributed micro-perimeters and extensive micro-segmentation around application profiles, with dynamic just-in-time and just-enough connectivity.

The model was written for federal agencies, and a private firm does not have to follow it. It is still useful as a ruler. Honest assessment usually places a mid-size company between Traditional and Initial on the network pillar, and that is a fine place to start. The model's own guidance is that progress is gradual and that each stage requires more protection, detail and complexity. A company does not need Optimal everywhere. It needs Initial for its crown jewels first.

A practical path

• Inventory and classify. List the systems that hold regulated or business-critical data, and the systems that administer them. These are the first workloads to isolate. Our data-protection and HIPAA articles describe how to find them.
• Observe. Turn on flow telemetry (NetFlow, IPFIX or sFlow, or the cloud equivalent) and build a map of who talks to whom. Run it for a full business cycle, including month-end and backup windows, to catch the rare flows.
• Segment the crown jewels first. Put the database tier, the identity systems and the backup servers in their own zones with default deny and a written list of allowed callers.
• Close the management plane. Administrative protocols (SSH, RDP, WinRM, hypervisor and switch management) should be reachable only from a small administration zone or a privileged access workstation, with multifactor authentication.
• Write rules as labels. Choose the label scheme before you write the first rule, keep it small (application, tier, environment, data class), and put it in the inventory.
• Test in monitor mode. Most tools can log what a rule would block. Review the log, fix the allow list, then enforce one application at a time with a rollback plan.
• Handle exceptions in the open. Legacy systems that cannot take an agent get a gateway in front of them. Record each exception with an owner and a review date.

Where it goes wrong

The most common failure is enforcing too early. A rule set built from a guess breaks a month-end job at midnight, the team switches to allow-all to restore service, and the project loses credibility. The monitor-then-enforce sequence prevents that. The second failure is policy sprawl: thousands of address-based rules that nobody can read. Label-based policy keeps the count small. The third is to forget that the policy engine and agents are now critical infrastructure. If the controller is down, what do the agents do? Decide the failure mode (usually keep the last known policy) before the first outage.

Performance and cost also matter. A distributed firewall in the hypervisor adds little latency, but a design that hairpins every flow through a central firewall does. Host agents consume CPU and need patching. And logging every allowed connection from every workload can overwhelm a log pipeline, so decide what to log and for how long. None of this is an argument against the approach; they are costs to plan.

How it fits with the rest of a program

Microsegmentation is one control in a layered program. It works best beside strong identity and multifactor authentication, endpoint detection, patching, tested backups and an incident response plan. It also works with network design at the lower layers: VRFs and VXLAN-EVPN give every business unit or tenant its own routing domain, and the segmentation policy then runs inside and between those domains. Our team designs and operates this kind of segmentation, from VLAN and firewall-zone cleanups to host-based and identity-based policy, and can help a firm decide which step it needs first. Related reading: Private 5G (CBRS) vs Wi-Fi 6E and Wi-Fi 7 on the Factory Floor; Separating Global Networks: VRFs, VLANs and VXLAN-EVPN Across Datacenters.

Sources

• NIST SP 800-207 - Zero Trust Architecture (August 2020)
• NIST SP 800-125B - Secure Virtual Network Configuration for Virtual Machine (VM) Protection (March 2016)
• CISA - Zero Trust Maturity Model, Version 2.0 (April 2023)
• CISA - Zero Trust Maturity Model landing page
• NIST CSRC - SP 800-125B publication page

This article is general information, not legal or security advice for your environment. NIST SP 800-207 and the CISA model were written for U.S. federal use; a private firm should adapt them to its own risk. We read the NIST and CISA PDFs directly. The description of IEEE 802.1Q VLANs, the label-scheme steps, the failure modes and the practical path are general engineering knowledge, not quoted from the sources listed. Product capabilities differ, so confirm enforcement points, agent support and failure behavior in a pilot. Last reviewed November 8, 2026.

Keep reading

Next · InfrastructureAnycast DNS and Edge Load Balancing: BGP, Health Checks and DDoS AbsorptionAnycast announces the same IP address from many places and lets internet routing deliver each client to a nearby site. It is how the DNS root servers and most large content networks stay fast and hard to knock over. This article explains how anycast works with BGP, what RFC 4786 and RFC 7094 recommend, how health checks pull a failing site out of service, why anycast absorbs floods, and where it does not fit, notably long-lived TCP connections.9 min read

• Penetration Testing Explained for Executives: Scope, Reports and How Often to Test8 min
• Ransomware Readiness and Incident Response: A Checklist Based on the CISA #StopRansomware Guide9 min