Network segmentation in 2026 is a layered discipline, and the work that pays off in the next incident sits as the work you do before the incident. 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 teams, and the threats change underneath them. The teams that get this right pick a handful of high value assets, segment them properly, maintain the inventory, and ship the next handful. The teams that get it wrong try to segment the whole network at once and ship nothing.
This guide is for the second kind of team, the ones who are doing the work now and want 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 development environment, and the production database. The same laptop on a properly segmented network can reach only the resources it is allowed to reach. Same exploit, same attacker, same starting point; the segmentation is what determines 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 8 days across the organisations studied, and roughly half that for the environments that practice segmentation. Half the dwell time means half the data the attacker can touch before detection, and half the lateral movement the defender has to chase. The segmented environments are not immune; they are caught earlier, with less data lost, and with the attacker still contained inside the segment they first compromised.
Put these two together and you have the case for the work. The control that limits the blast radius and buys the time serves as the control 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 the attacker can use.
The perimeter. The firewall, the DMZ, the edge filtering, the public facing surface. The perimeter counts as the workhorse of thirty years of network security, and the perimeter is also the layer that has been most over sold. The modern attacker rarely breaks through the perimeter. They phish the credentials, they exploit the unpatched edge device, they walk through the 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 counts as the configuration the attacker 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 attacker to find a rule they can abuse, and a rule they can abuse is much harder to find than a flat network they can walk through. The internal subnet structure is where most of the work happens, and most of the work is maintenance: keeping the inventory current, retiring the dead subnets, reviewing the allow rules when the application changes.
The east west control. Traffic between servers inside the data centre, the traffic that carries the ransomware from the first compromised server to the rest of the fleet. The 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: the east west traffic needs to be controlled, because the east west traffic is where the modern attacker lives once they get past the perimeter.
What to segment first
You cannot segment the whole network in a quarter. Pick the assets that matter, segment them properly, then move to the next set.
Start with the data tier. The customer database, the financial systems, the authentication store, the crown jewels. The reason stands as the obvious one: this is what the attacker is after, and this is what the breach report is going to mention. The data tier should be 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 is usually on the same flat network as the office IT, and operational technology is usually the entry point the attacker uses to pivot into the corporate environment. Where possible, air gap the operational technology entirely. Where the 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 becomes the right starting reference. The insurance carrier serves as the right forcing function: ask the underwriter what they expect, and segment to that.
Then the development environment. The developer laptops, the staging servers, the CI runners, the container build infrastructure. The development environment runs as the highest risk surface in the modern enterprise, and the supply chain attack lives here. The development environment should not be on the same network as production, should require explicit allow rules to reach production, and should be treated as a separate trust zone. A developer laptop that can reach the production database is a developer laptop that can leak the production database when the developer’s credentials get phished.
What the operations team 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 teams change, and the threats change. The operations team needs three things to keep the segmentation working, and the operations team needs all three funded as ongoing operational cost, not as a one off project budget.
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. The segmentation project that ships without an ongoing inventory becomes the segmentation project that degrades within six months, because the rules drift out of sync with the reality, and the rules that drift are the rules that fail closed or fail open at the worst possible time. The segmentation project that ships with the inventory funded as operations serves as 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 teams that do this well treat segmentation as a platform the application teams consume, not as a project the security team gates. The application team submits a ticket, the platform team approves the rule, and the application team has the access they need without a security review on every change. The teams that do this poorly gate every rule through the security team, the security team becomes a bottleneck, and the application teams route around the segmentation with a third party SaaS the security team does not know about.
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 team needs the runbook to respond. The detection rules that catch the unexpected traffic are the rules that turn a breach into an incident that gets contained before the data leaves the segment.
What to do 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 runs as the work, and the work takes longer than the budget says it will. The teams that ship segmentation in a quarter pick the three highest value assets and the three highest value segments. The teams that ship segmentation in a year try to do the whole network at once and ship nothing useful. Pick the assets, pick the segments, ship the work, and move to the next set.
Segmentation is one of the few security controls where the boring work stands as 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
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
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.
