Network Segmentation Against Ransomware: 13 Steps [2026]

The advisory arrived from CISA on August 12, 2026, and it read like most of the ones before it: patch known exploited vulnerabilities, keep offline immutable backups, and segment the network so a single infected laptop can’t become a company-wide outage. That last instruction is the one most organizations still skip. The NIST Zero Trust Architecture standard has recommended it since 2020, yet a majority of ransomware post-mortems this year still describe attackers moving from one compromised endpoint to a domain controller in under four hours, mostly because nothing in the network stopped them. INC Ransomware spent much of July and August 2026 proving the point, chaining CVE-2026-15409 and CVE-2026-15410 in SonicWall SMA 1000 VPN appliances to land inside flat, unsegmented corporate networks and encrypt everything reachable from the entry point.

This tutorial walks through building real network segmentation, from asset inventory to VLAN design to firewall policy to a tested, documented, working reference architecture, using tools you likely already own: your existing switches, a firewall (this guide uses pfSense/OPNsense-style syntax but the logic ports to any platform), and free or open-source scanning and monitoring tools. It is written for a small-to-midsize IT or security team defending a network of roughly 50 to 500 devices, though the same principles scale up or down. Expect around 100 minutes to work through the 13 core steps, plus additional time to test against your specific environment and to roll changes out in a maintenance window rather than all at once.

Why Network Segmentation Is the Control Everyone Is Rushing to Implement

Ransomware groups active in 2026 don’t need a zero-day to devastate a target once they’re inside. They need one unsegmented network. CISA’s #StopRansomware advisory on Gunra Ransomware, published in the same window as the SonicWall exploitation wave, instructs organizations to “prioritize patching known exploited vulnerabilities in internet-facing systems,” specifically VPN gateways and RDP-exposed infrastructure, while also calling out immutable offline backups and network segmentation to restrict lateral movement as the two controls that most consistently blunt an active intrusion. The reasoning is simple: patching stops the initial break-in, but segmentation is what determines whether that break-in stays contained to one workstation or spreads to your file servers, your backup repository, and your domain controllers.

The current threat landscape makes that distinction concrete. CVE-2026-18577, an authentication bypass in the N-central remote management platform used heavily by managed service providers, was added to CISA’s Known Exploited Vulnerabilities catalog after attackers used it for account takeover, then pivoted onto whatever networks MSP credentials could reach. CVE-2026-68820, a Windows Ancillary Function Driver flaw exploited as a zero-day by the Lazarus group against defense contractors, gives a local attacker SYSTEM privileges once they’ve already landed on a machine, which only matters if the machine they land on can reach something worth escalating toward. In a flat network, every one of these footholds is a company-wide incident. In a segmented one, it’s an incident response ticket for a single subnet.

“Segment networks to restrict lateral movement from initial infected devices and other devices in the same organization,” is how CISA’s #StopRansomware Guide puts the recommendation, and it has stayed essentially unchanged across multiple ransomware advisories because the underlying attack pattern hasn’t changed either: initial access, discovery, lateral movement, then encryption or exfiltration. Segmentation attacks the middle two stages directly. WEI, an IT consulting and cybersecurity firm, frames the same idea from the containment side: “As an additional prevention, every enterprise [should] consider how to contain, rather than just prevent, a ransomware breach with network segmentation in addition to other strategies.” The shift in framing matters. Segmentation isn’t a prevention control competing with your firewall and EDR agent for budget; it’s a damage-limitation control that assumes something else will eventually fail.

If your organization has already worked through general ransomware protection measures or built out a formal incident response plan, segmentation is the piece that determines how much of that plan you actually need to execute during a real event. A well-segmented network turns “the entire company is down” into “the marketing VLAN is isolated while we investigate,” and that difference is worth the implementation effort covered in the rest of this guide.

What Network Segmentation Actually Means (and What It Doesn’t)

Network segmentation is the practice of dividing a network into smaller, isolated zones and controlling exactly what traffic can cross between them, rather than allowing every device to reach every other device by default. WEI describes the underlying logic well: “Since departments and teams have different access needs, an enterprise should divide a network into segments and then control each segment’s communication to the outside world.” The finance team’s workstations don’t need to talk directly to the manufacturing floor’s industrial control systems. The guest Wi-Fi network doesn’t need a route to your backup server. A compromised print server doesn’t need the ability to open an SMB connection to your domain controller. Segmentation makes each of those statements a technical enforcement rule instead of a policy document nobody reads.

