Zero Trust Segmentation vs VLANs: What Actually Changes (and What You Keep)

A VLAN and zero trust segmentation answer different questions. A VLAN is a Layer 2 broadcast domain defined by IEEE 802.1Q, and VLAN membership decides where a device sits. Controls that govern traffic inside a single VLAN do exist: private VLANs, protected ports, and VLAN or port access lists. Each is written against ports, addresses and VLAN IDs, and each grants a permission set fixed at admission and not re-evaluated as identity or context changes. Zero trust segmentation adds a per-connection identity decision independent of network location.

Zero trust segmentation and identity-based microsegmentation name the same control: a policy layer that decides, for each connection, whether one identified asset should be allowed to reach another, wherever either sits on the network.

For the long-form explanation of that control, see identity-based microsegmentation, defined.

What is the difference between zero trust segmentation and VLANs?

A VLAN decides where a device sits on the network. Zero trust segmentation decides whether one device should be allowed to reach another.

The difference starts with design intent. The published abstract of IEEE 802.1Q-2022 reads: “This standard specifies how the Media Access Control (MAC) Service is supported by Bridged Networks, the principles of operation of those networks, and the operation of MAC Bridges and VLAN Bridges, including management, protocols, and algorithms.” The 1998 and 2005 editions describe bridging in the same terms, and no edition’s published abstract mentions security.

Federal guidance treats the distance between the two as a maturity ladder. CISA’s Zero Trust Maturity Model, Version 2.0, April 2023, Table 4, Networks pillar, describes the Traditional stage of network segmentation this way: “Agency defines their network architecture using large perimeter/macro-segmentation with minimal restrictions on reachability within network segments.” At the Optimal stage, “Agency network architecture consists of fully distributed ingress/egress micro-perimeters and extensive micro-segmentation based around application profiles with dynamic just-in-time and just-enough connectivity for service-specific interconnections.”

CISA is explicit that the second builds on the first. The Journey to Zero Trust: Microsegmentation in Zero Trust, Part One: Introduction and Planning, Version 1.0, 29 July 2025, states that microsegmentation “builds upon the concept of macrosegmentation of the private (internal) network space. It further divides these business needs-based boundaries or perimeters and extends them from the private internal network space to all networks internal and external that support business needs.” A longer reading of that document is in Elisity’s guidance on CISA’s Microsegmentation in Zero Trust, Part One.

This page compares one control with one technology. For the category-level comparison, see how microsegmentation differs from broad network segmentation.

What happens to traffic between two devices inside the same VLAN?

Traffic between two devices in the same VLAN is forwarded at Layer 2 by default and reaches the far device without being evaluated.

The enforcement point for a VLAN boundary sits at Layer 3, and by default it evaluates only what crosses that boundary. RFC 5517 (Informational, February 2010), Section 1.1, describes the mechanism: “Once a server learns the Media Access Control (MAC) address associated to the IP address of another computer in the same VLAN, it can establish direct Layer 2 communication with that device without having to go through a Layer 3 gateway/firewall.”

That default changes when a control is explicitly configured inside the VLAN, and several exist. Private VLANs, protected ports, and VLAN or port access lists all govern traffic between members. Each is written against ports, addresses or VLAN IDs rather than against verified identity, which sets what each can express, not whether it works.

Juniper Networks documents the same mechanism independently: “PVLANs provide Layer 2 isolation between ports within a VLAN, splitting a broadcast domain into multiple discrete broadcast subdomains by creating secondary VLANs (community VLANs and an isolated VLAN) inside a primary VLAN.”

The useful self-diagnosis is a question rather than a claim: what percentage of east-west flows in this network never cross a VLAN boundary at all?

Federal policy states the goal for that traffic directly. OMB Memorandum M-22-09, 26 January 2022, quoted in CISA’s Part One guidance, describes approaches that share one aim, “to meaningfully isolate environments, so that an adversary that compromises one application or component cannot easily move laterally within an organization and compromise other distinct environments.” Named incidents and the technique IDs behind them are collected in Elisity’s account of how flat VLANs let lateral movement spread (SolarWinds, Colonial Pipeline, Kaseya).

How do you stop one VLAN from talking to another without doing IP math?

Write the rule against what the devices are rather than what addresses they hold, so the rule never has to be renumbered.

