Updated: an earlier version of the blog post included an incorrect quote. The way we segment networks defines how we contain attacks. But as architectures have evolved, so must segmentation itself. What began as firewalls at the edge now needs to extend everywhere, across zones, between workloads, and deep within the systems we run. Segmentation is no longer a fixed concept; it exists across a spectrum that must evolve with how applications are built, deployed, and secured. That evolution is no longer optional. The frequency and scale of modern breaches show how attackers exploit weak boundaries and inconsistent controls. When segmentation fails, intruders move freely and quietly within the environment, often for months before they are detected. In recent months, cyber attacks have disrupted operations across well-known UK businesses. Retailers faced outages that left shops and websites offline, while manufacturers such as Jaguar Land Rover have faced significant operational disruption and financial impact following recent cyber incidents. In 2017, the law firm DLA Piper was struck by the NotPetya ransomware outbreak. The infection began in a branch office in Ukraine and spread globally within minutes. Operations ground to a halt. Signs were posted on whiteboards: “Attention DLA employees – all network services are down. Do not turn on your computers! Please remove all laptops from docking stations and keep them turned off.” This extreme measure reflected a genuine fear that reconnecting infected devices could accelerate the spread of the ransomware across the firm’s internal network. Microsegmentation became part of the remediation strategy, highlighting how perimeter and branch firewalls alone could not contain lateral movement once attackers gained a foothold. These incidents show the cost of insufficient segmentation. To understand how we got here, it helps to look back before we look ahead. From Firewalls to Segmentation When the first network firewalls appeared in the late 1980s and early 1990s, they served as barriers at the edge, acting as controls between inside and outside networks. That perimeter model worked when most traffic was north–south (entering or leaving the data centre). Today, most data centre traffic flows east-west, meaning it stays within the environment rather than entering or leaving it. This shift has made lateral movement one of the most effective tactics for attackers, who exploit internal pathways once they gain a foothold. Two of the most influential networking minds of the past quarter century, Larry Peterson and Bruce Davie, have written about this evolution of traffic patterns and the security challenges it creates. In their Systems Approach work, Bruce and Larry highlight how the concept of network boundaries has shifted over time, showing that firewalls continue to evolve from simple packet filters at the edge to distributed security systems that are closer to the workloads they're designed to protect. This is how you should be thinking about segmentation today: not as a static box on the edge, but as a moving boundary that must evolve with each generation of infrastructure. From Microsegmentation to the Segmentation Spectrum The first time I heard Martin Casado, the godfather of software-defined networking and the creator of NSX, explain microsegmentation, it changed how I thought about security. The idea of a centrally managed, distributed firewall in front of every virtual machine was powerful enough that I joined VMware soon after to work on NSX. Years later, Martin backed Isovalent as a seed investor, joined by Cisco, which was also an early believer in the company. Their support was a clear signal that the team behind Cilium and eBPF were on the right path to redefine security. Cisco’s acquisition of Isovalent seven years later confirmed that early faith had become long-term conviction. For me, joining Isovalent felt like pursuing the same mission of revolutionising security, continuing a journey I had started years earlier. NSX and Cisco’s own ACI platform applied the concept of microsegmentation primarily to virtual machines running on hypervisors. With the rise of Kubernetes, that model has evolved to include containers, pods, and even virtual machines running inside Kubernetes clusters. It became clear to me that the definition of segmentation itself had to evolve, which is what led me to describe it as a Segmentation Spectrum. It is a way of thinking about how controls need to exist at multiple layers, from macro separation across zones to micro policies between workloads, and even down to runtime enforcement. The Segmentation Spectrum Segmentation spans from broad separation at the infrastructure layer, through workload-to-workload controls, down to runtime and process-level enforcement. Each layer plays a different role. Macro segmentation defines the broad boundaries. Micro segmentation governs workload interactions. Runtime segmentation enforces controls within the workloads themselves. Macro Segmentation Macro segmentation refers to broad separation of environments. It can mean splitting networks by geography, isolating different business entities, enforcing tenant boundaries, or dividing racks from one another. This level of segmentation is often the first line of control in large or multi-tenant environments. Examples include: Environment segmentation: Production vs. Test Tenant segmentation: Pepsi vs. Coca-Cola Departmental segmentation: Finance vs. HR Cloud segmentation: VPCs or VNets, separated by peering or transit gateways Compliance segmentation: PCI-DSS cardholder environment (CDE) vs. the network outside PCI scope Geographic segmentation: EMEA vs. APAC A new form of macro segmentation is now appearing at the physical layer. At the top of the rack, Cisco Smart Switches introduce programmable DPUs, or data processing units. These dedicated processors offload and accelerate networking and security functions, allowing services such as firewalls and telemetry to run directly on the DPU rather than on the switch itself. In the past, racks of workloads were connected through switches with no native firewalling, forcing traffic to hairpin out to central appliances and creating chokepoints, latency, and operational cost. Some organisations tried to compensate with hypervisor-based microsegmentation or software agents, but both approaches added complexity and dependency. Smart Switches change this model entirely. Segmentation can now be enforced between servers directly within the rack, without hypervisor support, agents, or additional rack space. By steering traffic from the switching ASIC into the DPU only when needed, the switches reduce latency, simplify design, and eliminate external firewall hops. It reminds me of the extensibility once offered by Cisco ISRs or Catalyst 6500s with physical service modules, or even by eBPF's ability to dynamically insert programs directly into the Linux kernel. Now these capabilities run directly on the switch DPU. The architecture is software driven and future proof. Over time it could host additional modules, for example an Isovalent Load Balancer, enabling a programmable fabric that unifies connectivity and security at the rack. Micro Segmentation When Martin Casado first described microsegmentation, the idea was revolutionary: applying distributed firewalling directly to workloads rather than at the perimeter. That principle still defines modern segmentation, but its scope has widened. Microsegmentation now focuses on controlling workload-to-workload communication rather than zone-to-zone, containing the lateral movement that once allowed breaches to spread. The emphasis has shifted from large network boundaries to the workloads themselves and how they interact. This can apply to: Physical machines or bare-metal servers Classic application tiers, such as database vs. application servers Virtual machines on hypervisors Cloud instances (EC2, Azure VMs, GCE instances) Containers and Kubernetes pods Microservices within the same application communicating over APIs AI training systems vs. AI inference systems AI agent to AI agent interactions In Kubernetes, the platform most organisations use to run and deploy applications, microsegmentation is implemented through network policies. These policies define which workloads can communicate with one another, effectively serving as distributed firewall rules inside the cluster. By default, however, every pod can talk to every other pod without restriction. While this is convenient for platform teams establishing connectivity for applications, it clearly comes with a security compromise. When applications move into production, operators often have to retrofit restrictive policies into their clusters - a non-trivial task. Some fear breaking essential communications, while others are limited by inadequate tooling to design and validate the right rules. As a result, many environments remain far more open than intended. What we discovered in our State of Kubernetes Networking survey is telling: around a quarter of respondents are only using basic L3 and L4 network policies - essentially application-unaware firewalls - while another quarter are not using them at all. This leaves a significant portion of workloads without meaningful protection against lateral movement. The Isovalent Enterprise Platform provides the foundation for Kubernetes-aware microsegmentation. It not only supports Layer 7 and identity-based network policies that go beyond simple IP and port matching, but also allows engineers to design granular, hyper-specific rules based on actual observed traffic, supported by Hubble Enterprise. This ensures policies reflect reality rather than assumptions, and it provides the precision needed to satisfy regulatory and compliance frameworks such as PCI-DSS and GDPR. Beyond Kubernetes, Cisco Secure Workload delivers mature microsegmentation for environments where eBPF cannot yet be deployed, such as Windows and older Linux kernels. It also integrates with Cisco and cloud identity providers, making it well suited for hybrid and legacy environments. You might have noticed a pattern. We are evidently moving controls ever closer to where applications execute, until segmentation becomes something that happens inside the workload itself, at the runtime and process level. Nano Segmentation On the finer end of the spectrum, segmentation moves into the workloads themselves. Runtime segmentation - what I like to call nanosegmentation - focuses on what happens inside an application once it is running, when code is actively executing in memory and processes are interacting with the system. It is the phase where traditional network and workload controls have limited visibility. While microsegmentation limits which workloads can communicate with each other, runtime segmentation limits what those workloads can do. It observes process behaviour, system calls, and identity context to decide whether an action should be allowed. In effect, it enforces segmentation not just between workloads but within them. Isovalent Runtime Security provides this capability by observing kernel-level activity through eBPF and applying real-time enforcement based on process identity. For example, it can detect when a process attempts to access a network resource it should not, or when a binary executes in an unexpected context. These detections can then trigger enforcement actions, such as blocking the connection or alerting the operator. Runtime segmentation makes it possible to stop malicious behaviour directly at the source before it spreads laterally. A key use case is distributed exploit protection, where these capabilities defend not only workloads but also the underlying network platform itself. Cisco’s Live Protect initiative extends runtime detection and enforcement across Nexus switches, allowing threats to be contained at the point of execution. In this model, security becomes distributed and autonomous, capable of acting the moment suspicious behaviour is observed. Runtime segmentation complements macro and micro segmentation by operating where applications actually execute, reducing the gap between detection and response. It brings control to the closest possible point of risk, the process itself. Isovalent’s Role in the Spectrum Across the segmentation spectrum, Cisco and Isovalent deliver controls that extend from the fabric to the workload and deep into the runtime. Each layer reinforces the next, creating a consistent approach to visibility and enforcement across data centre, cloud, and edge environments. As the creators of Cilium and eBPF, Isovalent helped establish the foundation of modern cloud networking and security. With Cisco’s acquisition of Isovalent, and the integration of the Isovalent Enterprise Platform with Cisco Secure Workload, Hypershield, and Smart Switches, this combined portfolio now delivers a unified segmentation spectrum across hybrid and multi-cloud environments (a capability unmatched by traditional or appliance-centric solutions). This model comes together in Cisco's Hybrid Mesh Firewall architecture, which unifies policy across macro, micro, and runtime layers through a single control plane. Hypershield, Secure Workload, and the Isovalent Enterprise Platform each contribute unique capabilities within that framework. Segmentation is only effective if policies can be managed consistently across environments. Defining fine-grained rules in Kubernetes or isolating racks in the data centre is one step, but ensuring those rules align and remain enforceable everywhere is a far greater challenge. Hypershield addresses this by providing a single framework to define, test, and distribute policies across Cisco Smart Switches, bare-metal servers, virtual machines, and the Isovalent platform for Kubernetes environments. Through the Hybrid Mesh Firewall, policies managed in Security Cloud Control can also be validated before rollout and enforced natively by the underlying platform, whether that is a DPU in a Smart Switch, an eBPF datapath in Kubernetes, or an existing Cisco or third-party firewall. Secure Workload provides mature microsegmentation across heterogeneous environments, including Windows and older Linux distributions. The Isovalent Enterprise Platform, built on Cilium and Tetragon, introduces identity-aware enforcement for Kubernetes and cloud-native applications, combining workload and runtime protection within a single data plane. Cisco Cloud Protection Suite complements this strategy by simplifying how these capabilities are delivered and consumed. It provides a unified model for packaging, licensing, and orchestrating Cisco’s cloud security services, enabling customers to adopt segmentation and protection controls as part of a single, cohesive security offering. As applications span clouds, data centres, and edge locations, the combination of Hypershield, Secure Workload, and the Isovalent Enterprise Platform ensures that segmentation remains consistent, automated, and adaptable to any environment. Conclusion Segmentation is a spectrum. Macro, micro, and runtime controls each serve a purpose, and applying them in unison builds the resilience needed against modern threats. Like the spectrum of light, the full picture only emerges when every part is visible. Cisco and Isovalent bring these layers into alignment, embedding controls within workloads, runtimes, and the network fabric itself.