It’s worth being precise about terminology, because the industry uses several overlapping terms. Traditional network segmentation typically means VLANs and subnets separated by firewall or router ACLs, enforced at Layer 3, and it’s the foundation this tutorial builds. Microsegmentation goes finer-grained, applying policy down to the individual workload or even process level, commonly through host-based firewalls, software-defined networking, or a service mesh, and it’s the natural next step once your VLAN-level segmentation is solid. Zero Trust Network Access (ZTNA) is a related but distinct concept: instead of trusting anything inside a perimeter, it verifies identity and device posture for every connection regardless of network location. The three work together. Segmentation limits blast radius by network zone; microsegmentation limits it by workload; Zero Trust removes the assumption that being “inside” the network means anything at all. This tutorial focuses primarily on segmentation and microsegmentation, since that’s where most organizations get the fastest ransomware-containment return for the engineering effort involved.

Segmentation is also not the same as subnetting. You can carve a network into a dozen subnets on paper and still route freely between all of them with no firewall in the path, which delivers zero security benefit, just IP address organization. The security value comes entirely from the enforcement layer: the firewall rules, ACLs, or NAC policies that decide what’s allowed to cross a segment boundary and what gets dropped and logged.

Prerequisites: Tools, Access, and Versions You’ll Need

Before starting, confirm you have the following in place. None of it requires an enterprise SDN platform, though this guide notes where one accelerates the process at scale.

Administrative access to your core and access-layer switches (this guide uses Cisco IOS-style syntax as the reference; the same VLAN and trunk concepts apply to Aruba, Juniper, Ubiquiti, and MikroTik with different command syntax)
A stateful firewall capable of inter-VLAN filtering; examples used here are pfSense 2.8.x or OPNsense 25.x, both free and open source, though any enterprise firewall (Fortinet FortiGate, Palo Alto, Cisco Firepower) works with the same rule logic
Nmap 7.9x or later for pre- and post-segmentation lateral-movement testing
A current, accurate asset inventory, even a spreadsheet; you cannot segment what you haven’t mapped
A network diagramming tool (draw.io / diagrams.net is free and sufficient) to document zones before you touch a single switch port
Off-hours maintenance windows, since VLAN and ACL changes on a live network can cause brief connectivity drops if misconfigured
A NAC or 802.1X-capable solution if you plan to enforce device-level authentication (this guide covers a lightweight setup using open-source FreeRADIUS, but Cisco ISE, Aruba ClearPass, or Portnox are common commercial options)
Roughly 100 minutes to work through the core design and configuration steps below, plus a separate rollout window measured in days, not hours, for anything beyond a small office network

If your organization runs Kubernetes workloads alongside traditional infrastructure, pair this guide with a dedicated look at Kubernetes security hardening, since container network policies are a separate (and equally necessary) segmentation layer that this tutorial doesn’t cover in depth.

Step 1: Inventory Every Asset and Map Data Flows

Segmentation projects fail most often not because the firewall rules are wrong, but because nobody built an accurate map first. Start by inventorying every device with an IP address: servers, workstations, printers, IoT and building-management devices, VoIP phones, industrial control systems, and anything on your guest network. For each asset, record its function, its owner, what it needs to talk to, and how sensitive the data it touches is.

A quick Nmap sweep of your existing flat network gives you a starting inventory and, just as importantly, shows you what’s currently reachable that shouldn’t be. Run this from a workstation on your main network before making any changes, so you have a documented “before” state to compare against later.

# Discover live hosts and open services across your current flat network
nmap -sn 10.0.0.0/16 -oN pre-segmentation-hosts.txt

# Deeper service scan on discovered hosts to understand what's exposed
nmap -sV -O --top-ports 200 -iL live-hosts.txt -oN pre-segmentation-services.txt

# Specifically check whether workstations can reach domain controllers and backup servers
nmap -p 445,3389,88,389,636 10.0.5.0/24 -oN dc-reachability-check.txt

Expect this scan to be uncomfortable reading the first time you run it on a genuinely flat network. It’s common to find that every workstation can reach SMB (port 445) and RDP (port 3389) on every server, including domain controllers and backup targets, which is precisely the reachability that lets ransomware jump from patient zero to the entire environment in one automated sweep. Save this output; you’ll re-run the same scans after segmentation to confirm the reachability is gone.

Step 2: Classify Assets Into Trust Zones

With your inventory in hand, group assets into trust zones based on function and sensitivity rather than physical location. A typical mid-size organization ends up with somewhere between six and twelve zones. Fewer than that and you likely haven’t separated anything meaningful; more than that and the policy becomes unmanageable for a small team.