Traffic between two VLANs already passes a Layer 3 hop, so something at that hop has to say no: an access list applied to the VLAN interface, an access list applied to the VLAN itself, or a firewall rule when the routing happens there. All three work. All three are keyed to addresses, which is usually why the question gets asked in the first place. Every new subnet, every merged site and every re-addressed building means the same intent has to be re-expressed in different numbers.

A policy layer keyed to device identity removes the arithmetic instead of automating it. The rule reads that ultrasound machines may reach the imaging archive, and it holds when an ultrasound machine lands in a different VLAN, a different building or a different subnet, because nothing in the rule refers to an address. The VLANs stay where they are. What changes is what the rule is written against, and therefore how often anyone has to touch it.

Is VLAN hopping still a real risk?

VLAN hopping is real, documented, and closed by configuration. Trunk negotiation abuse works when a user-facing port may still negotiate a trunk link, so a connected device can bring one up and reach the VLANs it carries. Double tagging works when a user-facing port sits in the trunk link’s native VLAN: a frame with two 802.1Q tags loses the outer tag at the first hop and is forwarded into the VLAN named by the inner tag. The Defense Information Systems Agency requires both closed by configuration: fix trunk links statically, make user-facing ports access ports, and either give the native VLAN a non-default ID or tag native VLAN traffic (DISA Cisco IOS Switch L2S Security Technical Implementation Guide, V3R1, 24 July 2024). Neither technique is why VLAN-based segmentation falls short as a security control; both are configuration findings a single review closes. The real limit is different: a correctly hardened VLAN still carries no statement about which of its own members should reach each other.

Are VLANs zero trust?

No. A VLAN grants reachability by port and tag, and zero trust requires a per-connection decision that network position cannot make.

NIST SP 800-207, Zero Trust Architecture, August 2020, never names the technology. A full-text search returns no occurrence of the word VLAN. What it states, as Tenet 2 in Section 2.1, is the principle: “All communication is secured regardless of network location. Network location alone does not imply trust.” Section 1 states the consequence: “Perimeter-based network security has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered.”

Applying that tenet to VLANs is Elisity’s analytical step, not NIST’s: a VLAN is by definition a network-location construct, so the tenet governs it even though the document never names it.

IEEE assigned security to separate standards. Access control is IEEE 802.1X-2020, whose published abstract reads: “Port-based network access control allows a network administrator to restrict the use of IEEE 802 LAN service access points (ports) to secure communication between authenticated and authorized devices.” MAC-layer security is IEEE 802.1AE and device identity is IEEE 802.1AR.

Zero trust segmentation vs VLANs, side by side

Zero trust segmentation vs VLANs comes down to one difference that repeats in every row: a VLAN decides where a device sits, zero trust segmentation decides whether one device should reach another, and changing a device’s VLAN typically forces an IP address change while a policy overlay does not. Every row below is a default rather than a law, because a control configured inside a VLAN changes what that VLAN does, and because approaches to zero trust segmentation differ in what they disturb.

Do you have to replace or re-address your VLANs to adopt zero trust segmentation?

Not for approaches that add a policy layer over existing addressing and topology, which require no renumbering and no redesign of the VLAN plan.

Approaches inside the category differ sharply on what they disturb: one that builds a new forwarding fabric changes the transport itself, and one that depends on a host agent never reaches the devices that cannot run one, which on a hospital or plant floor is much of it. The coexistence claim holds for addressing and topology. Not for control planes.

NIST SP 1800-35, Implementing a Zero Trust Architecture: High-Level Document, June 2025, assumes the same starting point. Section 8.3 states that most organizations “will not be starting from scratch. Instead, they will have an existing infrastructure and technology systems that already perform security functions.” Section 8.4 continues: “Initially, the organization’s network may not be well-segmented... As the organization implements ZTA, it should segment its infrastructure into smaller parts.”

The cost of the other path is published. St. Luke’s University Health Network weighed a traditional redesign, and its case study records: “The alternatives on the table were no better,” among them re-IP for every device older than ten years and an 18-month deployment. Daniel Dopsovic, Senior Enterprise Information Security Architect, noted that converting roughly 500 PACS workstations the old way “took well over six months.” That is the price of the legacy alternative St. Luke’s rejected, not the price of what it adopted. The full account is in the published case study of what a decade of VLAN and firewall macrosegmentation actually cost one health system.

