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 challenging, that is usually a sign that it has been approached as a technology problem rather than a design problem.
Data#3 works with organisations every day that understand the importance of segmentation but are unsure where to start or how far they can realistically take it given their existing environment. With deep experience across networking, security and infrastructure, Data#3 approaches segmentation as a design and operating problem first, not a product conversation.
By assessing current controls, mapping application dependencies, and designing policies that align with business intent, we help reduce exposure and the blast radius in ways that are achievable, maintainable, and consistent with how their network actually runs.
If you want to understand how effective your current segmentation is, regardless of which vendor you’re currently aligned with, and what a practical path looks like, you can talk to one of Data#3’s security team. Done properly, segmentation stops being the boring thing no one wants to touch and becomes one of the most valuable controls you can have.