Microsegmentation vs Network Segmentation: What Actually Separates Them

The shortlist, grouped by the gap you are actually filling. Each description is drawn from the vendor’s own published scope language, listed alphabetically, with no ranking implied.

If the gap is remote user access to private applications: Zscaler Private Access documents user-to-application access brokered by the Zero Trust Exchange, with an App Connector deployed in front of the private application. Other vendors compete directly here. This guide does not compare them at the same depth.

If the gap is workload-to-workload traffic on hosts that can run software: Akamai Guardicore Segmentation documents both agent-based and agentless options, and states agentless is suited to in-cloud PaaS, IoT and OT. Cisco Secure Workload documents agent-based enforcement for data center and cloud workloads. ColorTokens Xshield documents a combination of lightweight agents, reuse of existing EDR agents, native cloud controls and an agentless Gatekeeper appliance. Illumio documents a Virtual Enforcement Node deployed into user space on each protected workload, which programs the host operating system firewall. Zscaler Microsegmentation documents granular visibility, group recommendations and local enforcement in what Zscaler calls a simple agent-based architecture for cloud and data center workloads.

If the gap is device-to-device traffic on assets that cannot run software: Elisity documents identity-based policy enforced by access-layer infrastructure already deployed, against a published compatibility matrix of specific hardware models and software versions. Zero Networks documents a fully agentless model in which a Segment Server observes connections for a learning period, then applies rules to host firewalls on managed devices and to access control lists on the network infrastructure connecting unmanaged OT devices. Zscaler Zero Trust Device Segmentation, also published as OT/IoT Segmentation, documents an agentless design that isolates every IP endpoint into a network segment of one using a DHCP proxy gateway placed in the traffic path.

Which Zscaler segmentation product do you mean?

This is the question that decides everything downstream, and it is the reason a single shortlist cannot answer the query. Read against Zscaler’s own published documents, at least four distinct products carry segmentation or access language, and they do not address the same traffic.

Zscaler product	Traffic it addresses	Agent required	Where enforcement sits
Zscaler Internet Access (ZIA)	User and office traffic to the internet	Client Connector, or a PAC file, or a tunnel from the site	Zscaler cloud
Zscaler Private Access (ZPA)	User to private application access	Client Connector on the device, App Connector at the application	Zscaler cloud, brokered
Zscaler Microsegmentation	Server to server and east-west traffic for cloud and data center workloads	Yes, described by Zscaler as a simple agent-based architecture	On the host, described as host-based segmentation
Zero Trust Device Segmentation, also published as OT/IoT Segmentation	Device to device traffic inside branch, factory and campus networks	No, agentless	A DHCP proxy gateway appliance in the traffic path

One documentation note, recorded because it costs buyers real diligence time: the device segmentation line is published under two names, Zero Trust Device Segmentation and OT/IoT Segmentation, across two current documents. Product renaming is common across this market, and several other vendors in this guide have renamed or rebranded segmentation products in the same period.

What happened to Airgap Networks after Zscaler acquired it?

Zscaler announced an agreement to acquire Airgap Networks on 11 April 2024 and completed the acquisition on 12 April 2024. Zscaler’s announcement described the goal as combining its Zero Trust SD-WAN with Airgap’s agentless segmentation technology to bring segmentation to IoT and OT devices across branches, campuses, factories and data centers. In its annual report for the fiscal year ended 31 July 2024, Zscaler recorded total purchase price consideration of 124.4 million dollars, on an allocation the filing describes as preliminary and subject to working capital adjustment, plus deferred merger consideration for certain Airgap employees with a grant-date fair value of 20.3 million dollars payable in restricted shares.

Airgap’s technology, before the acquisition, was built on a DHCP proxy architecture that isolated devices and controlled access by identity and context. That mechanism is still visible in the current product. Zscaler’s Zero Trust Device Segmentation data sheet places a DHCP proxy gateway in the traffic path and describes isolating every IP endpoint into a network segment of one, with gateway appliances available as physical or virtual machines and a two-node option.

Do I need Zscaler and microsegmentation, or do they overlap?

For most enterprises they do not overlap, because they govern different traffic. ZIA governs traffic leaving the organisation for the internet. ZPA governs a user reaching a private application. Neither one sees an infusion pump talking to a workstation on the same VLAN, or a programmable logic controller talking to a historian in the same cell. That east-west traffic is what microsegmentation addresses, and it is the traffic ransomware uses to move once it lands.