Connected medical and OT equipment is where this question gets sharpest, because much of it cannot run an agent and cannot absorb a change window. NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023, is candid about the trade-off. Appendix E.1.3 states: “A VLAN can be used to logically separate areas within a network when physical separation may not be feasible due to cost or other prohibitive measures.” NIST SP 800-82r3 Section 6.2.1.3 records that VLANs can be a cost-effective solution for OT network segmentation, and recommends that organizations consider physically separate network hardware rather than a shared VLAN for high-criticality devices such as those that support safety systems. The vertical versions are worked through in how hospitals compare identity-based microsegmentation with VLANs and NAC and in the NAC versus network segmentation versus microsegmentation comparison for OT.

What happens when a device moves?

What follows the device depends on what the rule was written against: a port group, an admission-time permission set, or the device’s own identity.

RFC 5517 Section 2 supplies the port-group case. Private VLAN treatment is assigned to a group of access-layer ports, so a device that moves to a differently designated port inherits the rules of that port rather than carrying its own. Nothing about the device travels with it.

Where 802.1X is deployed, a downloadable access list pushed at authentication does re-apply when the same device authenticates on a different port, so the permission travels with the device; what does not travel is a decision about each connection, because the permission set is chosen once at admission.

Identity-based policy inverts the dependency. The rule names the device, so moving the device changes nothing about the rule, and the decision is made again on the next connection rather than once at the door.

Where are VLANs still the right answer?

Wherever the job is broadcast-domain containment, traffic organization, or defining the coarse zones a boundary control separates, a VLAN is the right tool. And you already own it.

Each of those jobs is coarse by design, and a policy layer does not replace any of them. CISA’s own macrosegmentation use cases run along the same lines, isolating development and production environments and standing up DMZs. CISA states the trade-off in the same document: “Coarse-grained segments are easier to manage, though may require additional security protections and visibility to account for the potential for increased lateral movement.”

Compliance scope is the third standing job. PCI DSS v4.0.1, June 2024, page 12, states: “Segmentation (or isolation) of the CDE from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce the: Scope of the PCI DSS assessment...” The same page sets the condition: without adequate segmentation, which PCI DSS calls a “flat network,” the entire network stays in scope.

Healthcare carries a parallel expectation. The U.S. Department of Health and Human Services lists Network Segmentation as Enhanced Goal 6.M.B in its Healthcare and Public Health Sector-Specific Cybersecurity Performance Goals, which asks that “Mission critical assets are separated into discrete network segments to minimize lateral movement by threat actors after initial compromise.”

None of that argues for keeping policy in the VLAN plan. It argues for letting a VLAN do the work it is good at while a separate layer decides who may reach whom.

How many VLANs is too many?

Too many is the point at which new VLANs are being created to express policy rather than to describe topology.

The hard ceiling is fixed and rarely the binding constraint. RFC 5517 Section 1, citing IEEE 802.1Q, records that “the IEEE 802.1Q standard [802.1Q] specifies that the VLAN ID field in an Ethernet frame is 12 bits wide. That allows for a theoretical maximum of 4094 VLANs in an Ethernet network (VLAN numbers 0 and 4095 are reserved),” and Section 1.2 adds that “In reality, many devices support a much smaller number of active VLANs.”

The operational ceiling arrives long before the numeric one. Section 1.2 also records that “Since each VLAN requires a separate subnet, there can be potential wastage of IP addresses in each subnet,” and each added VLAN brings addressing, routing and change-control work with it.

So the right number is the number that maps to real trust, performance or management boundaries. When the count is rising because a policy needed somewhere to live, the VLAN plan has stopped describing the network and started standing in for a control.

Why do VLAN segmentation projects stall, and what does the time actually cost?

They stall on administrative overhead, required address changes, and VLANs that cannot tell device types apart, and the cost is labor, not licensing.

St. Luke’s University Health Network is the published case. It attempted macrosegmentation with VLANs and firewalls for a decade without success, and the case study names three causes: administrative overhead, a requirement to change device IP addresses, and an inability to differentiate device types. Door controls, ultrasound machines and EMR workstations sat on the same VLAN, so any policy written at the VLAN level applied to all three at once. Mixed-criticality VLANs are a documented condition there, not a vendor hypothetical.

Daniel Dopsovic, Senior Enterprise Information Security Architect at St. Luke’s, described the arithmetic of that decade plainly: “We had been at this for ten years. We weren’t going to spend another ten.” He also described the inventory problem underneath it, that “most organizations do not have accurate network diagrams, and even if you did, it’s probably just of your IT assets, not your biomedical, not your IoT devices.”