Zone	Example Assets	Trust Level	Typical Inbound Access
Management/OOB	Switch/firewall admin interfaces, IPMI, KVM	Highest	Admin workstations only, via jump host
Servers/Data Center	Domain controllers, file servers, databases	High	Application tier and specific admin accounts only
Backup Infrastructure	Backup repository, immutable storage target	High (isolated)	Backup agent traffic only, one-way where possible
Corporate Workstations	Employee laptops and desktops	Medium	Outbound to app tier; no direct server-to-server style access
VoIP/Print	IP phones, network printers, scanners	Medium-Low	Isolated from data zones, internet for updates only
IoT/Building Systems	Cameras, badge readers, HVAC controllers	Low	Fully isolated, no internet unless required, no lateral access
Guest/BYOD	Visitor devices, personal phones	Untrusted	Internet-only, zero access to internal zones
DMZ	Public-facing web servers, VPN gateway	Semi-trusted	Internet inbound on specific ports; no direct internal routes

The backup infrastructure zone deserves particular attention given the current threat data. Ransomware operators in 2026 routinely target backup repositories first, specifically to remove the victim’s ability to recover without paying. CISA’s Gunra guidance explicitly recommends immutable, offline backups isolated from the production network for exactly this reason. If your backup server is reachable from the same VLAN as general-purpose workstations, an attacker with domain admin credentials (which lateral movement from a single endpoint frequently yields within hours) can delete or encrypt your recovery point before you ever notice the intrusion.

Step 3: Design Your VLAN and Subnet Architecture

Translate your trust zones into a concrete VLAN and IP addressing scheme. Use a consistent, documented numbering convention so anyone on the team can look at a VLAN ID or subnet and immediately know its purpose. A common pattern uses the third octet of a /24 to encode the VLAN ID, which keeps troubleshooting fast even for engineers unfamiliar with the specific deployment.

VLAN ID	Name	Subnet	Gateway
10	MGMT	10.0.10.0/24	10.0.10.1
20	SERVERS	10.0.20.0/24	10.0.20.1
25	BACKUP	10.0.25.0/28	10.0.25.1
30	CORP-WORKSTATIONS	10.0.30.0/23	10.0.30.1
40	VOIP-PRINT	10.0.40.0/24	10.0.40.1
50	IOT-BUILDING	10.0.50.0/24	10.0.50.1
60	GUEST	10.0.60.0/23	10.0.60.1
90	DMZ	10.0.90.0/28	10.0.90.1

Deliberately undersize the backup VLAN (a /28 gives 14 usable addresses) as a soft control: it forces a conversation before anyone adds an unplanned device to a network segment that should only ever contain backup infrastructure. The same applies to the DMZ, which should hold only what’s genuinely internet-facing.

Step 4: Configure VLANs on Your Switches

With the design documented, create the VLANs on your core switch and configure access ports for end devices and trunk ports between switches and to your firewall. The example below uses Cisco IOS syntax; the underlying concept, tagging traffic by VLAN and restricting each port to the VLANs it should carry, applies regardless of vendor.

! Create VLANs on the core switch
vlan 10
 name MGMT
vlan 20
 name SERVERS
vlan 25
 name BACKUP
vlan 30
 name CORP-WORKSTATIONS
vlan 40
 name VOIP-PRINT
vlan 50
 name IOT-BUILDING
vlan 60
 name GUEST
vlan 90
 name DMZ
exit

! Configure an access port for a workstation
interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 30
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 spanning-tree portfast
 spanning-tree bpduguard enable

! Configure the trunk to the firewall carrying all VLANs
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,25,30,40,50,60,90
 switchport trunk native vlan 999
 description TRUNK-TO-FIREWALL

Two details in that configuration matter more than they look. First, the native VLAN is set to an unused ID (999) rather than left as the default VLAN 1, which closes off a well-known VLAN-hopping technique that relies on double-tagging through the default native VLAN. Second, port security with a MAC address limit and BPDU guard on access ports prevents someone from plugging an unauthorized switch into an office port and quietly extending your trusted VLAN into a conference room or a visitor’s laptop bag.

Step 5: Build Firewall Rules Between Segments

VLANs alone only separate broadcast domains; they don’t stop routed traffic from crossing between segments unless a firewall enforces that boundary. This is the step that turns organizational structure into an actual security control. The default policy for every segment boundary should be deny, with specific allow rules added only for traffic that has a documented business reason to cross.

