Most organisations consider network segmentation a problem they have already solved. Guest traffic is separated, corporate users sit on a different network and firewalls are in place to control access between zones. From a distance, that structure appears sound and is often taken as evidence that segmentation is working as intended, but that confidence tends to soften when attention shifts from network boundaries to what actually happens inside the environment.
Questions about how applications are isolated from one another, how lateral movement is constrained after an initial compromise, and how access decisions are made beyond basic IP constructs often reveal assumptions that have never been tested. In many cases, segmentation exists in name, but not in effect.
Despite this, segmentation remains one of the most reliable ways to reduce risk. When applied deliberately it limits exposure, constrains attacker movement and reduces the impact of inevitable failures. The challenge is rarely the absence of technology. More often, it lies in how segmentation is understood, how policies are designed, and how deliberately they are applied over time.
This blog explores how segmentation is commonly implemented, why it often fails to contain risk, and what a more deliberate, intent‑based approach looks like in practice.
Segmentation isn’t new, and that could be part of the problem. It doesn’t feel exciting or come with a flashy dashboard and a promise to solve everything overnight, but what it does do consistently is reduce exposure. It limits the attack surface by controlling where traffic can flow and the blast radius when something inevitably goes wrong. From an attacker’s point of view, this matters because it directly breaks the techniques most breaches rely on, particularly lateral movement and internal discovery. That’s why network segmentation is recognised as a formal mitigation in frameworks like MITRE ATT&CK.
When an attacker compromises a system, segmentation determines whether the compromise stops there, or escalates into a business-wide incident. That makes it foundational, not optional. Yet too often, it’s treated as an afterthought once perimeter controls and access solutions are in place.
One of the most common patterns we see is organisations believing they have already solved segmentation. Often, this is because they have deployed network access control or basic network separation.
In practice, that usually means devices are placed on different networks based on simple criteria, and little thought is given to what they can reach once connected. The result? Once an attacker gains a foothold on any system, moving sideways to other systems is often far easier than most teams realise. Policies are then built around IP addresses and subnets because that is how segmentation has traditionally been done. The result is brittle rules that are hard to maintain and rarely reflect how modern environments work.
Intent-based segmentation flips the model. Instead of asking where something lives on the network, you ask what it is, who uses it, and what it needs to do.
Policies are defined around users, device types, applications and roles, and the network becomes an enforcement layer rather than just a transport mechanism.
This approach isn’t about adding complexity for complexity sake. It’s about decreasing operational pain by aligning security policy with how the business operates, rather than forcing everything into rigid network constructs.
Another common misconception is that segmentation is only about controlling access to an application. In reality, many applications consist of multiple tiers that should never be freely accessible to one another. Web servers, application servers and databases serve different purposes and expose different risks.
If a front-end system is compromised, proper segmentation prevents that breach from automatically spreading to the data layer. Instead of unrestricted movement across the environment, an attacker is forced through tightly controlled pathways where suspicious activity is much easier to detect and stop. This kind of internal segmentation is often overlooked, even in environments that consider themselves mature.
If segmentation is so powerful, why isn’t it being applied more deliberately? The short answer, historically, is that it’s been operationally difficult. Deeper segmentation meant:
As a result, many organisations deprioritised it in favour of newer, more visible security investments.
The irony is that many organisations already own tools capable of far more advanced segmentation than they currently use. Those capabilities sit idle because no one has stepped back to think about how they should be applied. Buying another product rarely fixes this. What does fix it is clarity around scope, priorities and intent.
With modern platforms providing far better insight into traffic flows, identities and application behaviour, there are now more places across the network, workloads and infrastructure where policies can be enforced consistently. Just as importantly, abnormal traffic becomes far more obvious when it crosses a defined segment boundary – giving security teams clearer, higher-confidence signals that something is wrong.
There is also a clearer understanding across the industry of what zero trust and microsegmentation aim to achieve, making it easier to design toward a defined end state.
Segmentation does not need to be an all-or-nothing exercise. In fact, trying to segment everything at once is one of the fastest ways to fail. A more effective approach is to start with what matters most and build confidence over time.
A practical segmentation policy cycle looks like this:
Finally, enforce, monitor and refine continuously, recognising that networks and threats never stand still
Alongside this cycle, a few guiding principles consistently make the difference:
We regularly hear from our customers that segmentation is already covered by existing access controls, or that zero-trust initiatives have addressed the problem. In reality, those controls often stop at the front door, leaving segmentation within the environment untouched. Policies may exist, but they are rarely revisited or extended to application-level enforcement.
Segmentation is not a checkbox. Rather, it’s an ongoing discipline that develops in tandem with the environment it protects.
If segmentation feels difficult, it’s usually because it’s been treated as a technology problem instead of a design and operating model challenge.
That’s exactly what the Segmentation Unlocked workshop is designed to address.
Rather than jumping straight into tools, this session helps you step back and answer the critical questions that shape an effective segmentation strategy.
By the end of the workshop, you’ll walk away with:
✔ Proven segmentation design strategies
✔ How segmentation is applied across on-prem, hybrid cloud, and OT
✔ Real-world architecture decisions, trade-offs, and pitfalls
✔ Where Cisco SDA & Hybrid Mesh Firewall fit (and where they don’t)
✔ Practical approaches you can apply in your own environment
Whether you’re early in your journey or looking to get more value from existing investments, the workshop provides a structured way to turn segmentation from a theoretical control into a measurable security outcome.
You can learn more or register here: https://www.data3.com/event/segmentation-unlocked/