The structural reason the work compounds is recorded in RFC 5517 Section 1.2: each VLAN requires its own subnet, so a segmentation plan expressed in VLANs is simultaneously an addressing plan, a routing plan and a change-control queue. NIST SP 1800-35 Section 8.4 describes the same starting condition and the same direction of travel, a network that is not well segmented at the outset and is divided into smaller parts as a zero trust architecture is implemented.

Nothing on a quote captures that. The cost is the labor of authoring, testing, change-controlling and troubleshooting rules that are expressed in addresses, repeated every time the addresses change, and carried by the team that also has to keep the network running.

How do you move from VLAN-based segmentation to identity-based segmentation?

Start by seeing every asset, then simulate policy against observed traffic, then enforce in stages, leaving the VLAN plan in place throughout.

1. Build the asset and identity picture first. Start from what is actually on the wire, then enrich it from the systems that claim to know: directory, endpoint management, and clinical and OT asset databases. Confirm what the existing infrastructure can enforce and what it can only observe, before any policy is written.
2. Observe before deciding. Record which assets actually communicate with which, so the first policy describes traffic that exists rather than traffic someone remembers.
3. Simulate. Run candidate rules against observed flows and read what would have been denied, before anything is enforced.
4. Enforce in buckets. Take one device class or one site, enforce, confirm, then repeat. The addressing plan does not change while this happens.

That sequence is worked through step by step in a practitioner’s guide to phased rollout. Daniel Dopsovic reported the effect directly: “We were able to simulate our policies, see them in action before they went live, and were able to enable those policies in seconds.”

One published program gives the shape of the timeline. St. Luke’s University Health Network spent about a month preparing its infrastructure, then completed its major segmentation buckets in roughly 46 days, per the published case study’s own narration. David Finkelstein, CISO, states: “We deployed Elisity across 15 hospitals, 350 practices, and 85,000 devices. In two months.” The 46 days covers the segmentation phase across 15 hospitals and 85,000 production devices, not a time-to-first-policy figure, and one program is not a benchmark.

The video case study credits Daniel Dopsovic as Dan Dopsovic, Network Architect, and quotes him on the figure: “Within 46 days, we went from no microsegmentation to having all of our microsegmentation completed.”

Both figures come from published St. Luke’s material: the written case study of what a decade of VLAN and firewall macrosegmentation actually cost one health system, and the St. Luke’s University Health Network video case study.

Do you need 802.1X or NAC first?

No, identity-based zero trust segmentation does not require 802.1X enrollment or NAC deployment first.

802.1X authenticates a device or user at the moment it joins the network, and RADIUS can use the result to choose which VLAN the port lands in, so VLAN membership can absolutely be identity-derived. What the VLAN still does not carry is a decision about each connection afterward: once a device is inside, its membership permits everything membership permits, and the admission decision is not re-evaluated per flow.

Where 802.1X is already deployed, none of that work is wasted. Authentication events become one more identity signal, consumed alongside directory, endpoint and asset-system records rather than replaced by them. The comparison between the two control models is set out in a modern alternative to NAC and 802.1X-driven access control.

What replaces VACL and inter-VLAN ACL sprawl?

A policy written against device identity replaces the list, because one identity rule covers every address that device will ever hold.

Sprawl is a property of the rule language rather than a failure of anyone’s discipline. A list keyed to addresses has to be rewritten when a subnet is added, a site is merged or a device class moves, and the safest edit is nearly always an addition, because nobody deletes an entry they cannot prove is dead. The list grows and the intent behind each line ages out of memory.

Identity-based rules collapse the count because they are written once per relationship rather than once per address pair. Ultrasound machines reaching the imaging archive is a single rule whether those machines sit in four VLANs or forty, and it survives re-addressing, new sites and device replacement without an edit. The access lists that remain are the ones doing genuine boundary work, and they stop being the place where policy is stored.

Frequently asked questions

How do I stop one VLAN from talking to another without doing IP math?

Put the decision somewhere that is not keyed to addresses. Traffic between VLANs already passes a Layer 3 hop, so a rule can be applied there, but it will be written in subnets. A policy layer keyed to device identity expresses the same intent once and survives every re-addressing.

How many VLANs is too many?

The theoretical ceiling is 4094 and real equipment supports far fewer, but the count stops being the constraint long before that. Each VLAN carries its own subnet and its own change-control load. The practical signal is qualitative: VLANs being created to express policy rather than topology.

Do I have to replace or re-address my VLANs to adopt zero trust segmentation?