# pfSense/OPNsense-style firewall rules (interface: CORP-WORKSTATIONS)
# Rule order matters: most specific allow rules first, explicit deny-log last

# Allow workstations to reach the application tier on required ports only
pass in on CORP_WORKSTATIONS proto tcp from 10.0.30.0/23 to 10.0.20.0/24 port {443,8443} 
    label "workstations-to-app-tier-https"

# Allow workstations to resolve DNS from internal resolvers only
pass in on CORP_WORKSTATIONS proto udp from 10.0.30.0/23 to 10.0.20.5 port 53 
    label "workstations-dns"

# Explicitly block workstations from ever reaching the backup VLAN
block in log on CORP_WORKSTATIONS from 10.0.30.0/23 to 10.0.25.0/28 
    label "DENY-workstations-to-backup"

# Explicitly block workstations from initiating SMB/RDP to domain controllers directly
block in log on CORP_WORKSTATIONS proto tcp from 10.0.30.0/23 to 10.0.20.0/24 port {445,3389} 
    label "DENY-workstation-lateral-smb-rdp"

# Default deny with logging for anything not explicitly permitted above
block in log on CORP_WORKSTATIONS all label "DEFAULT-DENY-CORP-WORKSTATIONS"

Notice the SMB and RDP block rule specifically. Those two ports are the single most common lateral-movement path in ransomware incidents, since Windows environments rely on them heavily for legitimate administration, which is exactly what attackers abuse. Blocking workstation-to-server SMB and RDP by default, and only permitting it from a dedicated admin jump host (covered in Step 8), closes the path that let the CVE-2026-68820 Lazarus intrusion escalate on machines it had already landed on. Log every deny rule; those logs become your lateral-movement detection signal in Step 11.

Step 6: Implement Microsegmentation for Critical Servers

VLAN-level segmentation stops a compromised workstation from reaching your backup server directly, but it doesn’t stop lateral movement between two servers that happen to sit in the same SERVERS VLAN. Microsegmentation closes that gap by applying host-based firewall rules on the servers themselves, so a compromised web application server can’t pivot to your database server even though both live on 10.0.20.0/24.

# Linux host-based firewall (nftables) on a database server
# Only accept connections from the specific application server IPs on the DB port

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr 10.0.20.11 tcp dport 5432 accept comment "app-server-1 to postgres"
    ip saddr 10.0.20.12 tcp dport 5432 accept comment "app-server-2 to postgres"
    ip saddr 10.0.10.0/24 tcp dport 22 accept comment "mgmt-vlan-ssh-jumphost-only"
    ip protocol icmp accept
    counter log prefix "nft-drop: " drop
  }
}

This is also the layer where Windows Defender Firewall with Advanced Security or a commercial microsegmentation product (Illumio, Guardicore/Akamai, VMware NSX) pays for itself at scale, since managing per-host nftables or iptables rules by hand becomes unwieldy past a few dozen servers. For a small environment, hand-written host firewall rules on your dozen or so most critical servers, domain controllers, backup targets, and databases, deliver most of the security benefit without the licensing cost.

Step 7: Segment and Isolate Your Backup Infrastructure

Given how consistently ransomware operators target backups first, this segment deserves its own hardened configuration rather than sitting inside a general SERVERS VLAN. Configure the backup infrastructure so that traffic can only flow one direction wherever your backup software supports it: backup agents push data to the repository, but the repository itself has no route back out to production except for the specific management connection your backup admin uses.

Place the backup repository on its own dedicated VLAN (VLAN 25 in the design above), not shared with any other server role
Restrict inbound access to backup agent traffic on the specific ports your backup software requires, from production server IPs only, never from the general workstation VLAN
Configure the backup target as immutable or air-gapped wherever your platform supports it (S3 Object Lock, tape rotated offline, or a dedicated backup appliance with its own hardened OS), so that even a domain admin account compromised in production cannot delete existing recovery points
Disable or tightly restrict any management interface on the backup appliance that’s reachable from anywhere other than the dedicated admin jump host
Test restoration quarterly from the isolated segment to confirm the isolation itself hasn’t broken your recovery process

Step 8: Set Up a Jump Host for Administrative Access

Every SMB and RDP block rule from Step 5 needs a documented exception path for legitimate administration, and that path should be a single, tightly monitored jump host (sometimes called a bastion host) rather than a blanket exception for the IT team’s regular workstations. Place the jump host in the management VLAN, require multi-factor authentication to reach it, and log every session.

