Illumio Segmentation

Evaluates proposed segmentation policies against observed traffic to identify what legitimate connections would be blocked, enabling policy validation without a production enforcement change.

Enriches raw flow and asset records with context such as owning process, user, application, environment, cloud tags, CMDB attributes and threat intelligence, and turns that context into labels that policies reference directly, so rules are written in business terms (application, environment, role) rather than addresses and ports. Products differ in attribute breadth, process- and payload-level depth, and how much labeling is automatic rather than manual.

Discovers and classifies every workload and device that communicates on the network, including unknown and unmanaged assets missing from the CMDB, using the product's own agents, network sensors and ingested external inventories, so segmentation policy can cover assets the organization did not know it had. Products differ in fingerprinting depth (device make, model, operating system, function), agentless reach, and use of external data sources.

Enforces segmentation through the existing on-premises network infrastructure, programming switches, DPU-based switches, firewalls, NAC, application delivery controllers or an inline gateway appliance, so devices that cannot run an agent are segmented without rearchitecting the network or replacing hardware. Products differ in the range of network hardware vendors supported, whether enforcement is distributed at the access layer or backhauled to central chokepoints, and dependency on a NAC deployment.

Programs the cloud provider's own network controls (AWS security groups, Azure network security groups, GCP firewall rules, VPC and VNet constructs) from the central segmentation policy, so cloud virtual machines are governed by the same labels and rules as on-premises workloads without a host agent. Products differ in provider breadth, whether enforcement uses native controls or requires proprietary virtual appliances, and how drift between cloud rules and intended policy is reconciled.

Proposes least-privilege allow-list rules automatically from observed flows, labels and templates, and manages them through the full lifecycle of creation, testing, enforcement, tuning and retirement, so segmentation is not built by writing rules by hand. Products differ in recommendation quality, template coverage for common applications and compliance zones, and support for iterative refinement before enforcement.

Segments purpose-built and unmanaged devices such as medical devices, industrial controllers, building systems and IoT endpoints that cannot host an agent and often run very old operating systems, combining device fingerprinting and classification with network-side enforcement and policy templates tuned to clinical and industrial protocols, without disrupting device operation. Products differ in device fingerprinting depth, protocol awareness, and whether enforcement works with the legacy network equipment typical of hospitals and plants.

Enforces segmentation policy on the workload itself through a host agent or existing endpoint hooks (operating system firewall, eBPF, an EDR agent already deployed), so the policy travels with the workload across data center, cloud and endpoint locations and gives per-process visibility. Products differ in operating system coverage, resource overhead, kernel or user-mode operation, and whether an existing EDR agent can be reused instead of deploying a new one.

Contains an active breach by cutting the paths ransomware and attackers use to spread: pre-staged containment policies that block peer-to-peer SMB, RDP, WMI and other administrative protocols between endpoints and servers, a firebreak around devices that cannot run security agents, and quarantine of compromised workloads that can be triggered from the console, by a severity-level switch, or by SIEM, SOAR and EDR during an incident. Products differ in whether containment can be staged by threat level and activated with a single switch, and in how quickly a quarantine reaches every enforcement point.

Renders the discovered assets, their flows and the current policy state as an interactive map that can be viewed at data center, application, workload and connection level, showing which traffic is allowed, blocked or not yet governed, so teams can author policy and investigate incidents from the same view. Products differ in readability at scale, filtering and drill-down, and whether the map supports policy authoring directly.

Extends the same segmentation policy model into Kubernetes and container environments, enforcing at pod, namespace and service level through CNI or eBPF hooks, sidecars or native NetworkPolicy objects, so container traffic is governed by the same labels and rules as virtual machines and bare metal instead of a separate container-only tool. Products differ in whether Kubernetes support is enforcement or visibility only, distribution coverage (managed cloud Kubernetes, OpenShift, self-managed), and Layer 7 awareness.

Discovers the actual north-south and east-west communication flows between workloads and devices by observing live traffic, producing the dependency data that allow-list policy is built from instead of hand-documented application maps. Products differ in flow sources (host agent, network sensors or switch telemetry, cloud flow logs, virtual switch) and therefore in how completely agentless assets are covered.