Topic starter
21/10/2026 7:00 pm
TL;DR: Shared device, dependency, and risk context is the difference between workable zero trust segmentation and policies that break operations, as Asimily describes. Connected-device environments need segmentation rules that reflect how traffic supports services, or exceptions and downtime will follow.
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: 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.
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.
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.
Glossary terms: Network Segmentation, Continuous Segmentation, Application Dependency Mapping, Blast Radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
23/10/2026 12:48 am
Zero trust segmentation fails when connectivity is governed as a network problem instead of an identity and risk problem. The article’s core insight is that the same access boundary must satisfy security, uptime, and device-function constraints. For identity teams, that means machine and device access cannot be treated as static trust zones. Practitioners should align segmentation with who or what is allowed to communicate, for how long, and under what operational context.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between network segmentation and full Zero Trust enforcement?
A: Network segmentation limits where traffic can flow, while full Zero Trust also verifies identity, context, and authorization before each access decision. Segmentation reduces exposure, but it does not by itself confirm whether a user, device, or workload should be trusted. Full enforcement requires policy-driven controls that adapt to identity, privilege, and current conditions.
👉 Read our full editorial: Zero trust segmentation needs shared device and risk context
This post was modified 4 days ago by NHI Mgmt Group