The genuine overlap question is narrower than the query suggests. It applies only if you are comparing Zero Trust Device Segmentation against another east-west product, because those two are competing for the same job. Comparing ZPA against a microsegmentation platform is comparing a remote access control against a lateral movement control.

Access-layer segmentation platforms and SSE platforms are also frequently deployed together, and several vendors on both sides publish mechanisms for exchanging policy context between the two, so that an identity decision made in one is reflected in the other.

What does a segment of one do to Layer 2 traffic?

This is the most consequential technical question on this page, and it applies to any per-device isolation design, not only Zscaler’s.

Zero Trust Device Segmentation isolates every IP endpoint into a network segment of one. Practitioners who have deployed the architecture describe the mechanism plainly: because every device sits on a host route, there is no Layer 2 communication between devices, and deployment involves making the gateway the default gateway and changing endpoint subnet masks accordingly. Proponents describe this as straightforward to roll out and effective in IoT and OT environments.

That same property is the constraint. A meaningful set of operational protocols depend on Layer 2 adjacency or broadcast and multicast on a shared segment. PROFINET and EtherCAT on a plant floor, IEC 61850 GOOSE messaging in substations, BACnet discovery in building systems, multicast DNS device discovery, and some nurse-call and clinical paging systems all assume peers can reach each other at Layer 2. Where a device population depends on that behaviour, isolating each endpoint into its own segment changes how those protocols work, and the design has to account for it.

This is a question to put to any vendor whose model isolates devices individually, and to test in a proof of value against your actual protocol mix rather than against a generic device list. Two further prerequisites follow from the same architecture. Placing a DHCP proxy in the path makes DHCP a production-critical service, which interacts with static-IP devices, hardcoded default gateways and address reservations. And gateway appliances are hardware or virtual machines to size, deploy and maintain per site.

What are the alternatives to Zscaler for segmentation?

The table below is keyed on the vendor, and every entry is drawn from that vendor’s own published documentation.

Vendor and product	Agent required	Where enforcement happens	Documented scope	One documented limit
Akamai Guardicore Segmentation	Optional, agent and agentless options	Host agent, or agentless at the network and host system layer	Hybrid cloud workloads, with agentless stated as suited to in-cloud PaaS, IoT and OT	Akamai states agent deployment is recommended for maximum visibility and control
ColorTokens Xshield	Optional	Native agent, reused EDR agent, native cloud controls, or an agentless Gatekeeper appliance	Hybrid IT and OT, with a Gatekeeper deployable as a virtual machine or as hardware on the shop floor	No Gatekeeper sizing figures are published in the data sheet or solution brief
Elisity	No	Access-layer infrastructure already deployed, with a cloud control plane	Campus, branch, clinical and OT device estates, using identity rather than address	Enforcement is bounded by a published compatibility matrix of specific hardware models and software versions, and only covers traffic that traverses that infrastructure
Illumio	Yes	On the workload, by programming the host operating system firewall	Clouds, data centers and endpoint devices	Illumio states its user-space agent has less visibility into processes deeper in kernel space than kernel-based alternatives
Zero Networks Segment	No	Host firewalls on managed devices, and access control lists on the network infrastructure for unmanaged devices	Mixed IT, OT and IoT estates, after an observation period	Enforcement for unmanaged devices depends on what the connecting network infrastructure supports
Zscaler Zero Trust Device Segmentation	No	A DHCP proxy gateway appliance in the traffic path	Branch, factory and campus networks, isolating every IP endpoint into a segment of one	Per-device isolation removes Layer 2 adjacency between devices, and gateway appliances are deployed per site
Zscaler Microsegmentation	Yes	On the host, described by Zscaler as host-based segmentation	Cloud and data center workloads, server to server	An agent-based model does not address devices that cannot run software

What does each approach not do?

Every architecture in this market trades something. The trade is usually the most useful thing to know about it.

Agent-based platforms give the richest context, because software on the host can see processes and applications, not only addresses. They cannot protect anything that will not accept an agent, which in a hospital or a plant is frequently the majority of the connected estate.

Per-device isolation using a gateway in the path requires no agent and reaches devices nothing else can reach. It changes Layer 2 behaviour for every device it protects, makes DHCP production-critical, and adds appliances to size and maintain at each site.

Enforcement by access-layer infrastructure requires no agent and no new hardware in the path, and preserves normal Layer 2 behaviour. It only sees traffic that actually traverses the enforcing infrastructure, so traffic between devices behind a downstream unmanaged device, or in a daisy-chained topology, reaches no enforcement point. It is also bounded by a published compatibility matrix, so the specific models and software versions in your estate decide what is enforceable. This constraint applies to every vendor in this category without exception, and it is the first thing to check against your own hardware inventory.