Not with approaches that layer policy over the addressing already in place. Those leave the VLAN plan intact and decide per connection instead. Approaches that build a new fabric, or that depend on a host agent, disturb more, so the honest answer depends on which approach is on the table.

What can replace growing VACL and inter-VLAN ACL sprawl?

Rules written against device identity. A single identity rule covers every address a device will ever hold, so new subnets, merged sites and replacements no longer force an edit. The access lists that remain are the ones doing real boundary work rather than storing policy.

Is VLAN hopping still a real risk?

It is real, documented and closed by configuration. Fix trunk links statically, make user-facing ports access ports, and either give the native VLAN a non-default ID or tag native VLAN traffic. The structural limit is separate. A correctly hardened VLAN still says nothing about which of its own members should reach each other.

How do I move from VLAN-based segmentation to identity-based segmentation?

See every asset, observe which assets actually communicate, simulate the policy against that observed traffic, then enforce in stages by device class or site. The VLAN plan stays where it is throughout, which is what keeps change windows small and the work reversible.

Go deeper: the complete guide to microsegmentation.

Sources

Last reviewed: 3 August 2026. Every source below was checked against its primary text on that date.

1. CISA. Zero Trust Maturity Model. Version 2.0, April 2023. Table 4, Networks pillar, Network Segmentation row. https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
2. CISA. The Journey to Zero Trust: Microsegmentation in Zero Trust, Part One: Introduction and Planning. Version 1.0, 29 July 2025. Macrosegmentation and microsegmentation definitions. https://www.cisa.gov/sites/default/files/2025-07/ZT-Microsegmentation-Guidance-Part-One_508c.pdf
3. Office of Management and Budget. Memorandum M-22-09. 26 January 2022. Isolation of environments, quoted verbatim in the CISA guidance at https://www.cisa.gov/sites/default/files/2025-07/ZT-Microsegmentation-Guidance-Part-One_508c.pdf
4. NIST. Special Publication 800-207, Zero Trust Architecture. August 2020. Section 1 and Section 2.1, Tenet 2. https://doi.org/10.6028/NIST.SP.800-207
5. NIST. Special Publication 1800-35, Implementing a Zero Trust Architecture: High-Level Document. June 2025, final. Sections 8.3 and 8.4. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf
6. NIST. Special Publication 800-82r3, Guide to Operational Technology (OT) Security. September 2023. Appendix E.1.3 and Section 6.2.1.3. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
7. HomChaudhuri, S., and Foschiano, M. RFC 5517, Cisco Systems’ Private VLANs: Scalable Security in a Multi-Client Environment. Informational, Independent Submission, February 2010. Sections 1, 1.1, 1.2, 2, 3 and 5. https://www.rfc-editor.org/rfc/rfc5517.txt
8. Juniper Networks. Junos OS documentation, Understanding Private VLANs. Current edition. Private VLAN semantics. https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/private-vlans-qfx-series.html
9. DISA. Cisco IOS Switch L2S Security Technical Implementation Guide. V3R1, 24 July 2024. Rules CISC-L2-000200, CISC-L2-000250, CISC-L2-000260 and CISC-L2-000270. https://public.cyber.mil/stigs/downloads/
10. IEEE. IEEE Std 802.1Q-2022. Published abstract. https://standards.ieee.org/ieee/802.1Q/10323/
11. IEEE. IEEE Std 802.1X-2020. Published abstract. https://standards.ieee.org/
12. PCI Security Standards Council. PCI DSS. v4.0.1, June 2024. Page 12, Segmentation: “Without adequate segmentation (sometimes called a ‘flat network’), the entire network is in scope for the PCI DSS assessment.” https://www.pcisecuritystandards.org/document_library/
13. U.S. Department of Health and Human Services. Healthcare and Public Health Sector-Specific Cybersecurity Performance Goals. No revision date printed. Enhanced Goal 6.M.B, Network Segmentation. https://hhscyber.hhs.gov/Documents/cybersecurity-performance-goals.pdf
14. IEEE. IEEE Std 802.1Q-1998. Published abstract. Reference only. https://standards.ieee.org/
15. IEEE. IEEE Std 802.1Q-2005. Published abstract. Reference only. https://standards.ieee.org/
16. PCI Security Standards Council. Guidance for PCI DSS Scoping and Segmentation. Current edition. Whole document. Reference only. https://listings.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

This page covers zero trust segmentation compared with VLANs: what a VLAN decides, what a policy layer decides, and what changes when you add one. For the broader category comparison, see /microsegmentation/vs-network-segmentation.