AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Misconfigured segmentation can cause self-inflicted outages; look for a described safe-rollout methodology (simulate/monitor before enforce) alongside the enforcement mechanism itself.
Writing segmentation policy without accurate dependency mapping breaks applications; look for automated discovery with a real accuracy figure, not a manual dependency-documentation exercise.
IP-based policy breaks immediately in dynamic environments; look for label/identity-based policy that survives workload churn, which is now the standard expectation.
Simulation mode is the single most important safety feature for avoiding production outages from segmentation changes — a product without it is asking the customer to enforce blind.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Look for an honest per-environment coverage breakdown; 'unified policy' claims sometimes hide separate underlying engines with different capabilities per environment.
Identity-aware segmentation is materially stronger than location-only network segmentation — look for real IdP/service-identity integration.
Host-based enforcement agents can add meaningful latency/CPU overhead at scale — look for measured, realistic figures, not lab benchmarks.
Look for continuous, exportable enforcement evidence — compliance segmentation requirements need ongoing proof, not a one-time architecture diagram.
Workload-count-based pricing interacts awkwardly with autoscaling — ask explicitly how the vendor handles pricing for a highly elastic environment rather than assuming a static count.
Strong answers describe a real post-incident policy-gap analysis workflow with a customer example, not just the general claim that segmentation reduces lateral-movement risk.
Trend-over-time coverage reporting is a distinct capability from a point-in-time policy view — confirm this exists as a maintained, exportable report.
This is a real, common buyer question given the functional overlap — a vendor should give an honest answer about the boundary and complementarity, not imply a standalone purchase is always necessary.
A complete application-dependency map is a meaningful target in its own right — role-based access control over this specific asset is an often-overlooked consideration.
A false positive on enforced segmentation policy can break legitimate application communication — ask for a real, customer-validated false-positive figure and a safe enforcement-rollout process.
Strong answers give a concrete, customer-validated timeline for a realistic large-scale retrofit scenario, not just a greenfield deployment example.
OT-specific segmentation requires genuinely different technical understanding (Purdue Model zones, OT protocols) than generic IT east-west policy — a vendor should clarify whether real OT-aware segmentation exists or coverage is IT-only.