Cloud-delivered access controls such as ZIA and ZPA govern traffic that leaves the site or reaches an application. They are not designed to see or stop device-to-device traffic on a local segment, and evaluating them as though they were is the single most common category error behind this query.

How does each approach go live without breaking production?

In a hospital or on a plant floor, deployment risk decides the evaluation more often than the feature list does. Six questions separate the options, and only two of them can be answered from published documentation today. Ask every vendor for the other four in writing, and treat a demonstration as an illustration rather than an answer.

First, is there a genuine observe-only mode in which policy is provisioned but not enforced? Illumio documents that state in product terms: provisioned rules can sit in a non-enforcing “Static Policy” state, the workloads display a Staged status, and administrators must manually click Apply Policy to enforce the rules. Illumio’s documentation recommends that state for testing. Zero Networks documents a different route to the same caution, a Segment Server installed on the network that monitors all connections for up to a 30-day learning period before it centrally applies rules. Those two behaviours are documented. For any other product, ask for the page reference rather than the claim.

Second, what has to be installed, and what privilege does it need? Akamai documents both agent-based and agentless options for Guardicore Segmentation, and states that agent deployment is recommended for achieving maximum visibility and control, so the less invasive choice can also be the less capable one. Cisco documents agentless visibility for Secure Workload through NetFlow/IPFIX and ERSPAN connectors as an alternative to host agents, which require root or administrator privileges. Zscaler documents zero-touch Airgap Gateway provisioning for Zero Trust Device Segmentation, with physical or virtual gateways and a two-node option. Those are three different change-control conversations: a host package, a traffic feed, or an appliance per site.

The remaining four questions are the ones this page cannot answer, because none of the vendor documentation reviewed for this page contains a complete failure specification. Where a design places an appliance in the traffic path, the architecture implies that the availability of that appliance becomes the availability of production, but implication is not documentation. Put the following to every vendor during a proof of value, and require the answers in writing.

Question to put to every vendor	What a usable answer contains
What happens to traffic while the enforcement point reboots?	Whether traffic continues or stops, for how long, and whether that behaviour is configurable
What happens when the enforcement point cannot reach the management plane?	Whether the last known policy keeps enforcing, for how long, and what stops working first
How long does a full rollback take, and what is the procedure?	A written, ordered procedure and a timed run on a live segment, not an assurance
Does the cutover fit one maintenance window?	Per-site steps with a duration against each, compared against your real window

What happens when the enforcement point fails?

Ask this in every evaluation, and require a document rather than a demonstration. Vendors publish where enforcement lives far more consistently than they publish what happens when it stops. Architecture is the part you can verify today, so start there and treat failure behaviour as a written question each vendor answers for your design.

Where enforcement lives	Documented architecture	Documented failure behaviour	What the architecture implies, to confirm with the vendor
On the protected host	Illumio documents that its Virtual Enforcement Node retrieves policy from the Policy Compute Engine, enforces locally by programming the native operating system firewall, and that the engine never initiates communication with workloads.	not documented	Rules already sit in the host firewall, so losing the management plane looks architecturally different from losing enforcement. That is reasoning from the design, not a published failure specification.
In a device placed in the traffic path	Zscaler Zero Trust Device Segmentation documents a DHCP proxy gateway in the traffic path.	Zscaler documents a two-node gateway option. Whether traffic continues or stops on failure: not documented	A component in the traffic path has to stay up for the traffic it carries, and a per-device design carries all of it. Ask for documented fail-open or fail-closed behaviour, and for what an appliance pair does during a failover.
On network infrastructure already deployed	Zero Networks documents rules applied to host firewalls on managed devices and to access control lists on the infrastructure connecting unmanaged devices. Cisco documents TrustSec enforcement at the exit network device using Security Group ACLs.	Zero Networks documents an additional Trust Server for high availability. Behaviour of installed rules during a control-plane outage: not documented	Nothing is added to the path, so no new component sits between two devices. Only traffic that traverses the enforcing infrastructure reaches a policy decision at all.
Nowhere, by design	Forescout documents that eyeSegment does not enforce traffic itself; it orchestrates controls across existing enforcement points.	not documented	Failure behaviour is inherited from whatever actually enforces, so the question repeats for each underlying control.

Every “not documented” above means the statement was absent from the sources reviewed here: Zscaler’s Zero Trust Device Segmentation data sheet and OT/IoT segmentation brief, Illumio’s Virtual Enforcement Node and security policy documentation, Zero Networks’ platform pages and technical product overview, Forescout’s eyeSegment page, and Cisco’s TrustSec collateral. Absence is not evidence of bad behaviour. It means the answer has to come from the vendor in writing, against your topology.

