TL;DR: Zero trust segmentation fails when security and network teams lack shared device, dependency, and risk context, according to Asimily, because blocked connections can create downtime while permissive policies leave lateral movement paths open. The real control problem is continuously balancing blast-radius reduction against operational continuity.
Editorial analysis by NHI Mgmt Group, based on content published by Asimily: “How Security and Network Teams Can Work Together to Achieve Zero Trust”.
Key questions
Q: What breaks when zero trust segmentation is applied without device context?
A: Security teams often block legitimate communications because they cannot see the dependencies behind a device’s normal operation.
Q: Why do unmanaged device dependencies make zero trust harder to enforce?
A: Because segmentation decisions depend on knowing which paths are necessary and which are merely convenient.
Q: How do security teams know if segmentation is actually reducing risk?
A: Teams know segmentation is working when unnecessary workload communications disappear, exception volume falls, and policy changes are validated continuously rather than assumed.
Practitioner guidance
- Establish a shared device dependency inventory Build a common view of connected devices, their normal communications, and the business services those connections support before changing segmentation policy.
- Classify devices by operational function and risk Use device identification, function, and criticality to decide which paths are legitimate rather than relying on IP ranges or VLAN placement.
- Simulate segmentation before enforcement Validate proposed rules against observed traffic and dependencies so you can catch blocked workflows before they become outages.
Bottom line: Zero trust segmentation only works when security and network teams share the same view of device behavior, dependencies, and risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →