Microsegmentation cost: agent vs fabric, per-workload pricing

Microsegmentation limits east-west (workload-to-workload) network traffic to only what is explicitly authorised. Where traditional segmentation operates at the subnet level with firewalls between zones, microsegmentation operates at the workload level: every workload gets its own policy describing which other workloads it can talk to. The goal is to contain blast radius after an initial endpoint compromise. An attacker who lands on a web server cannot pivot to the database server unless explicit policy allows web-to-database traffic, even if both are on the same network segment.

CISA Zero Trust Maturity Model v2.0 treats microsegmentation as an Advanced-tier network pillar capability, deployed after identity and basic network controls (ZTNA, SWG) are mature. The Forrester Microsegmentation Wave tracks the commercial platform category. The dominant vendors are Illumio, Akamai Guardicore, Cisco Secure Workload, VMware NSX, plus newer entrants like Zero Networks and Elisity.

The pillar has two distinct architectural patterns. Agent-based microsegmentation installs a small software agent on every protected workload that enforces policy at the workload's network stack. Fabric-basedmicrosegmentation enforces policy at the underlying network or hypervisor layer. Agent-based is more portable across heterogeneous infrastructure; fabric-based is faster (no agent overhead) but locked to specific infrastructure. Most modern mid-market deployments use agent-based for portability.

Microsegmentation policy is most effective when it can reference identity primitives: this user, this role, this workload identity, this asset class. Without identity context, policy falls back to IP addresses, hostnames and ports, which is what traditional firewalling does. IP-based policy works but is brittle: every workload IP change, every infrastructure refresh, every new application requires policy updates. Identity-aware policy is durable because identity primitives change much less than IP primitives.

The sequencing mistake is deploying microsegmentation in Phase 1 of a zero trust rollout, before identity context is mature. In Phase 1, the identity context is incomplete: only privileged accounts have MFA, only SaaS apps are SSO-integrated, only some workloads have workload identity. Policy authored against this incomplete context has to be re-authored once identity matures in Phase 2 or 3. The re-authoring cost is roughly half the original policy-authoring cost, which translates to 40 to 60 percent waste on the initial investment.

The fix is straightforward in principle and hard in practice: defer microsegmentation to Phase 2 or 3 of the zero trust rollout, after identity context is mature. The political challenge is that microsegmentation is exciting and visible (board reporting, analyst kudos) while identity is unglamorous (table-stakes infrastructure work). CISOs often face pressure to deploy microsegmentation early for narrative reasons. The right response is to use the early Phase 1 budget for identity work, then move to microsegmentation in Phase 2 with the savings from doing it once.

A useful intermediate path: deploy discovery-only microsegmentation in Phase 1 (the agent or fabric inspects flows and produces a behavioural baseline, but does not enforce policy). Discovery-only costs roughly 30 to 50 percent of full enforcement licensing and produces immediate value (network behaviour visibility, attack-path mapping). Move to full enforcement in Phase 2 once identity context is in place and the discovery data has produced clean policy candidates. This phased approach captures most of the value of early deployment without the re-work cost of full enforcement on incomplete identity context.

Cloud-native estates have a fundamentally different microsegmentation cost profile. AWS Security Groups, Azure Network Security Groups and GCP firewall rules provide basic microsegmentation at zero marginal cost. Service mesh (Istio, Linkerd, Consul Connect) provides identity-aware service-to-service traffic control at the application layer. The two together cover most microsegmentation requirements for cloud-native organisations at low cost.

Commercial microsegmentation platforms still add value in cloud-native estates in three scenarios. First, when policy needs to span multiple clouds with consistent tooling, native security groups become awkward (each cloud is different) and a multi-cloud microsegmentation platform pays back. Second, when policy granularity exceeds what native security groups can express (per-process policy, per-application-identity policy), commercial platforms offer expressiveness native primitives lack. Third, when the organisation needs unified policy management across hybrid (on-prem plus cloud) infrastructure, commercial platforms cover both; native primitives only cover their own cloud.

For pure cloud-native estates without these three scenarios, native security groups plus service mesh is the cost-effective microsegmentation strategy. The licensing saving versus commercial microsegmentation is 60 to 80 percent. The operational cost is higher (you need engineers fluent in each cloud's native primitives), but the total cost of ownership is typically lower. For hybrid estates with significant on-prem footprint, commercial microsegmentation is the cost-effective choice.