Skip to content
WorakornKoonawootrittriron
Back to blog
Network security

Five network segmentation myths, checked against CISA and NIST

VLANs alone are not segmentation. Five common myths checked against CISA, NIST and MITRE guidance, plus a default-deny rollout and ways to test it.

Beginner10 min read

On this page
  1. Myth 1: "We have VLANs, so we are segmented"
  2. Myth 2: "Segmentation is only for big companies"
  3. Myth 3: "Our perimeter is strong, so the inside doesn't matter"
  4. Myth 4: "Microsegmentation is a product you buy, and then you're done with the rest"
  5. Myth 5: "Segment once and it stays segmented"
  6. Zones and a default-deny policy between them
  7. How to start: map, group, enforce gradually
  8. Measuring whether it works

Picture an office network where every laptop, printer, file server and database sits in one big network and can talk to every other device. It works, and it is easy to run. It also means that when one laptop is compromised, the attacker's next stop can be anything on that network.

Network segmentation is the fix most security guides point to. It is also a topic with a lot of half-truths around it. This post takes five common myths, checks each one against free public guidance (mostly from CISA, NIST and MITRE), and ends with a practical way to start and a way to tell whether it is working.

First, a definition. CISA describes network segmentation as dividing a network into multiple distinct pieces, called segments, that group related resources, where each segment acts as its own network and segmentation is used to "limit access to devices, data and applications and restrict communications between networks" (CISA, Microsegmentation in Zero Trust, Part One, July 2025, section 2). The important word there is restrict. Segments are only useful because of what is allowed, and not allowed, between them.

One infected host on a flat network reaches every host. With policy walls between zones, the same infection fills its own zone and stops at the wall

Myth 1: "We have VLANs, so we are segmented"

Fact: a VLAN is a container. The segmentation is the policy between containers.

VLANs are a perfectly good building block, and CISA lists them, together with IP address ranges, as the traditional way organisations controlled traffic between zones (CISA, introductory overview). But notice the rest of that sentence: VLANs and "devices or services that can accept or reject the connections based on static rules". NIST describes traditional segmentation the same way: segments are created with network constructs such as VLAN IDs, and firewall rules are then created "to block or allow communication with each group or segment" (NIST SP 800-215, section 5.1.2).

Two everyday situations show why the rules matter more than the VLAN numbers:

  • Routing with no filter. On a layer 3 switch, a VLAN interface (an SVI) connects a VLAN to the switch's routing engine, and you can route between VLANs simply by giving each VLAN an interface with an IP address (Cisco Nexus 9000 interfaces guide). If nobody adds an access list or sends that traffic through a firewall, ten VLANs can still behave like one flat network.
  • Big zones with open insides. Firewalls usually have a default for traffic that stays inside one zone. On Palo Alto Networks firewalls, the predefined default rules allow all intrazone traffic and deny all interzone traffic (Palo Alto Networks, Security Policy Rules). If every user laptop and every server share one zone, the firewall never filters most of the traffic that matters.

What to do instead: for each pair of segments, write down which flows are actually needed, and make sure something enforces that list. A diagram full of VLANs with no rules between them is a map, not a control.

Myth 2: "Segmentation is only for big companies"

Fact: the simplest form of segmentation is already on most small-office routers.

The US Federal Trade Commission's small business guidance says that if you need Wi-Fi for guests, employees' personal devices or the public, you should set up a separate "public" network, and that guest or customer Wi-Fi should be separate from and not connected to your business network (FTC, Cybersecurity for Small Business). That is segmentation: the guest's phone and the accounting PC no longer share a network.

The FTC's general security guide for businesses puts the idea in one line: "Not every computer in your system needs to be able to communicate with every other one", and it suggests housing particularly sensitive data in a separate, secure place on the network (FTC, Start with Security, August 2023).

CISA's microsegmentation guide is written with US federal agencies in mind, but it says plainly that any organisation can apply it (CISA, section 1.1).