The limitation named earlier under what each approach does not do applies here too, to every design that enforces on infrastructure already deployed, without exception. Traffic between two devices behind the same downstream unmanaged hardware, or on a daisy-chained run, never traverses an enforcement point, so no policy is evaluated on it. That holds for Cisco TrustSec, the unmanaged-device path in the Zero Networks model, Elisity, and any comparable approach. Map the access-layer topology before an evaluation, not during one.

How much discovery and classification work is this really?

Policy quality is downstream of classification quality. A rule that permits an infusion pump to reach its own vendor’s server and nothing else is only as good as the inventory that decided which endpoints are infusion pumps. In a hospital or on a plant floor that inventory is rarely clean when the project starts, and cleaning it is usually the longest task on the plan.

Platforms in this market split on where classification comes from. Some document native discovery, some document a dependency on systems you already own, and the table below shows both patterns. The useful question is therefore narrower than whether a platform does discovery: which sources can it consume, and how much manual classification is left once those integrations are connected?

Platform	Documented discovery and classification input	Published figure for manual classification remaining
Arista Multi-Domain Segmentation	Documented dependency on external sources such as NAC systems, CMDBs and virtualization infrastructure management to classify endpoints into microperimeters, plus Arista NetDL for traffic mapping	not documented
Cisco TrustSec	Classification at network access, for example through 802.1X, with ISE assigning a Security Group Tag	not documented
Elisity	Documented dependency on external sources: IdentityGraph correlates device and user identity from Active Directory, CMDBs, EDR platforms and tools including Armis, Claroty and Medigate	not documented
Forescout eyeSegment	More than 30 agentless discovery methods covering managed, unmanaged and headless devices, classifying by device type, function, operating system, behaviour, risk score and communication patterns	not documented
Palo Alto Networks OT Security	350 or more OT asset profiles, 1,070 or more OT and ICS app identifiers and 650 or more OT threat signatures, applied through passive machine learning, App-ID and Device-ID for devices that cannot run agents	not documented

The third column is the honest state of the market. Across the Forescout eyeSegment product page, the Palo Alto Networks OT security solution page, the Arista Multi-Domain Segmentation product page, Cisco’s published TrustSec material and Elisity’s own solution overview data sheet, we found no figure in any of them for how many endpoints remain unclassified once its integrations are connected. Treat any number offered verbally as a claim to test against your own inventory.

Two shapes of dependency are worth separating. A platform that discovers natively carries that workload itself. A platform that consumes classification from a NAC system, a CMDB or a clinical asset tool, as Arista and Elisity both document, inherits the accuracy of those systems, which the architecture implies will surface as a policy gap wherever the upstream record is stale or missing. Ask each vendor to confirm from documentation what happens to an endpoint it cannot classify, because that default decides whether an unknown device is quietly permitted or quietly cut off.

Scope shapes the effort too. Elisity publishes a comparison rating its own cloud and Kubernetes support as limited, and states that organisations with primarily cloud-native workloads may need to pair it with a cloud-focused tool, so a discovery model built around campus and OT estates leaves the cloud estate to be classified separately.

We already have NAC or an asset intelligence platform. Do we need microsegmentation too?

In most environments these are complementary layers rather than substitutes, because they answer different questions. Network access control and asset intelligence platforms largely answer what is on the network and whether it should be admitted. Segmentation answers what a thing may talk to once it is admitted. A device can be correctly identified, correctly admitted and still reach every other device on its VLAN.

The segmentation vendors themselves document consuming that data rather than replacing it. Cisco TrustSec classifies at network access, where Cisco ISE assigns a Security Group Tag, then propagates the tag and enforces at the exit device using Security Group ACLs. Arista states its Multi-Domain Segmentation depends on external sources including NAC systems and CMDBs to classify endpoints. In each case the asset system stays and the segmentation product reads from it.

A second distinction matters more than the category label: whether a product is the enforcement point, or a policy modelling and orchestration layer above other enforcement points. Forescout states that eyeSegment does not enforce traffic itself, and that it orchestrates controls across enforcement points, driving existing network infrastructure, NAC systems and firewalls. That is a legitimate design, not a deficiency, but it decides what you are buying and which team owns the failure mode.