# Firewall rule permitting RDP/SMB only from the jump host, to servers
pass in on MGMT proto tcp from 10.0.10.5 to 10.0.20.0/24 port {445,3389,22} 
    label "jumphost-to-servers-admin-only"

# Everything else attempting RDP/SMB to servers is denied by the Step 5 default-deny rule

This single change closes the exact gap that turns “one compromised laptop” into “domain-wide ransomware event” in most 2026 incident write-ups: an admin’s day-to-day workstation, which is just as exposed to phishing as anyone else’s, no longer has a standing path to open an RDP session against a domain controller. If that admin’s laptop gets compromised, the attacker still has to separately compromise the jump host, which is a much smaller, much more heavily monitored attack surface.

Step 9: Deploy Network Access Control and Zero Trust Policies

VLANs and firewall rules control traffic between segments, but Network Access Control (NAC) decides whether a device gets onto a segment in the first place. Without it, anyone with a network cable can plug into an office port and land wherever that port’s static VLAN assignment puts them. 802.1X authentication ties port access to device or user identity instead, and it’s the piece that makes segmentation resilient to physical access, not just logical topology.

# FreeRADIUS clients.conf entry for switch-based 802.1X authentication
client switch-core-01 {
    ipaddr = 10.0.10.2
    secret = REPLACE_WITH_STRONG_SHARED_SECRET
    shortname = core-switch-01
}

# Example dynamic VLAN assignment returned to the switch after successful auth
# (in FreeRADIUS users file or an equivalent policy engine)
DEFAULT Auth-Type := EAP
    Tunnel-Type = VLAN,
    Tunnel-Medium-Type = IEEE-802,
    Tunnel-Private-Group-Id = "30"

This is also where the Zero Trust principle from Microsoft’s Zero Trust network deployment guidance and the NIST SP 800-207 Zero Trust Architecture standard becomes practical rather than theoretical: instead of trusting a device because it’s plugged into a particular port, the network verifies identity and posture, unpatched, unmanaged, or unrecognized devices land in a quarantine VLAN with internet-only access until remediated. Organizations without budget for a full commercial NAC platform can get meaningful coverage from FreeRADIUS paired with switch-native 802.1X support, which is included in virtually every managed switch shipped since the mid-2010s.

Step 10: Test Segmentation With Lateral Movement Simulation

Configuration you haven’t tested is a belief, not a control. Re-run the same Nmap scans from Step 1, this time from a workstation on the CORP-WORKSTATIONS VLAN, and confirm the reachability that existed before segmentation is now gone.

# Re-run from a workstation on VLAN 30 after segmentation is live
nmap -p 445,3389,88,389,636 10.0.20.0/24 -oN post-segmentation-dc-check.txt
nmap -p 445,3389 10.0.25.0/28 -oN post-segmentation-backup-check.txt

# Expect: filtered/closed on 445 and 3389 to domain controllers and backup
# Compare directly against pre-segmentation-services.txt from Step 1

A clean result shows those ports as filtered or closed from the workstation VLAN, while the same scan run from the jump host in the MGMT VLAN should still show them open, confirming the exception path from Step 8 works as intended. If you have the internal expertise or budget, follow this up with a proper penetration test or a purple-team exercise that specifically attempts lateral movement techniques mapped to MITRE ATT&CK’s Lateral Movement tactic (TA0008), since automated port scans catch misconfigured ACLs but won’t catch every creative pivot path a determined attacker might find.

Step 11: Monitor and Alert on Cross-Segment Traffic

Segmentation without monitoring tells you what should happen; it doesn’t tell you when something is trying to happen anyway. Every deny-and-log rule written in Steps 5 through 8 needs to feed somewhere a human or an automated system actually looks. At minimum, forward firewall deny logs to a central log destination and alert on specific high-signal patterns.

# Example Sigma-style detection rule: workstation attempting SMB/RDP to servers
title: Denied Lateral Movement Attempt - Workstation to Server VLAN
status: stable
logsource:
  product: firewall
  category: firewall
detection:
  selection:
    action: deny
    src_zone: CORP-WORKSTATIONS
    dst_zone: SERVERS
    dst_port:
      - 445
      - 3389
  condition: selection
level: high
tags:
  - attack.lateral_movement
  - attack.t1021