What to do instead: start with the separations that cost almost nothing. Guests away from staff. Cameras, printers and other smart devices away from laptops. The machine that holds payroll or customer data in its own spot, reachable only by the people and systems that need it.

Myth 3: "Our perimeter is strong, so the inside doesn't matter"

Fact: attackers plan for life after the perimeter. That stage even has its own name.

MITRE ATT&CK, the public knowledge base of attacker behaviour, has a whole tactic for it: Lateral Movement (TA0008), which "consists of techniques that adversaries use to enter and control remote systems on a network" (MITRE ATT&CK, TA0008). Its techniques include using remote services such as RDP, SMB admin shares, SSH and WinRM (T1021), exploiting remote services (T1210) and moving tools between systems (T1570).

NIST's zero trust document is blunt about the old model: perimeter security "has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered" (NIST SP 800-207, section 1). CISA's ransomware guide makes the same link in practical terms: network segmentation "can help contain the impact of any intrusion" and is there to prevent or limit lateral movement (CISA, #StopRansomware Guide).

MITRE also lists Network Segmentation as a mitigation (M1030). For RDP it suggests blocking the traffic between security zones; for exploited remote services it suggests segmenting so that access to critical systems only happens through controlled methods (MITRE ATT&CK, M1030).

Segmentation does not stop the first infection. It decides how far that infection can go next, and it gives you more places to notice it.

Myth 4: "Microsegmentation is a product you buy, and then you're done with the rest"

Fact: microsegmentation is a design approach, built from several kinds of tools, and it sits on top of your other controls, not instead of them.

CISA calls microsegmentation "a design philosophy focused on minimizing the size of network segments". Its example: a traditional network might put every server in the data centre into one segment, while a microsegmented one lets servers talk only to the servers they need for their business function (CISA, section 2.1). NIST's enterprise network guide gives the purpose in one sentence: to provide "a degree of isolation to prevent attack escalation" (NIST SP 800-215, section 5.1).

How you enforce it varies. CISA's guide groups the options into network-based (routers, SD-WAN, next-generation firewalls), endpoint-based (host firewalls, SASE agents), container, hypervisor and cloud-native controls, and expects most organisations to combine several of them (CISA, table 1). NIST SP 800-207 describes the same two main shapes: gateways such as NGFWs placed in front of each resource or small group of resources, or software agents and firewalls on the hosts themselves (NIST SP 800-207, section 3.1.2).

And it is not a replacement for anything. CISA states that microsegmentation "does not replace defense-in-depth" or the proper management of data, assets, configuration and vulnerabilities (CISA, section 1.1). Patching, MFA and monitoring still matter. Microsegmentation makes each of them easier to aim, because each segment is small enough to reason about.

Where zero trust comes in

Zero trust and microsegmentation are often mentioned in the same breath for a reason. CISA's Zero Trust Maturity Model describes the network segmentation journey in four stages, from "large perimeter/macro-segmentation with minimal restrictions on reachability within network segments" at the traditional end, to "fully distributed ingress/egress micro-perimeters and extensive micro-segmentation based around application profiles" at the optimal end (CISA Zero Trust Maturity Model v2.0, Networks pillar). In the zero trust version, the decision to let a connection through can use more than IP addresses: who the user is, what device they are on, and other context (CISA, section 2.1).

Myth 5: "Segment once and it stays segmented"

Fact: segmentation drifts, so it has to be checked and revisited.

Applications move, new services appear, and somebody adds a "temporary" rule during an outage. CISA's guide says the change to microsegmentation "is not a singular transition", and that organisations should periodically evaluate their segmentation and validate it against the current threat landscape (CISA, section 4.9).

Some standards make this a hard requirement. In PCI DSS v4.x (v4.0.1 was published in June 2024 with no added or deleted requirements, and v4.0 was retired on 31 December 2024, according to the PCI Security Standards Council), if segmentation is used to isolate the cardholder data environment, requirement 11.4.5 calls for penetration tests on the segmentation controls at least once every 12 months and after any change to them, confirming that the controls work and isolate that environment from out-of-scope systems (PCI DSS requirement 11.4.5, as reproduced by Microsoft Learn).

Zones and a default-deny policy between them

With the myths out of the way, the core pattern is simple enough to fit on a sticky note:

  1. Group assets into zones by what they do and how sensitive they are (users, servers, data, guests, management, and so on).
  2. Deny by default between zones.
  3. Allow only the specific flows the business needs, and log them.

The "deny by default" part is old, well-tested advice. NIST's firewall guide defines it as blocking all inbound and outbound traffic that has not been expressly permitted by firewall policy, and explains that it is a more secure approach than permitting everything not explicitly forbidden (NIST SP 800-41 Rev. 1).

Four connections cross the zone firewall: two match an allow rule and pass, two fall through to the default deny and are dropped

A small example of what the allow list between two zones might look like:

From zone To zone Allowed Why
Users Web servers HTTPS (tcp/443) people use the web app
Web servers Database the database port only the app reads and writes data
Users Database nothing nobody needs direct access
Guests anything internal nothing guests only need the internet

Every other combination falls through to the default deny.

How to start: map, group, enforce gradually

The fastest way to make people hate segmentation is to switch on a strict policy on day one and break the payroll system. CISA recommends a phased approach instead, in four steps that you repeat for one candidate at a time (CISA, sections 3 and 4.3):

  1. Identify candidate resources. Pick an application, workflow or environment. Early on, CISA suggests choosing for ease of transition; later, when you have experience, prioritise critical assets.
  2. Identify dependencies. List everything the candidate talks to, and everything that talks to it. For something already running, CISA notes the initial list can come from tracking its actual communications, and that you should check the list is complete.
  3. Determine the policy. Choose rules that let the business function work, with users involved so you understand the impact on their work.
  4. Deploy and validate. Test the policy first, for example "in a permissive mode that flags policy violations to detect potentially missed dependencies", then enforce it with enough visibility to confirm it is working.
Map the flows, run the new policy in log-only mode, then enforce: the unplanned flow is first logged, then blocked

That log-only step is the one I would never skip. CISA also advises planning a way to revert updated policies, and having monitoring and testing in place before the change (CISA, section 4.5). In other words, treat each enforcement step as a change with a rollback plan.

Two groups of devices need extra thought. Laptops that roam between office and home may need agent-based or application-based controls rather than network-only ones. OT, IoT and legacy devices often can't run agents at all, so network-based segmentation and tightly limited access to and from them become more important, not less (CISA, sections 4.6 and 4.7).

Measuring whether it works

"We segmented the network" is a claim. These are ways to test it:

  • Try the paths that should fail. From a host in each zone, attempt connections that your policy says are denied. This is the same idea behind the PCI DSS segmentation tests above. A denied path that succeeds is the most useful finding you can get.
  • Compare reality with the allow list. Review the flows that actually cross each boundary against the table you wrote. Anything not on the list is either a missing rule or a problem.
  • Read the deny logs. Logged denies between zones show either a dependency you missed or something probing where it shouldn't. CISA lists improved visibility as one of the benefits of microsegmentation (CISA, section 1.2), but it only helps if someone looks.
  • Hunt for broad rules. Rules with "any" as source, destination or service between zones quietly undo the design. Review them regularly.
  • Think like ATT&CK. Take the Lateral Movement techniques (RDP, SMB, SSH, WinRM and friends) and ask, for each zone: if one host here were compromised, which of these could reach the next zone?

Segmentation is not glamorous work. It is mostly spreadsheets of flows, careful change windows and reading logs. But it changes the question after an incident from "what did they reach?" to "what did they reach in that one zone?", which is a much better question to have to answer.

Sources

Keep reading

Related posts

Back to blog