Platform	What its own documentation says it consumes or depends on	Does it enforce traffic itself
Cisco TrustSec	Classification at network access, for example 802.1X, where Cisco ISE assigns a Security Group Tag	Yes, at the exit device using Security Group ACLs or firewall rules, with no endpoint agent
Forescout eyeSegment	More than 30 agentless discovery methods covering managed, unmanaged and headless devices	No. Forescout states it orchestrates controls across existing enforcement points
Arista Multi-Domain Segmentation	NAC systems, CMDBs and virtualization infrastructure management solutions for classification	Yes, policy orchestrated by CloudVision on Arista’s own EOS network infrastructure, with no agents on endpoints and workloads, though Arista documents that classification depends on external sources
Elisity	Active Directory, CMDBs, EDR platforms and tools such as Armis, Claroty and Medigate	Yes, at access-layer infrastructure already deployed

One gap worth stating plainly: across the Forescout eyeSegment product page and the Forescout network segmentation solution page, we found no claim that an asset intelligence platform enforces device-to-device traffic on its own. Whether your own deployment already blocks east-west traffic is not documented in that material, so confirm it against your configuration.

Frequently asked questions

Every capability statement on this page is drawn from the named vendor’s own current public documentation. Last reviewed 3 August 2026.

What are the alternatives to Zscaler for segmentation?

It depends which Zscaler product you are replacing. For user-to-application access, the alternatives are other SSE and ZTNA platforms. For workload-to-workload traffic on hosts that can run software, documented alternatives include Akamai Guardicore Segmentation, Cisco Secure Workload, ColorTokens Xshield and Illumio. For device-to-device traffic on assets that cannot run software, documented alternatives include Elisity, Zero Networks and Zscaler’s own Zero Trust Device Segmentation. Establishing which traffic is unprotected today is the step that makes the shortlist obvious.

Do I need Zscaler and microsegmentation, or do they overlap?

In most enterprises they do not overlap, because they govern different traffic. Zscaler Internet Access governs traffic to the internet and Zscaler Private Access governs a user reaching a private application. Neither sees device-to-device traffic on a local network segment, which is what microsegmentation controls and what lateral movement uses. A genuine overlap exists only when comparing Zscaler Zero Trust Device Segmentation against another east-west segmentation product, because those two address the same traffic.

Is Zscaler Microsegmentation agentless?

No. Zscaler describes Zscaler Microsegmentation as providing local enforcement in a simple agent-based architecture, and describes the capability as host-based segmentation for cloud and data center workloads. Zscaler’s agentless offering is a different product, Zero Trust Device Segmentation, which is also published as OT/IoT Segmentation.

What happened to Airgap Networks after Zscaler acquired it?

Zscaler announced the acquisition on 11 April 2024 and completed it on 12 April 2024, recording total purchase price consideration of 124.4 million dollars in its annual report for the fiscal year ended 31 July 2024. Airgap’s DHCP proxy architecture remains visible in Zscaler Zero Trust Device Segmentation, which places a DHCP proxy gateway in the traffic path and isolates every IP endpoint into a network segment of one.

Does isolating every device into a segment of one break OT protocols?

It changes how any protocol that depends on Layer 2 adjacency or broadcast behaves, because devices on individual host routes do not communicate at Layer 2. Protocols to test include PROFINET, EtherCAT, IEC 61850 GOOSE, BACnet discovery, multicast DNS discovery and some clinical paging systems. Whether this is a problem depends entirely on your protocol mix, so it should be tested in a proof of value against real traffic rather than against a generic device list.

Can microsegmentation protect devices that cannot run an agent?

Yes, but only with an architecture that does not require one. Agentless approaches differ in where they enforce: Zscaler Zero Trust Device Segmentation uses a DHCP proxy gateway appliance placed in the traffic path, Zero Networks applies access control lists to the network infrastructure connecting unmanaged devices, and Elisity enforces using access-layer infrastructure already deployed against a published compatibility matrix. Each choice carries different prerequisites and different failure behaviour.

Which approach is best for a hospital or a plant?

There is no single answer, because the deciding factors are specific to the estate. Four variables matter and none of them outranks the others: what proportion of the assets can host software, where enforcement can physically live, what context the policy needs beyond an address, and which environments have to be covered, including cloud workloads. An architecture that suits a data center rarely suits a plant floor, and the reverse is equally true.

Does an agentless approach mean no new hardware?

Not necessarily, and the difference is worth checking. Agentless means no software on the protected device. It does not mean nothing is added to the network. Designs that place a gateway appliance in the traffic path add hardware or virtual machines to size and maintain per site. Designs that enforce using access-layer infrastructure already deployed do not, but are bounded by what that infrastructure supports.