A single denied connection attempt might be a misconfigured legacy application; a burst of denied SMB/RDP attempts from one workstation to multiple servers in a short window is a strong lateral-movement signal worth an automatic page, not a next-morning review. If your team already runs a SIEM, most platforms (Wazuh, Splunk, Microsoft Sentinel) accept Sigma-format rules natively or with a lightweight converter.

Step 12: Document the Policy and Assign Ownership

A segmentation architecture that lives only in switch configs and firewall rule tables decays within months as new servers, new vendors, and new “just this once” exceptions get added without anyone updating the design doc. Maintain a living document that pairs the zone table from Step 2 and the VLAN table from Step 3 with an explicit change-control process: any new cross-segment rule requires a documented business justification, an expiration or review date, and a named owner.

Store the network diagram, VLAN table, and firewall rule rationale in your team’s wiki or a version-controlled repository, not only in the device configs themselves
Require a ticket and a named approver for any firewall rule that opens a new cross-segment path
Review all firewall rules quarterly and remove anything without a current, valid business justification
Assign a segmentation owner, distinct from whoever owns the firewall itself, whose job includes catching architecture drift, not just keeping the box online

Step 13: Validate Against a Ransomware Tabletop Scenario

The final step ties the technical work back to the incident response process. Run a tabletop exercise that starts from a specific, current, realistic entry point, for example, a phishing email leading to a compromised workstation, or an exploited VPN appliance similar to the SonicWall SMA CVE-2026-15409/15410 chain, and walk through what an attacker can and can’t reach given your new segmentation. Ask the team to narrate each pivot attempt and check it against the firewall rules and logs from Steps 5 through 11.

This exercise routinely surfaces gaps that pure configuration review misses: a vendor VPN that bypasses the segment boundary, a service account with broader access than any single firewall rule reveals, or a legacy application that quietly needs a cross-segment path nobody documented. Treat each finding as a Step 12 change-control item rather than an emergency rule addition, unless it represents active risk that needs immediate closure.

Common Pitfalls When Segmenting a Network

Most segmentation projects don’t fail because the concept is misunderstood; they fail on a handful of predictable execution mistakes.

Segmenting by department instead of by trust level. A “Finance VLAN” and a “Marketing VLAN” sound organized but usually contain devices with wildly different sensitivity, and attackers don’t care about your org chart. Segment by what a device can do and what it can access, not by which team uses it.
Leaving a default-allow rule at the bottom of the ACL. A single forgotten “allow any any” catch-all rule, often left over from initial testing, silently undoes every specific deny rule above it. Always end with an explicit, logged default deny and audit for stray permissive rules regularly.
Forgetting east-west traffic within the same VLAN. VLAN-level segmentation does nothing to stop two compromised hosts on the same subnet from talking directly to each other. This is exactly the gap Step 6’s microsegmentation closes, and it’s the step teams skip most often because it takes more per-host effort.
Not testing the jump host exception path before rolling out the block rules. Teams that deploy Step 5’s SMB/RDP block rules without first confirming Step 8’s jump host works correctly lock their own admins out of production servers, usually during a maintenance window with no easy rollback plan.
Treating segmentation as a one-time project. New servers, new SaaS integrations, and new vendor VPNs get added constantly, and each one is a potential unplanned cross-segment path if it isn’t run through the change-control process from Step 12.
Ignoring legacy protocols that don’t route cleanly. Some older applications and industrial control systems rely on broadcast traffic or protocols that break when forced across a routed segment boundary. Identify these during the inventory phase (Step 1), not after a production outage.

Troubleshooting Guide

Segmentation changes touch live infrastructure, and the following issues account for most of the support tickets that follow a rollout.

