Microsegmentation Buyers Guide: Requirements, Vendor Questions and a Proof of Concept Plan

Microsegmentation products promise to stop lateral movement, but they enforce policy in very different places, and the wrong choice leaves your most exposed systems unprotected or your operations team buried in rules. Some products enforce on the host through agents, some in the hypervisor, some in network devices, some in the cloud provider's native controls and some inside Kubernetes or a service mesh. This vendor-neutral buyer's guide helps security architects, network and platform teams and procurement define requirements, compare products on what matters, ask the questions that expose weak spots, and run a proof of concept that tests real traffic. For design principles, zone models and PCI DSS scoping, read the Network Segmentation Guide first; this page focuses on buying.

Key takeaways

• Match the enforcement point to your estate. CISA groups microsegmentation technology into network, endpoint, container, hypervisor and cloud approaches; most organisations need two or more, so check coverage of each environment you run.
• Visibility comes before enforcement. The product must map application dependencies accurately before you write a single rule, and it must let you run policy in an alert-only mode first.
• Policy should follow identity, not IP addresses. Labels, workload identity and user identity keep rules stable when addresses change.
• Test operations, not demos. Rule lifecycle, rollback, change approval and the effort to keep policy current decide whether a deployment survives its second year.
• Legacy, OT and unmanaged devices need a plan. Agent-based products cannot cover devices that cannot run an agent; confirm the network-based fallback.

What the category does

CISA's Microsegmentation in Zero Trust Part One (July 2025) describes microsegmentation as a networking control that limits connections to a zone or segment, and notes that in a zero trust architecture it includes policy enforcement points that use attributes beyond IP addresses. The NSA's Network and Environment pillar guidance (March 2024) distinguishes macro segmentation, which divides the network into zones, from micro segmentation, which isolates users, applications or workflows into smaller segments with strict access policies. A microsegmentation product typically provides four things:

• Discovery: observation of flows between workloads, users and devices, and an application dependency map.
• Policy authoring: rules expressed with labels or identities, ideally suggested from observed traffic.
• Enforcement: pushing rules to an enforcement point, such as a host firewall, a hypervisor switch, a cloud security group or a Kubernetes network policy.
• Monitoring: logs of allowed and blocked flows, policy violation alerts and reporting for audits.

When you need it

• Flat internal networks: any user or server can reach most others, so one compromised host exposes everything. See the Zero Trust Network Segmentation Playbook for Flat Networks.
• Ransomware containment: you need to stop spread through ATT&CK techniques such as T1021 Remote Services, T1210 Exploitation of Remote Services and T1570 Lateral Tool Transfer. See the Lateral Movement Guide.
• Compliance scope reduction: isolating cardholder data or other regulated environments to reduce audit scope, with segmentation testing required by PCI DSS.
• Hybrid and multi-cloud estates: rules must be consistent across data centres and clouds that use different native controls.
• Zero trust programmes: the network pillar of your zero trust roadmap calls for segmentation by application and identity. See the CISA Zero Trust Maturity Model Guide.

If you only run a single cloud with infrastructure as code, native controls plus a policy review process may be enough. A dedicated product earns its cost when you have hybrid estates, many applications with unknown dependencies, or audit pressure to show consistent policy.

• Smaller organisations: often get most of the benefit from macro segmentation on existing firewalls (users, servers, management and backup networks kept apart) plus host firewalls managed through endpoint tooling. Buy a microsegmentation product only when the number of applications makes manual rules unmanageable.
• Large and regulated organisations: usually need a central policy layer across several enforcement points, with role-based administration so application teams can request changes without holding firewall rights.
• Agent or agentless: choose agent-based enforcement where you control the operating system and want fine-grained, workload-following rules; choose network or hypervisor enforcement where agents are not allowed, such as appliances, OT controllers and medical devices.

Define requirements

• Environments: list every environment in scope (physical servers, virtual machines, each cloud, Kubernetes clusters, user devices, OT and IoT) and the share of workloads in each.
• Agent tolerance: which systems can run an agent, which cannot (appliances, OT, legacy operating systems), and who owns approval for agents.
• Priority assets: CISA's first phase is to identify candidate resources by criticality or ease of transition; name the crown jewels and the first three applications.
• Policy model: environment, application and tier labels; whether rules should use user identity, workload identity or both.
• Operating model: who writes, approves and changes rules (security, network, platform or application teams), and how changes flow through existing change management.
• Integrations: CMDB or asset inventory, identity provider, SIEM, SOAR, EDR, ticketing and infrastructure as code pipelines.
• Compliance: evidence needed for PCI DSS segmentation tests, ISO/IEC 27001 Annex A 8.22 Segregation of networks, NIST SP 800-53 SC-7 Boundary Protection and AC-4 Information Flow Enforcement.

Where identity fits

