Every security framework says the same thing: segment your network. Put the servers, the workstations, the IoT, the guest Wi-Fi, and the industrial gear on separate VLANs with firewall rules between them, so a compromise in one zone doesn't become a compromise of everything. It's good advice. It's in every checklist for a reason.

It's also advice written for a greenfield, and most networks are not green. They're a flat /16 that grew organically over fifteen years, running on switches whose configs nobody fully understands, where the last person who touched the VLAN layout left in 2019. On that network, "just segment it" is not a checklist item. It's a project with real risk, and the honest answer to whether you should do it is: it depends — and the tradeoff deserves to be looked at squarely instead of assumed away.

Why segmentation is right in principle

The case for segmentation is genuinely strong and worth stating plainly, because the "it depends" is not an excuse to do nothing:

  • Blast-radius containment. A flat network means any compromised device can reach every other device. Ransomware on one workstation can scan and spread to servers, backups, and everything else in one hop. Segmentation forces an attacker to cross controlled boundaries, each one a chance to detect and stop them.
  • IoT and OT isolation. The security camera, the badge reader, the HVAC controller, the manufacturing gear — these are often unpatchable, long-lived, and trivially compromised. On a flat network they're a direct bridge to everything. Isolated, they can only hurt their own segment.
  • Blast-radius for mistakes, not just attacks. A broadcast storm, a misconfigured device, a rogue DHCP server — segmentation contains operational accidents too, not only malicious ones.

None of this is in dispute. A well-segmented network is more defensible than a flat one. The question is never whether segmentation is good. It's whether retrofitting it onto this infrastructure, right now, is net positive.

Why it's not free on aging gear

The costs that the checklist doesn't mention, and that aging infrastructure amplifies:

  • Complexity is a failure mode. Every VLAN boundary is inter-VLAN routing and firewall rules that have to be right. On aging gear with limited routing capacity, a poorly-planned segmentation can introduce bottlenecks, asymmetric routing, and failure modes that didn't exist on the flat network. More moving parts means more things that break at 2 a.m.
  • The gear may not be up to it. Old switches have limited VLAN capacity, weak or no layer-3 features, and inter-VLAN routing that pushes traffic through a firewall that becomes a chokepoint. A segmentation design that assumes modern hardware can fall over on gear that predates it.
  • The migration is the risk. Moving a flat production network to a segmented one, live, is genuinely dangerous. Every device has to move to the right VLAN, every application dependency across the new boundaries has to be discovered (and some will only be discovered when they break), and the cutover can take down services nobody realized were talking across the flat space.
  • Undocumented dependencies bite. On a flat network, everything can reach everything, so applications and integrations were built assuming that. Segmenting reveals the hidden cross-talk the hard way — the backup job that quietly reached a host it now can't, the license server three "zones" away, the monitoring that stops seeing half the estate.

Deciding without dogma

The useful question isn't "segment or not" in the abstract. It's a few concrete ones:

Can the gear actually do it well? If the switches have the VLAN capacity, the routing headroom, and a firewall that can handle inter-segment traffic without becoming a bottleneck, segmentation is viable. If you'd be asking tired hardware to do something it was never sized for, you may be trading a security risk for a reliability one.

What's the highest-value segmentation you can do cheaply? Full microsegmentation is a big project. But the 20% that delivers 80% of the value is often small and low-risk: pull the IoT/OT devices and the guest Wi-Fi off the production network. Those are the clearest bridges to everything, and isolating just them — even on aging gear — is a large security win for a fraction of the risk and effort of segmenting the whole estate.

Is the migration risk survivable? A segmentation you can stage, test, and roll back is worth more than an ambitious one you have to big-bang. If the only way to segment this network is a risky all-at-once cutover on gear you don't fully trust, the prudent path may be to do the cheap high-value isolation now and save the full redesign for the hardware refresh that's coming anyway.

Would the refresh make it free? If this aging gear is near replacement, segmentation designed into the new network — greenfield, planned, tested before cutover — is dramatically cheaper and safer than retrofitting the old one. Sometimes the right answer to "should we segment the old LAN" is "no — we segment the new one, and we isolate only the worst offenders on the old one until then."

The honest conclusion

Segment where the value is high and the gear can carry it. Always isolate the unpatchable IoT/OT and the guest network — that's close to unconditional. Be honest about whether aging hardware can support a full segmentation without becoming less reliable than the flat network it replaces. And when a refresh is on the horizon, design the segmentation into the new build rather than risking a dangerous retrofit of the old one.

The dogma says segment everything, now. The operator's version is quieter and truer: contain the worst risks immediately, segment deeply where the infrastructure can actually carry it, and don't trade a security problem you understand for a reliability problem you created. Both are risks. The job is to end up with less total risk, not just a tidier diagram.