Workstations can’t reach the internet after VLAN reassignment. Confirm the new VLAN’s DHCP scope is configured and that the access port’s switchport access vlan matches the intended VLAN ID; a typo here is the single most common post-migration issue.
An application breaks after segmentation with no obvious firewall block in the logs. Check for a missing DNS rule first; many outages that look like a general connectivity failure are actually the application server unable to resolve a hostname because the DNS allow rule from Step 5 wasn’t broad enough for its specific resolver.
Printers stop appearing on workstations. Print traffic (typically ports 9100, 631, and mDNS/Bonjour on 5353) needs an explicit allow rule between the workstation and print VLANs if you’ve segmented them separately; add a narrow rule rather than merging the VLANs back together.
VoIP calls have audio issues or fail to connect after segmentation. SIP and RTP traffic often needs a wider UDP port range permitted between the VoIP VLAN and your PBX or SIP trunk provider; consult your phone system vendor’s documented port requirements rather than guessing.
The jump host itself becomes a bottleneck during incident response. If only one admin can be on the jump host at a time, incidents that need multiple hands stall. Configure the jump host to support multiple concurrent, individually logged sessions rather than a single shared login.
802.1X authentication fails intermittently, dropping devices off the network. This is frequently a RADIUS shared-secret mismatch or a certificate expiration on the switch or the client; check FreeRADIUS logs (radiusd -X for verbose debug output) before assuming it’s a switch hardware issue.
Firewall logs show a flood of denied traffic you didn’t expect. This is often legitimate but previously undocumented traffic, such as a monitoring agent or backup software checking in more broadly than the architecture assumed. Investigate before either permitting it broadly or ignoring the alerts, since alert fatigue from unresolved noisy denies is how real lateral-movement attempts get missed.
Legacy industrial or OT equipment stops functioning after being placed in an isolated VLAN. Some OT protocols (Modbus, BACnet) don’t route well across Layer 3 boundaries without a protocol-aware gateway. Consult the equipment vendor and consider a dedicated OT segmentation approach rather than treating it identically to IT assets.
Guest Wi-Fi users report they can’t access anything, including the internet. Verify the guest VLAN’s firewall rule permits outbound internet (typically 80/443) while blocking everything internal; a default-deny-all rule applied too broadly blocks legitimate guest internet access along with the internal access you intended to remove.

Advanced Tips: Scaling Segmentation With SDN and Automation

Once the manual VLAN and firewall-rule approach above is working reliably, several avenues make segmentation easier to maintain at scale. Software-defined networking (SDN) platforms decouple policy from physical topology, letting you define “workstations can reach the app tier on 443” as a policy object that gets enforced consistently regardless of which physical switch or cloud region a workload lands on, which matters increasingly as environments span on-premises and cloud infrastructure simultaneously.

Infrastructure-as-code tooling (Terraform providers exist for most major firewall and switch platforms) turns your VLAN and ACL configuration into version-controlled files, which makes the Step 12 change-control process enforceable through pull requests and code review rather than relying entirely on documentation discipline. For organizations running substantial cloud infrastructure alongside on-premises networks, cloud-native security groups and network ACLs (AWS Security Groups, Azure NSGs, GCP firewall rules) implement the same segmentation logic in their respective environments and should follow the identical default-deny, explicit-allow pattern used throughout this guide.

Finally, map your segmentation architecture explicitly against the CIS Critical Security Controls, specifically Control 12 (Network Infrastructure Management) and Control 13 (Network Monitoring and Defense), and the NIST Cybersecurity Framework’s Protect function. Doing so gives you a ready-made audit trail if your organization needs to demonstrate segmentation maturity for cyber insurance underwriting, which increasingly asks specific questions about network segmentation and backup isolation before issuing or renewing a ransomware coverage policy.

Complete Working Project: A Small Business Reference Architecture

Bringing every step together, here’s what a complete, working segmented network looks like for a roughly 150-device small business, combining the VLAN design, firewall policy, jump host, and monitoring covered above into a single reference you can adapt directly.

# reference-architecture.yaml — small business segmentation summary
site: example-hq
core_firewall: OPNsense 25.x
core_switch: managed L3 switch with 802.1X support

vlans:
  - {id: 10, name: MGMT,      subnet: 10.0.10.0/24, internet: jump-host-only}
  - {id: 20, name: SERVERS,   subnet: 10.0.20.0/24, internet: outbound-updates-only}
  - {id: 25, name: BACKUP,    subnet: 10.0.25.0/28, internet: none}
  - {id: 30, name: CORP,      subnet: 10.0.30.0/23, internet: full-with-proxy}
  - {id: 40, name: VOIP,      subnet: 10.0.40.0/24, internet: sip-trunk-only}
  - {id: 50, name: IOT,       subnet: 10.0.50.0/24, internet: vendor-firmware-only}
  - {id: 60, name: GUEST,     subnet: 10.0.60.0/23, internet: full}
  - {id: 90, name: DMZ,       subnet: 10.0.90.0/28, internet: inbound-443-only}

default_policy: deny
logging: all-denies-to-siem
nac: freeradius-8021x
backup_immutability: s3-object-lock
jump_host: 10.0.10.5
monitoring: sigma-rules-to-wazuh

validated:
  - nmap-post-segmentation-scan: pass
  - tabletop-exercise: quarterly
  - firewall-rule-review: quarterly
  - backup-restore-test: quarterly

