Network segmentation is not enough on its own. It reduces your attack surface and limits blast radius, but it does not stop an attacker who has already made it inside a segment. Once someone is in, segmentation alone gives them room to move, probe, and escalate — and most organizations have more trust baked into their internal networks than they realize. The sections below break down exactly where segmentation falls short, what fills the gaps, and how to find the holes in your current setup before someone else does.
What can attackers still do inside a segmented network?
Inside a network segment, an attacker can still move laterally between hosts, escalate privileges, exfiltrate data, and establish persistence — all without crossing a segment boundary. Segmentation controls traffic between zones, not within them. If a device inside a segment is compromised, everything else in that same segment is reachable. That is the core problem segmentation alone cannot solve.
Think about what “inside a segment” actually means in a real enterprise environment. You might have 50 endpoints in a single VLAN (Virtual Local Area Network). If one of those endpoints gets hit with a phishing payload, the attacker now has a foothold with direct network access to the other 49. They can scan for open ports, probe for unpatched services, harvest credentials from memory, and move to the next host — all without triggering a perimeter alert because they never crossed a segment boundary.
This is not a theoretical risk. Credential harvesting tools, pass-the-hash attacks, and SMB (Server Message Block) relay attacks are all designed to exploit exactly this kind of implicit trust within a segment. Segmentation was never designed to stop this. It was designed to contain it — and containment is only useful if you catch the breach fast enough to act.
What’s the difference between network segmentation and microsegmentation?
Network segmentation divides a network into broad zones — typically by function, department, or trust level — and controls traffic between those zones using firewalls or access control lists. Microsegmentation goes further by applying granular, workload-level policies that control traffic between individual hosts, containers, or applications, even within the same zone. The key distinction is granularity: segmentation works at the zone level, microsegmentation works at the workload level.
Traditional segmentation might separate your finance VLAN from your engineering VLAN. That is useful. But microsegmentation says that within the finance VLAN, the accounts payable server should only talk to the ERP (Enterprise Resource Planning) system on specific ports — and nothing else. Every other connection attempt gets denied by default.
Microsegmentation is harder to implement because it requires a detailed understanding of your application dependencies. You need to know what talks to what before you can write policies that allow the right traffic and block everything else. That inventory work is painful, but it is also what makes microsegmentation genuinely effective where broad segmentation is not.
How does lateral movement bypass segmentation controls?
Lateral movement bypasses segmentation controls by exploiting trust that already exists within a segment. Attackers use legitimate credentials, approved protocols, and authorized communication paths to move between systems — none of which trigger segmentation rules because the traffic looks normal. Segmentation blocks unauthorized zone crossings, not authorized-looking traffic inside a zone.
The most common techniques include credential theft and reuse, where an attacker harvests a service account password and authenticates to other systems using it. They also exploit overly permissive firewall rules that allow broad internal access “for operational convenience.” And they abuse trusted administrative protocols — RDP (Remote Desktop Protocol), WinRM, SSH — that are often allowed everywhere inside a segment because IT needs them for management.
The uncomfortable truth is that most segmentation policies are built around what needs to be blocked, not around what should be explicitly allowed. That default-permit posture inside segments is exactly the gap attackers exploit. You cannot fix this with more segmentation rules. You need a different model entirely.
What is zero trust, and how does it go beyond segmentation?
Zero trust (ZT) is a security model built on the principle of “never trust, always verify.” Instead of granting access based on network location — being inside the perimeter or inside a segment — zero trust requires every user, device, and application to authenticate and authorize every connection, every time. It goes beyond segmentation by eliminating implicit trust entirely, not just reducing the zones where that trust applies.
Segmentation says: “You are in the finance zone, so you can talk to other finance systems.” Zero trust says: “You are a specific user, on a specific device, with a verified identity, requesting access to a specific resource — and that access is granted only for this session, only for this resource, and only if your device posture meets our policy.”
The practical difference is enormous. Zero trust architectures enforce identity-based access controls at the application layer, not just at the network layer. They continuously validate device health, user behavior, and session context. And they apply the principle of least privilege — meaning every entity gets the minimum access required to do its job, nothing more.
Zero trust network access (ZTNA) is the network implementation of this model. It replaces broad network access with application-specific, identity-verified connections. Where a traditional VPN (Virtual Private Network) drops a user onto the network and trusts them to behave, ZTNA grants access only to the specific application the user needs — and nothing else is reachable.
Should you replace network segmentation or build on top of it?
You should build on top of segmentation, not replace it. Segmentation is still a valid and useful control — it limits blast radius, satisfies compliance requirements, and provides a meaningful layer of defense. The problem is treating it as sufficient. The right approach is to layer zero trust controls, microsegmentation, and identity-based access on top of your existing segmentation architecture.
Ripping out segmentation entirely is operationally risky and rarely necessary. Your existing zone boundaries, firewall rules, and VLAN structure still provide value. What they need is reinforcement at the workload level and at the identity layer.
A practical layered approach looks like this:
- Segmentation: Broad zone isolation between departments, functions, and trust levels
- Microsegmentation: Workload-level policies within zones, enforcing least-privilege communication
- ZTNA: Identity-verified, application-specific access replacing broad network access grants
- Continuous monitoring: Behavioral analytics and anomaly detection to catch what the policy layers miss
Each layer catches what the one below it misses. None of them is sufficient alone. Together, they create a defense-in-depth posture that is genuinely hard to move through undetected.
How do you identify the gaps in your current segmentation strategy?
You identify gaps in your segmentation strategy by mapping actual traffic flows against your intended policy, auditing trust assumptions baked into your rules, and testing whether lateral movement is possible within your existing segments. Most organizations find that their real-world traffic patterns diverge significantly from their documented architecture — and that divergence is where the gaps live.
Start with traffic visibility. Deploy network flow analysis or a network detection and response (NDR) platform to capture what is actually communicating with what inside your segments. Compare that against your firewall rules and access control lists. You will almost certainly find connections that should not exist — legacy rules that were never cleaned up, service accounts with excessive reach, and east-west traffic that was never intended to be allowed.
Next, audit your trust assumptions. Ask these questions for every segment:
- What is the default posture inside this segment: permit or deny?
- Which protocols are allowed between hosts within the segment, and why?
- Which service accounts have access to multiple systems, and are those accounts monitored?
- What would an attacker be able to reach if they compromised any single host in this segment?
Finally, run a tabletop exercise or engage a red team to attempt lateral movement within your highest-value segments. You do not need a full penetration test to get useful signal. Even a structured internal exercise — “assume this endpoint is compromised, what can we reach?” — will surface gaps that documentation reviews miss.
For organizations in regulated industries, defense contracting, or environments with significant technical debt in their defense networks, this audit process often reveals that software-defined networking approaches can close gaps faster than hardware-based segmentation changes. Rebuilding segment boundaries in hardware is slow and expensive. Software-defined overlays let you enforce granular access policies without touching physical infrastructure.
How ZeroTier helps close the gaps segmentation leaves open
ZeroTier is an encrypted overlay networking platform — not a VPN — that lets you enforce identity-based, software-defined network access across your entire environment without replacing your existing infrastructure. For security and compliance leaders dealing with complex, distributed environments, it addresses the specific gaps that segmentation alone cannot close.
- Software-defined access control: Define exactly which devices and users can communicate, at the network layer, without relying on physical topology or hardware firewall rules.
- Post-quantum cryptography: ZeroTier Quantum embeds hybrid FIPS (Federal Information Processing Standard) 140-compliant post-quantum cryptography directly into the transport layer, meeting NIST (National Institute of Standards and Technology) and NSA CNSA 2.0 standards — critical for the defense industrial base and regulated environments concerned about quantum security threats.
- Air-gapped and sovereign deployments: Fully self-hosted configurations support air-gapped environments where cloud-based controls are not acceptable.
- Minimal footprint, maximum scale: A 2 MB memory footprint with up to 40 Gbps throughput means you can enforce granular access policies at scale without introducing performance bottlenecks.
- Built in memory-safe Rust: The platform is secure by design, not just by configuration — reducing the attack surface at the software level.
If your current segmentation strategy has gaps you already know about — or ones you suspect but have not mapped yet — ZeroTier gives you a faster path to closing them than hardware-based redesigns. Talk to the team about where your environment stands and what a software-defined overlay approach would look like in practice.
Related Articles
- How are defense contractors actually meeting CMMC 2.0 network requirements?
- What's the real cost of outdated remote access tools in a distributed workforce?
- Why are government IT teams moving away from hardware-dependent networking?
- What does 'assume breach' mean for how you design your network today?
- Why does a multi-cloud environment break perimeter-based security models?