Rules based on identity survive re-addressing, autoscaling and cloud migration; rules based on IP addresses do not. Ask how each product identifies a workload: from labels in the orchestrator, from cloud tags, from a certificate such as a SPIFFE ID, or from the agent's own identity. The integration that pushes rules to firewalls or cloud APIs is itself a powerful non-human identity: scope it narrowly, give it short-lived credentials and log every change it makes. See the Cloud Workload Identity Guide and the SPIFFE and SPIRE Guide.

Evaluation criteria

Questions to ask vendors

• Which of our environments do you enforce in natively, and which do you only observe? What do you do for devices that cannot run an agent?
• How do you build the dependency map: flow logs, packet capture, host agents? How long do you need to observe before suggesting rules, and how do you handle monthly or quarterly jobs that are easy to miss?
• Show a rule written with labels or identities rather than IP addresses, then show what happens when the workload is redeployed with a new address.
• Can every rule and every segment run in alert-only mode before enforcement? How quickly can we roll back a blocking rule?
• What happens to enforcement if your management plane or cloud service is unreachable for an hour?
• How do you translate policy into each cloud's native controls, and how do you handle provider limits on rule counts?
• Do you support Kubernetes network policy, a service mesh, or your own enforcement inside clusters?
• Which credentials does your platform hold to change our firewalls or cloud configuration, and can they be short-lived and least privilege?
• How do you prove segmentation to an auditor? Can you export evidence for PCI DSS segmentation testing?
• How many rules does a typical customer of our size maintain, and how many staff run the platform day to day?

Red flags

• Dependency maps that need weeks of professional services before they are usable, with no way to validate accuracy.
• No alert-only or test mode, or rollback that requires a support ticket.
• Policies that can only be expressed with IP addresses and ports.
• "Agentless" claims that turn out to mean cloud native rules only, with no answer for on-premises or OT.
• Integration accounts with permanent administrative rights over firewalls or cloud accounts.
• No export of flow and policy logs to your SIEM, or a per-event charge that makes logging unaffordable.
• Undefined behaviour when the management plane fails.

Proof of concept

1. Pick scope: one critical three-tier application, one Kubernetes namespace or cloud account, and one group of legacy or agentless servers. CISA recommends starting with candidate resources chosen by criticality or ease of transition.
2. Observe: run discovery for at least two weeks, covering a month-end or batch job if possible. Compare the map against what the application owners know and record missed or false dependencies, as CISA advises validating the dependency list.
3. Write policy: build deny-by-default rules with labels or identities, and count how many rules each product needs for the same application.
4. Enforce in alert-only mode: CISA notes that deployments often start in a permissive, alert-only mode to find missed dependencies. Run for a week and review what would have been blocked.
5. Enforce and test: switch to blocking, then simulate lateral movement from a test host using safe techniques (port scanning, remote service connections) and confirm blocks and alerts in the SIEM.
6. Test change and rollback: redeploy a workload with a new address, add a new service through your pipeline, and roll back a blocking rule. Time each step.
7. Test failure: disconnect the management plane and confirm enforcement behaves as documented.
8. Score: rate coverage, map accuracy, rule count, time to roll back, alert quality and operator effort, using the evaluation criteria above.

Deployment and integration

CISA's planning guidance describes an iterative cycle: identify candidates, identify dependencies, determine policies, deploy, then repeat as applications and threats change. In practice:

• Start with visibility everywhere, enforcement in rings: deploy discovery across the estate, then enforce first around crown jewels and administrative access paths, then by application.
• Ring-fence first, then go finer: separate environments (production, test, user networks) before writing per-application rules; the NSA's maturity levels move from isolating critical flows at Basic to extensive application and data flow based segmentation at Advanced.
• Integrate with the asset inventory: labels should come from the CMDB or cloud tags, so new workloads inherit policy. See the Asset Inventory and CMDB Security Guide.
• Feed the SOC: send blocked and anomalous flows to the SIEM and connect response actions, such as quarantine labels, to playbooks.
• Put rules in code: manage rules through infrastructure as code with peer review, so application teams own changes within guardrails.

Measure success after go-live with: percentage of critical workloads under enforced policy, percentage of rules expressed with labels or identities, number of rules with no hits in 90 days, mean time to roll back a blocking rule, and lateral movement techniques blocked in each quarterly test. Map the programme to NIST CSF 2.0 PR.IR-01 and ID.AM-03, ATT&CK mitigation M1030 Network Segmentation and D3FEND D3-NI Network Isolation.

Standards and references

• CISA: Microsegmentation in Zero Trust Part One, Introduction and Planning
• NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-53 Rev. 5 (SC-7, AC-4)
• MITRE ATT&CK: M1030 Network Segmentation
• MITRE D3FEND: Network Isolation
• Kubernetes: Network Policies

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Network Segmentation Guide · Firewall Buyer's Guide · ZTNA Guide · Service Mesh Security Guide