This reference maps directly to every step above: the VLAN table from Step 3, the firewall default-deny posture from Step 5, the isolated backup zone from Step 7, the jump host from Step 8, NAC from Step 9, and the ongoing validation cadence from Steps 10 through 13. Treat it as a starting template, not a fixed prescription; your specific asset inventory from Step 1 should drive the final zone count and boundaries, not the other way around.

How This Maps to Current Ransomware Advisories

The architecture above isn’t theoretical hardening; it’s a direct response to how 2026’s active ransomware campaigns actually operate. The table below connects specific recent threats to the segmentation control in this guide that would have interrupted them.

Threat / CVE	Attack Pattern	Segmentation Control That Helps
CVE-2026-15409/15410 (SonicWall SMA, exploited by INC Ransomware)	VPN appliance compromise, then flat-network lateral movement	DMZ isolation (Step 3) + default-deny between VPN segment and internal VLANs (Step 5)
CVE-2026-18577 (N-central RMM auth bypass)	Account takeover on remote management tooling used to pivot into client networks	Jump host with MFA (Step 8) instead of standing RMM access to production
CVE-2026-68820 (Windows AFD, exploited by Lazarus)	Local privilege escalation to SYSTEM after initial endpoint compromise	SMB/RDP block from workstation VLAN to servers (Step 5) limits what SYSTEM access is worth
CISA #StopRansomware Gunra advisory	General ransomware playbook: initial access, discovery, lateral movement, encryption	Full architecture (Steps 1-13), especially immutable backup isolation (Step 7)

Frequently Asked Questions

How long does it take to segment an existing flat network?

For a small business network of 100-200 devices, the design and initial VLAN/firewall configuration covered in this tutorial takes roughly 100 minutes of focused work, but the full rollout, including testing, staged migration, and validation, typically spans one to three weeks to avoid disrupting production during business hours. Larger enterprise environments with thousands of devices and multiple sites should plan for a phased rollout measured in months.

Is network segmentation the same as subnetting?

No. Subnetting is just IP address organization; segmentation requires an enforcement layer, typically a firewall or ACL, that actually restricts what traffic can cross between subnets. You can have a dozen subnets and zero segmentation if nothing enforces boundaries between them.

Do I need expensive commercial NAC or SDN products to segment my network?

No. This tutorial uses free or open-source tools throughout, including pfSense or OPNsense for firewalling, FreeRADIUS for 802.1X NAC, Nmap for validation, and nftables for host-based microsegmentation. Commercial platforms (Cisco ISE, Illumio, VMware NSX) add centralized management and easier scaling for large environments, but a small-to-midsize network can achieve strong segmentation with vendor switch hardware most teams already own.

What’s the difference between segmentation and microsegmentation?

Segmentation typically operates at the VLAN or subnet level, controlling traffic between broader zones. Microsegmentation goes finer-grained, applying policy down to individual workloads or hosts, which stops lateral movement between two devices on the same VLAN. Most mature architectures use both: VLAN segmentation for broad zone separation, microsegmentation for critical servers within those zones.

Will segmentation stop ransomware entirely?

No single control stops ransomware entirely, and segmentation isn’t a substitute for patching, endpoint detection, or backups. What it reliably does is limit blast radius: instead of one compromised workstation leading to a company-wide encryption event, a well-segmented network confines the damage to the segment the attacker initially compromised, buying time for detection and response before the incident spreads further.

How often should firewall rules between segments be reviewed?

Quarterly at minimum, as outlined in Step 12. Rule sets accumulate exceptions over time as new applications and vendors get added, and an unreviewed rule set gradually drifts back toward the flat-network state segmentation was meant to eliminate. Pair the quarterly review with the tabletop validation from Step 13 to catch gaps a pure configuration audit might miss.

Should the backup network really have zero connection to production?

As close to zero as your backup software allows. Given how consistently 2026 ransomware campaigns target backup infrastructure specifically to prevent recovery without payment, the backup segment should only accept the minimum traffic required for backup agents to push data in, with no standing administrative path from the general server or workstation VLANs. Immutable storage (such as S3 Object Lock) adds a further layer that survives even a fully compromised admin account.

Can I segment a network that includes industrial control or OT systems the same way?

The same principles apply, but OT environments often need protocol-aware gateways rather than standard Layer 3 ACLs, since protocols like Modbus and BACnet don’t always route cleanly. Treat OT as its own zone with its own review process, and consult vendor-specific guidance before applying the general VLAN and firewall patterns from this tutorial directly to production industrial equipment.