It's 9:00 on a Monday morning, and Sam already has 14 new requests in the ticket queue.
Sam is a senior network security engineer at a large bank with branches all over the country. Sam is a composite, built from several teams I've worked with, and the details are blended so no one is recognisable. So please don't go looking for him.
The requests look like this:
- Connect new IoT sensors at a regional branch
- Temporary vendor access for a compliance audit
- Configure switch ports for a new bare-metal server
- "Can we open port 443 for this new service?"
- New firewall rules for an application rollout
Each one is the same grind. Log in to a switch (or five). Configure the right VLANs. Write the firewall rules. Update the documentation. Hope nothing breaks.
The change itself takes about 30 minutes. The chain around it takes much longer: reviewing the current configuration, raising a change request, chasing approvals, making the change, and fixing whatever the change broke.
By lunch, Sam has closed three. Eleven to go.
Then, mid-afternoon, an email from the auditor:
"Why does the solution diagram show separation between these two zones, when the firewall rules permit broad access?"
A simple question. Not a simple answer.
The diagram dates from a project that finished years ago. To answer, Sam has to work through a spreadsheet of several hundred firewall rules, cross-check firewall logs and switch configurations, dig through old emails, and piece together the rest from memory. The answer the auditor gets at the end still won't be one they love.
That gap, between the diagram and the rules actually running on the firewall, is what this post is about.
TL;DR
- "Trust the inside" no longer works. Once inside, attackers start moving to other systems in about half an hour on average.
- Doing segmentation by hand doesn't scale. Every change adds to a pile no team can keep up with.
- Regulators now ask for segmentation you can prove, not just draw.
The inside is no longer safe
Back in the 20th century, network security was simple. The outside was the threat. The inside was safe.
That trust is gone.
29 minutes. That's the average breakout time for criminal attackers in 2025, according to CrowdStrike's 2026 Global Threat Report: the time from their first foothold to moving sideways into other systems. The fastest they recorded took 27 seconds.
One compromised laptop or one set of stolen credentials is the foothold. Whether the attacker can then reach core banking, patient records or payment systems depends on what your network lets them reach.
So the question isn't whether an attacker will get in. It's whether your architecture can contain the damage when they do.
Segmentation in two minutes
Network segmentation splits one network into smaller, isolated zones, each with its own rules about who and what can talk to it. If an attacker gets into one zone, they shouldn't be able to wander into the next.
Think of fire doors in a building. They don't stop a fire starting. They slow it down, contain the damage and give people time to respond. Take them away and the fire goes wherever the air goes.
There are many ways to draw the lines, but they come down to three levels:
- Coarse: separate physical networks or VLANs that split the network into big chunks, such as branches, data centre and corporate. Familiar and cheap, but configured by hand, switch by switch.
- Zone-to-zone: firewall rules that control what traffic may cross between those chunks. Powerful, and the place where complexity piles up fastest.
- Fine-grained (micro-segmentation): rules around individual applications, servers or containers. It's the closest fit for a Zero Trust architecture, and it brings the most rules to manage.
Software-defined networking platforms and dedicated micro-segmentation tools can automate a lot of this. But most organisations still run a mix, and a lot of it is still done by hand.
Why manual segmentation doesn't scale
Sam's Monday isn't bad luck. It's what manual segmentation looks like every day.
Every manual change is a chance for human error. Every outdated diagram is a compliance gap someone will have to explain. Every slow request is a bottleneck for the business, and a phone call from the boss waiting to happen.
None of these is fatal on its own. That's the trouble with a thousand cuts: each one is small, and they keep coming. Every new device, every new workload, every new policy and every new rule adds to the pile.
And the asks only grow. Better security. Clearer documentation. More compliance. Wider scope. Faster turnaround. Usually with the same team, or a smaller one.
Somewhere along the way, the fire door gets propped open with a wad of tickets, "just for now".
Sam's story isn't unique. In a 2025 survey of 1,000 people commissioned by Cisco, 79% said segmentation was a top priority for their organisation, but only 33% had fully implemented both broad (macro) and fine-grained (micro) segmentation. It's a vendor survey, so take it with a pinch of salt, but a gap that wide is hard to explain away.
And this isn't just an operational headache any more. It's becoming a regulatory one.
Regulators have noticed
Regulators are no longer satisfied with "we have a perimeter firewall and some VLANs". They want segmentation that matches how critical each system is, and evidence that it's still working.
A few examples:
- EU financial services (DORA): the technical standard on ICT risk management requires financial entities to segregate and segment their networks based on how critical each system is. It also requires a review of network architecture once a year, and a check of the firewall rules for critical systems at least every six months. And under DORA's threat-led penetration testing, the most significant firms face red teams who try exactly the sideways movement segmentation is meant to stop, on live systems.
- Payments (PCI DSS v4.0): if you use segmentation to keep card data separate, you must penetration-test those controls at least every 12 months and after any change to them. Service providers have to do it every six months.
- US healthcare (HIPAA): a proposed update to the HIPAA Security Rule would make network segmentation an explicit requirement. It isn't final yet, and the final rule is currently expected in July 2027.
Notice the pattern. Nobody is asking to see your diagram. They're asking you to prove the diagram is true. Your diagram shows clean separation. Your firewall rules may tell a different story. These rules are designed to find exactly that gap.
Where we go from here
The problem is clear. Manual segmentation doesn't scale, regulators want proof, and the gap between the diagram and reality keeps growing with every ticket.
So what's actually standing in the way of fixing it?
In the next post, I'll look at the four challenges that make segmentation so hard to deploy: distributed sites, technical complexity, policy management and team alignment.
Over to you: when did someone last check your firewall rules against your network diagram, and which one turned out to be right?
References
- CrowdStrike, "2026 CrowdStrike Global Threat Report: AI Accelerates Adversaries and Reshapes the Attack Surface", 24 February 2026.
- Aamer Akhter, "2025 Cisco Segmentation Report Sheds Light on Evolving Technology", Cisco Blogs, 23 October 2025.
- European Commission, Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk management framework), Article 13, 25 June 2024.
- European Commission, Commission Delegated Regulation (EU) 2025/1190 (DORA threat-led penetration testing), 18 June 2025.
- PCI Security Standards Council, "Just Published: PCI DSS v4.0.1", 11 June 2024, Requirements 11.4.5 and 11.4.6 (requirement text).
- US Department of Health and Human Services, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information" (proposed rule), Federal Register, 6 January 2025.
- HIPAA Journal, "HIPAA Security Rule Update Postponed".
