8 MIN READ
Network segmentation in 2026 is a layered discipline, and the work that pays off in the next incident is the work done before the incident, not during it. Treat it as a programme, not a project. A project ships a set of firewall rules and walks away. A programme keeps the rules current as the systems, the organisations, and the threats change underneath them. Most security orgs try to segment the whole network at once and ship nothing. A smaller set picks a handful of high value assets, segments them properly, maintains the inventory, and ships the next handful. The difference is almost always programme discipline, not technical skill.
This guide is for the second camp, the ones doing the work now and wanting to do it properly.
What segmentation actually does
Segmentation limits blast radius. A compromised laptop on a flat office network can reach the file share, the print server, the engineering environment, and the production database. The same laptop on a properly segmented network can reach only the resources it has been explicitly allowed to reach. Same exploit, same attacker, same starting point. The segmentation is what decides whether the incident ends at the laptop or runs to the database.
Segmentation also buys time. Sophos State of Ransomware 2024 reports a median dwell time of around eight days across the organisations studied, and roughly half that for environments that practice segmentation. Half the dwell time means half the data the intruder can touch before detection, and half the lateral movement the defender has to chase. Segmented environments are not immune. They get caught earlier, with less data lost, and with the intruder still contained inside the segment they first compromised.
Put these two together and the case writes itself. The control that limits blast radius and buys time is the one that decides whether a breach is a contained incident or a regulatory disclosure.
The three layers that matter
Modern segmentation runs at three layers, and each layer does a different job. Skipping any one of them leaves a gap an intruder can use.
The perimeter. The firewall, the DMZ, the edge filtering, the public facing surface. Thirty years of network security have leaned on the perimeter, and the perimeter has also been the most oversold layer. The modern intruder rarely breaks through the perimeter. They phish the credentials, exploit an unpatched edge device, or walk through a partner VPN that nobody remembers to monitor. Treat the perimeter as a useful second line of defence, not as the first.
The internal subnet structure. VLANs, subnets, firewall rules between them. A single flat VLAN with hundreds of endpoints is the configuration an intruder dreams of, because every endpoint is one credential theft away from every other endpoint. A properly segmented network with explicit allow rules between subnets forces the intruder to find a rule they can abuse, and that is much harder than walking a flat network. Most of the work happens here, and most of the work is maintenance: keeping the inventory current, retiring dead subnets, reviewing allow rules when the application changes.
The east west control. Traffic between servers inside the data centre, the traffic that carries ransomware from the first compromised server to the rest of the fleet. Microsegmentation tooling (Illumio, Cisco Tetration, the open source equivalents) gives per workload policy. The service mesh (Istio, Linkerd, Cilium) gives per request authentication and authorisation at the application layer. Both add operational overhead. The choice between them depends on whether the workload is on bare metal or already in Kubernetes, and the choice does not change the principle: east west traffic needs to be controlled, because east west traffic is where the modern intruder lives once they are past the perimeter.
What to segment first
You cannot segment the whole network in a quarter. Pick the assets that matter, segment them properly, move to the next set.
Start with the data tier. The customer database, the financial systems, the authentication store, the crown jewels. The reason is the obvious one: this is what an intruder is after, and this is what the breach report will name. The data tier belongs on its own subnet, with explicit allow rules from the application tier, and deny by default for everything else. Verify the deny by default by trying to reach the data tier from a workstation, a development laptop, a contractor VPN, and the partner integration. If any of them succeed, the deny by default is not actually deny by default.
Then the operational technology. The SCADA, the building management, the camera network, the badge readers, the printers. Operational technology usually lives on the same flat network as the office IT, and operational technology is usually the entry point an intruder uses to pivot into the corporate environment. Where possible, air gap the operational technology entirely. Where an air gap is not possible (the building management system that needs to phone home, the camera network that needs to be reachable from the security operations centre), put it on a dedicated VLAN with strict ingress and egress rules. NIST SP 800 82 is the right starting reference. The insurance carrier tends to be the right forcing function: ask the underwriter what they expect, and segment to that.
Then the development environment. Engineering laptops, staging servers, CI runners, container build infrastructure. The development tier runs as the highest risk surface in the modern enterprise, and the supply chain attack lives here. The development environment should not share a network with production, should require explicit allow rules to reach production, and should be treated as a separate trust zone. An engineering laptop that can reach the production database is one that can leak the production database when the engineer’s credentials get phished.
What the operations org needs to keep it working
Segmentation ships as a project and lives as a programme. The project ends when the firewall rules are in place. The programme continues as the systems change, the organisations change, and the threats change. Three things need to be funded as ongoing operational cost, not as a one off project budget, or the segmentation drifts inside six months.
The inventory. Every device on every subnet, owned by a team, with a refresh cadence. Most organisations have an incomplete inventory of the operational technology, an even more incomplete inventory of the IoT, and a near complete absence of the shadow IT. A segmentation project that ships without an ongoing inventory becomes one that degrades inside six months, because the rules drift out of sync with the reality, and the rules that drift fail closed or fail open at the worst possible time. The project that funds the inventory as operations tends to be the one that lasts.
The change management. Every new application, every new service, every new team needs to be reflected in the firewall rules. The organisations that do this well treat segmentation as a platform the application teams consume, not as a project the AppSec team gates. The application team submits a ticket, the platform org approves the rule, and the application team has the access they need without a security review on every change. The organisations that do this poorly gate every rule through the security org, the security org becomes a bottleneck, and the application teams route around the segmentation with a third party SaaS nobody in security has ever heard of.
The detection. Unexpected cross segment traffic is a signal. A workstation reaching the data tier it has never reached before, a server reaching the operational technology it has never reached before, a partner integration reaching the development environment it has never reached before. The detection rules need to catch these, and the operations org needs the runbook to respond. The rules that catch the unexpected traffic are the ones that turn a breach into an incident that gets contained before the data leaves the segment.
What to ship this quarter
The honest checklist for the next ninety days is short. Pick the highest value asset (the customer database, the payment system, the authentication store), put it on its own subnet, write the allow rules for the application tier, verify the deny by default for everything else, and move to the next asset. The work takes longer than the budget says it will. The security orgs that ship segmentation in a quarter pick the three highest value assets and the three highest value segments. The ones that try to do the whole network at once ship nothing useful. Pick the assets, pick the segments, ship the work, move to the next set.
Segmentation is one of the few security controls where the boring work is the work that pays off. The next breach will be in the news, and the next breach will be in an environment that did not do the boring work. Ship the boring work now, and the next breach will not be in yours.
The bottom line
Pick the highest value assets, segment them properly, fund the inventory as operations, and let the perimeter be a second line of defence rather than the first. Segmentation is not the exciting part of cybersecurity, and the boring part is the part that decides whether the next incident is a contained event or a regulatory disclosure.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
